Tonight, thanks to PJ and Dylan's work, the ASP-BOT moves when it lands! We are indebted to PJ for giving us his time and expertise, and to Dylan and PJ for their diligence is seeing this problem through to good (great!) resolution. Please be sure to thank PJ for his help, everyone.
There are a few minor "tweaks" to be made in the program and I'd like Dylan and Andrew to work on these the next time we meet. But we're over the hump as far as getting the ASP-BOT moving once it lands.
PJ said that he'll be monitoring the forum and that he'll assist you as needed. But let's not wear out our welcome, either. He's already given us plenty of his time.
Now for the "bad news": we're out of PINs and there's no place to plug in the second servomotor on the BOE! You've aleady figured out what this means, right? We have to run two wheels with one motor....! Rocketeers, put your thinking caps on. We have a mechanical engineering challenge to solve.
Wow. You guys have been on fire the last day or two. I think the rocketeers owe PJ a major debt of gratitude (and maybe one of those great ARLISS t-shirts?). I'm very impressed at the amount of time and expertise he has put in here - a very worthy successor to Tracy.
Wow. You guys have been on fire the last day or two. I think the rocketeers owe PJ a major debt of gratitude (and maybe one of those great ARLISS t-shirts?). I'm very impressed at the amount of time and expertise he has put in here - a very worthy successor to Tracy.
On fire indeed ~ ! I would say blazing. PJ sure has been a great catalyst for our project and our programmers, and a fine role model of diligence. We couldn't have done it wiithout him. I think an ARLISS T-shirt is the very least we can do. We certainly owe him more than our undying appreciation and admiration. Maybe a new car? Or a new dog? What to get him, what to get him...?!
No small thanks to you too, Sylvie. You've been a stalwart of advice and support and your input and guidance have been invaluable. You've taught these kids a lot, much more than just technical expertise. Consider everything you and Tracy and PJ have role modeled: community service, fine character, humor and humility to name a few. These, in my estimation are more important than a robot, which is simply a vehicle for learning.
Today was rip-roaring fun at Harvard. The SEDS project team all got their Level 1 rockets built... six, 3-inch diameter x 42" tall scratch-built rockets. Our four-hour build time stretched into 6-1/2 hours but we got them all built, painted, and (almost) launch ready. I even built one with them. It has cool, clear plexiglass fins and I named it "Veritas." A good day's work but I had to rush back to New Hampshire for my 7 PM conference call with PJ. We talked for quite some time as we zapped programs and posts to the forum back and forth. But what a day it was today, with a lot accomplished. I'm glad it's Saturday so I can relax.
Do have any 'favorite' TARC teams in the hunt this year?
Attached are current pictures of the ASP-BOT so that everyone can see how much space is-- and isn't-- available on the clear plexiglass platforms. If we add much more, something may have to be removed. The shortwave transmitter? The CO2 sensor and ADC chip? Maybe trade the big heavy RC battery for alighter lithium battery? Physical space will ultimately make some decisions for us.
Do have any 'favorite' TARC teams in the hunt this year?
Pavel's Mad West teams again, of course.
Man, I haven't been to a rocket launch this year at all yet, other than one little low power launch at a new field back in January. I've got the urge, but no time.
Man, I haven't been to a rocket launch this year at all yet, other than one little low power launch at a new field back in January. I've got the urge, but no time.
Yeah, Pavel's Mad West TARC teams are as predictable as clockwork. But then, good science should be predicatable. I wonder how many test launches they make before they do their qualifying flights? I'll bet they go through a few thousand Newton-seconds of thrust getting ready.
I haven't launched a rocket since ARLISS either. I've worked on a lot of rockets for other people but nary a launch I've had. The group at Harvard got their Level 1 rockets pretty much finished on Saturday. We did a 6-hour build session and we went from start to finish, including the paint job. You should drop them a PM on the Harvards SEDS e-mail link and ask them how they think it went. I'm buildng a rocket with them, a 3" diameter x 42" beast with clear plexiglass fins. In the spirit of Harvard I'm naming it "Very Fast". Tee hee. We'll see who gets the double entendre.
The CO2 sensor and ADC are wired and mounted on the rover and it's spitting out data as we speak. I set the CO2 sensor Trip Level at 1000 mV and "input" millivoltage wanders from around 991 to 1050 or so. CO2 mV wanders from around 1392 to1456. Last year the data was tight-- very little variation-- and this wide range of data indicated a loose wire or somethin similar. When we had the system dialed in last year the Trip Level and CO2 mV both stayed within 0.002 or 0.003 or so. But the rover is pretty much assembled, all the major parts or installed, and the software doesn't show any major problems. Whew ~ ! That's good news, and BIG progress.
I've had 5 or 6 kids in my study hall "Advisory" class working on the wiring the last several days-- more unseen faces in the project-- and this may account for the "loose wires" (??) and the variation in data (**See attached screen shot - the third column is input mV and the fourth column is CO2 millivoltage.) When it gets here were work on getting the ServoPal and servos working, and fine tuning the wiring. Thanks again for the servo controller and the wire harness, PJ.
Mark
:cool:
=======================================
Added an hour later:
I swapped out the round CO2 sensor, not the whole module, and the data smoothed out nicely. There is little or no variation in the input millivoltage now (ranges from 1001 to 1004 mV) and the CO2 millivoltage is equally stable. There are no large jumps (e.g. from 1094 to 1164) in the CO2 mV either; the changes are small and stable. Good, good news. Things are wired correctly.
Compare column the data in column 3 and 4 in the second (good) screen shot with the first screen shot. Much less variation. ;-)
Of course I jinxed things. As soon as I took the second screen shot the data started to "stray" again...
Jake and I worked on the program in class today. We cut and pasted from your "ServoPal" program into Main_Prgrm_w_Controlled_Altit_040611_v2p5_PJ.bse (WAMD/ARLISS forum, post #150). Doggone it, we're close! The servos both activate and rotate in the same direction beautifully and your ServoPal and extender-adapter solution work beautifully! ===>
However, after we added the ServoPal code to the Main_Prgrm_w_Controlled_Altit program and bench tested the rover/program, the servos initiated between the 8th and 9th Zero Count on the debug screen. It did this before the altimeter is even in the vacuum chamber.
It seems that some program code is out of place but we couldn't figure out exactly where. I had 22 other kids in the classroom wanting to "help out", I was trying to teach Jake the logic and the "flow" (the Zen) of the program, and I couldn't concentrate well enough to figure out which line(s) of code were out of order. I'll tackle it again when I get home.
Does any program code jump out at you as being out of place?
Maybe you're "re-starting" ("re-doing") your test without pushing the Reset button on the BoE?
You must push the Reset button after any test or interruption, that's the only way to clear
those ZC and TC counters.
I added a couple of Stop commands to the ServoPAL initialisation routine in the program attached.
I'll see how you're doing when I get home later this afternoon.
I didn't have PBASIC_IDE available where I was made my Reply above. To look at it I had to change it to a .TXT and then I couldn't un-TXT it. I didn't see that till after I uploaded it, maybe that made for even more angst.
It seems that maybe you got caught up with "the 22" and didn't push the Reset button?
[Push the BoE Reset button.]
It wouldn't hurt to issue some STOP commands to begin with. Just to make sure that it's stopped from the beginning, so I kept them in the .BSE attached to this post.
There's no reason for the Servos to Go without being commanded to -- TC > 5, ZC > 8 is the only way that is possible.
PE -- You still have the DEBUG line in the Main_DO..LOOP (that should beomitted from the final version). You should be able to read the status of TC and ZC. When/once TC = 6 and ZC = 9 then the servos will turn.
I saw that P14 was declared twice, once as nInp (servoPAL way) and then as Servo (old way). I omitted the latter.
I modified the 'Movement' subroutine so that it will only get called once, from that point on it will keep rolling ("as per" the ServoPAL plan).
PJ,
You were right in your first post. The BOE simply had to be reset after its first start-up/initialization. When it's started on the bench the servos activate when the program reads ZC > 8. When it's reset and put into the bell jar, then when it comes "back to the (virtual) ground" (altitude = 0), the servos kick in perfectly...!
I'll download your new programs and compare them and report back. After dinner that is. Mrs. K has fresh oregeno bread, corn, and mustard and collard greens. If only I could upload the aroma...!
I didn't mean to bother you at work though I appreciated your reply.
Attached is an operational version of the program, open to interpretation (tweaking, critcism and humor.) It's called "Rover - Launch Ready" because essentially it is, launch ready. It's pretty much the same program that was posted above. If we had to launch tomorrow it would probably do just fine, don't you think?
Now that we're at a good "pause point" I'd like to sit back and examine the program long and hard to get a more complete understanding of how it really works. I'd also like to clean up the code a bit, if you think that will do any good (streamline DEBUG statements, etc.) Or does the axiom, "Leave well enough alone" apply here?
:thumb: <
(This is you Conscience speaking. "When in doubt, leave well enough alone, Mark.")
Thanks ever so much for sharing your time and expertise PJ.
OK.
I've attached your version with a couple of minor Revs:
I looked it over and saw that you commented out the DEBUG for ZC/TC (troubleshooting.)
I saw that PIN 14 was declared for nInp (for the ServoPAL) and Servo, so I omitted the latter.
As I mentioned in #162, "Movement" would be more efficient were it called only once. I guess it doesn't hurt anything to call it repeatedly (as it is.) It's horribly redundant, but
I'm not going to force the issue. Howbeit, I did make mention of this as comments in
"Movement" and would be much obliged for your leaving that note there.
OK.
I've attached your version with a couple of minor Revs:
I looked it over and saw that you commented out the DEBUG for ZC/TC (troubleshooting.)
Yes, this made the data on the GUI easier to interpret. Adding the statement, 'PUSH REST BUTTON" serves as a dual reminder that the first time through, the ZC is active,
.
I saw that PIN 14 was declared for nInp (for the ServoPAL) and Servo, so I omitted the latter.
I noticed that a few days ago too. But I simply left it for minds more clever than mine to decipher. Thanks for omitting (so what DOES a program do if a PIN is called on twice like that, by different names?)
.
As I mentioned in #162, "Movement" would be more efficient were it called only once. I guess it doesn't hurt anything to call it repeatedly (as it is.) It's horribly redundant, but
I'm not going to force the issue. Howbeit, I did make mention of this as comments in
"Movement" and would be much obliged for your leaving that note there....
This could be modified so that Movement is only called once by resetting ZC, TC = 0, but it doesn't hurt anything to come back here (repeated Calls to this subroutine) though it does 'defeat' the purpose of the ServoPAL.
. Can you please explain this in Braille so I can understand it? How exactly does it end-run the ServoPal if it makes both servos moves in tandem?
If you're happy then I can live with it.
.
.
Blissful would be more precise. Or ecstatic. Or relieved. I have lots of irons in the fire (though I'm sure you do, too) and it's nice to have the light at the end of the tunnel shining on cherubic faces. There are still some relatively minor mechanical things to finish and it's really nice to have programming "done". As you've figured out, while I do understand the basic's of BASIC, programming isn't my forte. My learning curve-- and the kids'-- is becoming more than flat-line though, thanks to some excellent on-line mentoring.
We had a potentially "Oh My Gosh" moment yesterday. I got the 7.2, 4000 mAh battery from "Batteris Plus" and they had soldered wires and a 9-volt battery connector on so we can connect it to the BOE. The wires and the connector were too thick to fit bewteen the 110 V and 9 volt plug-ins on the BOE so we cut the wires and soldered a thinner wire with a different end onto the battery pack's wires. Then we plugged it in. Guess what happened? When the BOE was turned on, nothing (*visible) happened. "Why?" you ask, as I did. Because the damage was already done.
We hadn't noticed that adding the battery end had essentially reversed polarity...! Red was black and black was red. BOING! =====> :thumb: (*moment of instant realization.)
We unplugged it immediately but the damage was done. Thankfully "all" that we fried was the CO2 sensor module, which we had mounted right on top of the rover's platform. That makes the fifth CO2 $en$or we've went through. "Ouch" to the wallet (and please don't tell Mrs. K.) Lesson learned again, the hard way, but the rover runs beautifully after the new COs sensor was added.
Practice at 1:00 today. We'll update you during or afterwards. Any suggestions for us before practice starts, Commander?
*Sung to the tune of "Vaya Con Dios":
"Now the hacidenda's dark, the town is sleeping.
And the time has come to part, the time for weeping.
'Vaya con huevos', compadres... (egss for breakfast)
You guys need a voltmeter. When making power connections you need to know: assume nothing.
I don't know where to begin.
I don't "do" Braille, I "do" heat - for when they feel the heat then they shall see the light.
Don't look at the ServoPAL as some "two-servos from one pin mystery device". Properly understood, it is a servo manager that autonomously oversees as many as two servos.
The asp-bot's mobility (via servos) was/is effected by the states of two status registers; zerocounter (ZC) and thousandcounter (TC). When the ZC & TC thresholds were met then a servo routine ("Movement") would be executed each time the MAWD was polled.
Formerly, with no ServoPAL, to move the asp-bot, it was necessary to run a basic servo routine, subject to servo pulsing and refresh requirements. The result was that the asp-bot would move forward briefly and then exit to the sensor reading functions (the Main:DO..LOOP) whereupon it would come around, necessarily, to execute the Movement routine, again, and so on.
Presently, the asp-bot is equipped with a ServoPAL. The ServoPAL manages the servos. The ServoPAL, a model of obedience and compliance, only needs to be told what to do once and will manage the servos as commanded, till commanded otherwise, with no further oversight.
The ROVER LAUNCH READY program, as it stands, continues to command the ServoPAL with every MAWD poll. If the object is, having landed, to get the asp-bot underway then one should simply command the ServoPAL as appropriate, because the ServoPAL takes over from there (as previously explained.) From that point, it serves no purpose to keep telling it to do the/that same thing, over and over again [emphasis], especially if it's doing what it should already.
(Imagine "the boss" telling you to mow the grass. You start the mower and start pushing it about only to have "the boss" tell you to mow the grass with each pass of the mower across the yard. Same thing.)
You guys need a voltmeter. When making power connections you need to know: assume nothing.
I don't know where to begin.
I don't "do" Braille, I "do" heat - for when they feel the heat then they shall see the light.
Don't look at the ServoPAL as some "two-servos from one pin mystery device". Properly understood, it is a servo manager that autonomously oversees as many as two servos.
The asp-bot's mobility (via servos) was/is effected by the states of two status registers; zerocounter (ZC) and thousandcounter (TC). When the ZC & TC thresholds were met then a servo routine ("Movement") would be executed each time the MAWD was polled.
Formerly, with no ServoPAL, to move the asp-bot, it was necessary to run a basic servo routine, subject to servo pulsing and refresh requirements. The result was that the asp-bot would move forward briefly and then exit to the sensor reading functions (the Main:DO..LOOP) whereupon it would come around, necessarily, to execute the Movement routine, again, and so on.
Presently, the asp-bot is equipped with a ServoPAL. The ServoPAL manages the servos. The ServoPAL, a model of obedience and compliance, only needs to be told what to do once and will manage the servos as commanded, till commanded otherwise, with no further oversight.
The ROVER LAUNCH READY program, as it stands, continues to command the ServoPAL with every MAWD poll. If the object is, having landed, to get the asp-bot underway then one should simply command the ServoPAL as appropriate, because the ServoPAL takes over from there (as previously explained.) From that point, it serves no purpose to keep telling it to do the/that same thing, over and over again [emphasis], especially if it's doing what it should already.
(Imagine "the boss" telling you to mow the grass. You start the mower and start pushing it about only to have "the boss" tell you to mow the grass with each pass of the mower across the yard. Same thing.)
Vaquero PJ Sundance,
Hacienda Kibler was hopping this afternoon. Lots of great progress and lots of happy, animated faces. The kids were thrilled to so (y)our rover ramble along the ground like a caffeinated chipmunk. It (the rover, not the caffeine) energized and buoyed them and they shifted into a higher plane of excellence because of it. Thanks.
The last "big" hurdle is that doggone parachute release mechanism. Justin and Jake had two excellent ideas and they came with two full-blown prototypes. Either idea would have worked but the Design Team opted for "The (Rube) Goldsberry Invention." Whether the decision was collective or unilateral is uncertain. Jake (of Goldsberry fame) has a full-sized prototype made of Legos and Lego motors, and two of our rover wheels, to work with. I'm eager to see what they end up with but I'm certain it *will* work.
Ah yes, the voltmeter. The good news is that we have one. That not-so-good news is that "someone" didn't use it to check polarity before installing the battery. "Someone" assumed that red = positive and black = negative but that is not the always case. Le$$on learned the hard way. Now if I could just get my hands on that "someone"... I would clap my hands. "Mis manos son mis manos."
That business about the boss telling you how to mow the grass each time you come around with the mower: did my wife e-mail you and tell you to tell me that the grass needs mowed. (*I asked her not to do that.) She always stands by the side of the yard every time I come around with the mower... How do I program her and/or the rover with just one program command so the WifePal/ServoPal program isn't repetetively redundant? I'll muse over the program code to see if I can figure it out on my own (for once.) I may need help though.
I hope you're not diabetic. Expect treats soon. The kids and I are very appreciative of all you've done to help us along.
The Parallax servos use a 650 or 850 PULSOUT for full power. If you use a non-Parallax servo, how do you know what PULSOUT value to use? How did you know how to use a value of 500 and 1000 for the "nInp" (and why is it called nInp?) Why did you use a value that's different than 650 and 850?
I remember that, at some point in the past, we had a Vex servo connected to the BOE. When we used the same 650/850 values (or similar values), the Vex servo pulsed erratically. While I understand the basic premise of what makes a servo run (the pulse length and its corresponding value determines the movement) I really don't understand the theory in simple terms. Would you mind clarifying?
Servo operation is based on the pulse width of a regular timing pulse. Typical servo pulse widths are in the range of 1ms to 2 ms (that's 1000us to 2000us.)
PULSOUT 650 effects a pulse width of 1300us, PULSOUT 850 effects a pulse width of 1700us (PULSOUT val * 2).
In the following, my numbers are valid given a general sense, it's concepts and relationships not concretes and strict exactness here. There's not a lot of precision with these hobby servos, they all vary, so when I state some value, in practice that means "about".
With a standard servo, the type with limited range (180deg), 0 deg is achieved with 1000us, 90 deg with 1500us, and 180 deg with 2000us.
With a continuous servo, the spinning sort, the pulse width doesn't vary the position but the direction and the speed. So, full full-bore one direction is 1000us and full-bore the other direction is 2000us; 1500us is a sort of neither one nor the other, where you're very slow and on the verge of neutral.
[Another important aspect is the repetition rate of the position/direction pulses - they must occur regularly: the 20ms rep rate (50 times / sec, 50pps, 50Hz). That much is managed by the ServoPAL, no matter which servo type is used.]
So far as why I used/chose the values that I did in my demonstration and so on, they were based/chosen on the operating premise previously explained. As I stated, every servo is different, within a reasonable range but nonetheless, and given some particular value each will position slightly differently or spin at a slightly different speed. There's a certain tolerance, or range, that you have to deal with, expect, integrate; and when you want to have two servos operating in harmony you have to experiment with (jockey) the values a little.
Given all that, you see, it's not as simple as me popping you a universal value. You guys need to play around with this stuff a little outside the asp-bot program. Just get one of your BoEs without all the other stuff and run the demo with the servos, change the numbers, observe, take notes: find what's appropriate for your servos and your situation. That's what this stuff is all about.
I think that all/most hobby servos operate on this same 1-2ms envelope/premise (Parallax/Futaba, VEX, too.)
Comments
.
EUREKA!
Tonight, thanks to PJ and Dylan's work, the ASP-BOT moves when it lands! We are indebted to PJ for giving us his time and expertise, and to Dylan and PJ for their diligence is seeing this problem through to good (great!) resolution. Please be sure to thank PJ for his help, everyone.
There are a few minor "tweaks" to be made in the program and I'd like Dylan and Andrew to work on these the next time we meet. But we're over the hump as far as getting the ASP-BOT moving once it lands.
PJ said that he'll be monitoring the forum and that he'll assist you as needed. But let's not wear out our welcome, either. He's already given us plenty of his time.
Now for the "bad news": we're out of PINs and there's no place to plug in the second servomotor on the BOE! You've aleady figured out what this means, right? We have to run two wheels with one motor....! Rocketeers, put your thinking caps on. We have a mechanical engineering challenge to solve.
Thanks again for all your help, PJ ~ !
Mr. (Mark) Kibler
:cool:
On fire indeed ~ ! I would say blazing. PJ sure has been a great catalyst for our project and our programmers, and a fine role model of diligence. We couldn't have done it wiithout him. I think an ARLISS T-shirt is the very least we can do. We certainly owe him more than our undying appreciation and admiration. Maybe a new car? Or a new dog? What to get him, what to get him...?!
No small thanks to you too, Sylvie. You've been a stalwart of advice and support and your input and guidance have been invaluable. You've taught these kids a lot, much more than just technical expertise. Consider everything you and Tracy and PJ have role modeled: community service, fine character, humor and humility to name a few. These, in my estimation are more important than a robot, which is simply a vehicle for learning.
Today was rip-roaring fun at Harvard. The SEDS project team all got their Level 1 rockets built... six, 3-inch diameter x 42" tall scratch-built rockets. Our four-hour build time stretched into 6-1/2 hours but we got them all built, painted, and (almost) launch ready. I even built one with them. It has cool, clear plexiglass fins and I named it "Veritas." A good day's work but I had to rush back to New Hampshire for my 7 PM conference call with PJ. We talked for quite some time as we zapped programs and posts to the forum back and forth. But what a day it was today, with a lot accomplished. I'm glad it's Saturday so I can relax.
Do have any 'favorite' TARC teams in the hunt this year?
Mark
Attached are current pictures of the ASP-BOT so that everyone can see how much space is-- and isn't-- available on the clear plexiglass platforms. If we add much more, something may have to be removed. The shortwave transmitter? The CO2 sensor and ADC chip? Maybe trade the big heavy RC battery for alighter lithium battery? Physical space will ultimately make some decisions for us.
Pavel's Mad West teams again, of course.
Man, I haven't been to a rocket launch this year at all yet, other than one little low power launch at a new field back in January. I've got the urge, but no time.
Yeah, Pavel's Mad West TARC teams are as predictable as clockwork. But then, good science should be predicatable. I wonder how many test launches they make before they do their qualifying flights? I'll bet they go through a few thousand Newton-seconds of thrust getting ready.
I haven't launched a rocket since ARLISS either. I've worked on a lot of rockets for other people but nary a launch I've had. The group at Harvard got their Level 1 rockets pretty much finished on Saturday. We did a 6-hour build session and we went from start to finish, including the paint job. You should drop them a PM on the Harvards SEDS e-mail link and ask them how they think it went. I'm buildng a rocket with them, a 3" diameter x 42" beast with clear plexiglass fins. In the spirit of Harvard I'm naming it "Very Fast". Tee hee. We'll see who gets the double entendre.
Mark
:nerd:
The CO2 sensor and ADC are wired and mounted on the rover and it's spitting out data as we speak. I set the CO2 sensor Trip Level at 1000 mV and "input" millivoltage wanders from around 991 to 1050 or so. CO2 mV wanders from around 1392 to1456. Last year the data was tight-- very little variation-- and this wide range of data indicated a loose wire or somethin similar. When we had the system dialed in last year the Trip Level and CO2 mV both stayed within 0.002 or 0.003 or so. But the rover is pretty much assembled, all the major parts or installed, and the software doesn't show any major problems. Whew ~ ! That's good news, and BIG progress.
I've had 5 or 6 kids in my study hall "Advisory" class working on the wiring the last several days-- more unseen faces in the project-- and this may account for the "loose wires" (??) and the variation in data (**See attached screen shot - the third column is input mV and the fourth column is CO2 millivoltage.) When it gets here were work on getting the ServoPal and servos working, and fine tuning the wiring. Thanks again for the servo controller and the wire harness, PJ.
Mark
:cool:
=======================================
Added an hour later:
I swapped out the round CO2 sensor, not the whole module, and the data smoothed out nicely. There is little or no variation in the input millivoltage now (ranges from 1001 to 1004 mV) and the CO2 millivoltage is equally stable. There are no large jumps (e.g. from 1094 to 1164) in the CO2 mV either; the changes are small and stable. Good, good news. Things are wired correctly.
Compare column the data in column 3 and 4 in the second (good) screen shot with the first screen shot. Much less variation. ;-)
Of course I jinxed things. As soon as I took the second screen shot the data started to "stray" again...
Jake and I worked on the program in class today. We cut and pasted from your "ServoPal" program into Main_Prgrm_w_Controlled_Altit_040611_v2p5_PJ.bse (WAMD/ARLISS forum, post #150).
Doggone it, we're close! The servos both activate and rotate in the same direction beautifully and your ServoPal and extender-adapter solution work beautifully! ===>
However, after we added the ServoPal code to the Main_Prgrm_w_Controlled_Altit program and bench tested the rover/program, the servos initiated between the 8th and 9th Zero Count on the debug screen. It did this before the altimeter is even in the vacuum chamber.
It seems that some program code is out of place but we couldn't figure out exactly where. I had 22 other kids in the classroom wanting to "help out", I was trying to teach Jake the logic and the "flow" (the Zen) of the program, and I couldn't concentrate well enough to figure out which line(s) of code were out of order. I'll tackle it again when I get home.
Does any program code jump out at you as being out of place?
Thanks,
Mark, Jake and The Twenty Two
:cool: +
You must push the Reset button after any test or interruption, that's the only way to clear
those ZC and TC counters.
I added a couple of Stop commands to the ServoPAL initialisation routine in the program attached.
I'll see how you're doing when I get home later this afternoon.
It seems that maybe you got caught up with "the 22" and didn't push the Reset button?
[Push the BoE Reset button.]
It wouldn't hurt to issue some STOP commands to begin with. Just to make sure that it's stopped from the beginning, so I kept them in the .BSE attached to this post.
There's no reason for the Servos to Go without being commanded to -- TC > 5, ZC > 8 is the only way that is possible.
PE -- You still have the DEBUG line in the Main_DO..LOOP (that should beomitted from the final version). You should be able to read the status of TC and ZC. When/once TC = 6 and ZC = 9 then the servos will turn.
I modified the 'Movement' subroutine so that it will only get called once, from that point on it will keep rolling ("as per" the ServoPAL plan).
PJ,
You were right in your first post. The BOE simply had to be reset after its first start-up/initialization. When it's started on the bench the servos activate when the program reads ZC > 8. When it's reset and put into the bell jar, then when it comes "back to the (virtual) ground" (altitude = 0), the servos kick in perfectly...!
I'll download your new programs and compare them and report back. After dinner that is. Mrs. K has fresh oregeno bread, corn, and mustard and collard greens. If only I could upload the aroma...!
I didn't mean to bother you at work though I appreciated your reply.
More later,
Mark
:cool:
Attached is an operational version of the program, open to interpretation (tweaking, critcism and humor.) It's called "Rover - Launch Ready" because essentially it is, launch ready. It's pretty much the same program that was posted above. If we had to launch tomorrow it would probably do just fine, don't you think?
Now that we're at a good "pause point" I'd like to sit back and examine the program long and hard to get a more complete understanding of how it really works. I'd also like to clean up the code a bit, if you think that will do any good (streamline DEBUG statements, etc.) Or does the axiom, "Leave well enough alone" apply here?
:thumb: <
(This is you Conscience speaking. "When in doubt, leave well enough alone, Mark.")
Thanks ever so much for sharing your time and expertise PJ.
Mark
:nerd:
I've attached your version with a couple of minor Revs:
I'm not going to force the issue. Howbeit, I did make mention of this as comments in
"Movement" and would be much obliged for your leaving that note there.
If you're happy then I can live with it.
.
Blissful would be more precise. Or ecstatic. Or relieved. I have lots of irons in the fire (though I'm sure you do, too) and it's nice to have the light at the end of the tunnel shining on cherubic faces. There are still some relatively minor mechanical things to finish and it's really nice to have programming "done". As you've figured out, while I do understand the basic's of BASIC, programming isn't my forte. My learning curve-- and the kids'-- is becoming more than flat-line though, thanks to some excellent on-line mentoring.
We had a potentially "Oh My Gosh" moment yesterday. I got the 7.2, 4000 mAh battery from "Batteris Plus" and they had soldered wires and a 9-volt battery connector on so we can connect it to the BOE. The wires and the connector were too thick to fit bewteen the 110 V and 9 volt plug-ins on the BOE so we cut the wires and soldered a thinner wire with a different end onto the battery pack's wires. Then we plugged it in. Guess what happened? When the BOE was turned on, nothing (*visible) happened. "Why?" you ask, as I did. Because the damage was already done.
We hadn't noticed that adding the battery end had essentially reversed polarity...! Red was black and black was red. BOING! =====> :thumb: (*moment of instant realization.)
We unplugged it immediately but the damage was done. Thankfully "all" that we fried was the CO2 sensor module, which we had mounted right on top of the rover's platform. That makes the fifth CO2 $en$or we've went through. "Ouch" to the wallet (and please don't tell Mrs. K.) Lesson learned again, the hard way, but the rover runs beautifully after the new COs sensor was added.
Practice at 1:00 today. We'll update you during or afterwards. Any suggestions for us before practice starts, Commander?
*Sung to the tune of "Vaya Con Dios":
"Now the hacidenda's dark, the town is sleeping.
And the time has come to part, the time for weeping.
'Vaya con huevos', compadres... (egss for breakfast)
Yawn,
Mark
:coffee:
I don't know where to begin.
I don't "do" Braille, I "do" heat - for when they feel the heat then they shall see the light.
Don't look at the ServoPAL as some "two-servos from one pin mystery device". Properly understood, it is a servo manager that autonomously oversees as many as two servos.
The asp-bot's mobility (via servos) was/is effected by the states of two status registers; zerocounter (ZC) and thousandcounter (TC). When the ZC & TC thresholds were met then a servo routine ("Movement") would be executed each time the MAWD was polled.
Formerly, with no ServoPAL, to move the asp-bot, it was necessary to run a basic servo routine, subject to servo pulsing and refresh requirements. The result was that the asp-bot would move forward briefly and then exit to the sensor reading functions (the Main:DO..LOOP) whereupon it would come around, necessarily, to execute the Movement routine, again, and so on.
Presently, the asp-bot is equipped with a ServoPAL. The ServoPAL manages the servos. The ServoPAL, a model of obedience and compliance, only needs to be told what to do once and will manage the servos as commanded, till commanded otherwise, with no further oversight.
The ROVER LAUNCH READY program, as it stands, continues to command the ServoPAL with every MAWD poll. If the object is, having landed, to get the asp-bot underway then one should simply command the ServoPAL as appropriate, because the ServoPAL takes over from there (as previously explained.) From that point, it serves no purpose to keep telling it to do the/that same thing, over and over again [emphasis], especially if it's doing what it should already.
(Imagine "the boss" telling you to mow the grass. You start the mower and start pushing it about only to have "the boss" tell you to mow the grass with each pass of the mower across the yard. Same thing.)
Vaquero PJ Sundance,
Hacienda Kibler was hopping this afternoon. Lots of great progress and lots of happy, animated faces. The kids were thrilled to so (y)our rover ramble along the ground like a caffeinated chipmunk. It (the rover, not the caffeine) energized and buoyed them and they shifted into a higher plane of excellence because of it. Thanks.
The last "big" hurdle is that doggone parachute release mechanism. Justin and Jake had two excellent ideas and they came with two full-blown prototypes. Either idea would have worked but the Design Team opted for "The (Rube) Goldsberry Invention." Whether the decision was collective or unilateral is uncertain. Jake (of Goldsberry fame) has a full-sized prototype made of Legos and Lego motors, and two of our rover wheels, to work with. I'm eager to see what they end up with but I'm certain it *will* work.
Ah yes, the voltmeter. The good news is that we have one. That not-so-good news is that "someone" didn't use it to check polarity before installing the battery. "Someone" assumed that red = positive and black = negative but that is not the always case. Le$$on learned the hard way. Now if I could just get my hands on that "someone"... I would clap my hands. "Mis manos son mis manos."
That business about the boss telling you how to mow the grass each time you come around with the mower: did my wife e-mail you and tell you to tell me that the grass needs mowed. (*I asked her not to do that.) She always stands by the side of the yard every time I come around with the mower... How do I program her and/or the rover with just one program command so the WifePal/ServoPal program isn't repetetively redundant? I'll muse over the program code to see if I can figure it out on my own (for once.) I may need help though.
I hope you're not diabetic. Expect treats soon. The kids and I are very appreciative of all you've done to help us along.
Vaya con queso mi amigo. Hasta manana,
Pepe
:cool:
The Parallax servos use a 650 or 850 PULSOUT for full power. If you use a non-Parallax servo, how do you know what PULSOUT value to use? How did you know how to use a value of 500 and 1000 for the "nInp" (and why is it called nInp?) Why did you use a value that's different than 650 and 850?
I remember that, at some point in the past, we had a Vex servo connected to the BOE. When we used the same 650/850 values (or similar values), the Vex servo pulsed erratically. While I understand the basic premise of what makes a servo run (the pulse length and its corresponding value determines the movement) I really don't understand the theory in simple terms. Would you mind clarifying?
Thanks,
Mark
Servo operation is based on the pulse width of a regular timing pulse. Typical servo pulse widths are in the range of 1ms to 2 ms (that's 1000us to 2000us.)
PULSOUT 650 effects a pulse width of 1300us, PULSOUT 850 effects a pulse width of 1700us (PULSOUT val * 2).
In the following, my numbers are valid given a general sense, it's concepts and relationships not concretes and strict exactness here. There's not a lot of precision with these hobby servos, they all vary, so when I state some value, in practice that means "about".
With a standard servo, the type with limited range (180deg), 0 deg is achieved with 1000us, 90 deg with 1500us, and 180 deg with 2000us.
With a continuous servo, the spinning sort, the pulse width doesn't vary the position but the direction and the speed. So, full full-bore one direction is 1000us and full-bore the other direction is 2000us; 1500us is a sort of neither one nor the other, where you're very slow and on the verge of neutral.
[Another important aspect is the repetition rate of the position/direction pulses - they must occur regularly: the 20ms rep rate (50 times / sec, 50pps, 50Hz). That much is managed by the ServoPAL, no matter which servo type is used.]
So far as why I used/chose the values that I did in my demonstration and so on, they were based/chosen on the operating premise previously explained. As I stated, every servo is different, within a reasonable range but nonetheless, and given some particular value each will position slightly differently or spin at a slightly different speed. There's a certain tolerance, or range, that you have to deal with, expect, integrate; and when you want to have two servos operating in harmony you have to experiment with (jockey) the values a little.
Given all that, you see, it's not as simple as me popping you a universal value. You guys need to play around with this stuff a little outside the asp-bot program. Just get one of your BoEs without all the other stuff and run the demo with the servos, change the numbers, observe, take notes: find what's appropriate for your servos and your situation. That's what this stuff is all about.
I think that all/most hobby servos operate on this same 1-2ms envelope/premise (Parallax/Futaba, VEX, too.)
:cool:
M. Kibler