It is sometimes helpful to jettison excess baggage in order to reach greater heights. Programs have a way of carrying along usless stuff that is left over from earlier efforts. It is taking up space, and in the Stamp BS2 it is nice to keep a big chunk free when you really need it. I looked over the Sensirion code. The following are suggestions.
Delete the following:
Heater_On: and the instructions after it that are commented out. You will not use the heater.
Heater_Off: and the instructions following it up to and including the STOP
tF = soT ** 11796 - 400 delete this line only. You are not using the Fahrenheit temperature.
SHT_Write_Status: delete the entire subroutine, up to and including the next RETURN. Not being used.
SHT_Read_Status: delete the entire subroutine, up to and including the next RETURN. Not being used.
SHT_Soft_Reset: delete the entire subroutine, up to and including the next RETURN. Not being used.
Finally, I would simplify the SHT_Wait: subroutine as follows. This is code from the SHT_Wait: label and the RETURN that follows it. Ask if you have questions or concerns. This should free up quite a few bytes for more important innovations!!
' wait for device to finish measurement (pulls data line low)
' timeout after ~1 second
SHT_Wait:
INPUT ShtData ' data line is input
toDelay=512 ' about one second
DO UNTIL ShtData=0 OR toDelay=0 ' until sht finishes or pbasic times out.
toDelay=toDelay-1
PAUSE 1
LOOP
RETURN
Andrew, Tim, Tyler, Mollie, Anna, and Christopher,
· Are you getting all of this? How's·your programming·coming along? I'll reprogram my robot when I get home after school this afternoon and I'll·post to the forum this evening.·I sense that we're almost there...!
I simplified the SHT_Wait subroutine as suggested. But when it's run as below it generates temperatures and humidity data that obviously can't be accurate: 653, 1224 (or something like that.) It repeats the same sequence of numbers,·and the program runs as before.
When I 'commented out' the command···'OR toDelay=0·· or when·you·change the value to anything other than '0', it runs as before, recording data and running the motors. I have no idea why, and there's still no data capture from the robot unless we push the black reset button. The program is still 'hanging up' in·the same spot.
Do programmers go cuckoo very often (because this is driving ME cuckoo!····· ) I feel so at a loss that all I can do is add·the program updates, read as much as I can, and then revert back to simply trial-and-error, deleting and adding in the hopes that I'll somehow get the right command in the right spot. But since one comma in the wrong place, or one misplaced parentheses can send a program into a tither, I doubt that my trial-and-error methods will result in much. But we move ahead nonetheless, right?
·· Attached is the 'New_Rocket_Robot.bs2' program (Phil's program from a few posts ago) with the deleted command lines suggested by Tracy, and with the modified SHT_Wait subroutine (see my previous post and note.)·The program still·"hangs up" in the same spot as before, and it only captures data when it's running from the robot if the black resetbutton is pushed.·The motors run fine, at the right time, and data feed/data capture is A-OK.
Yours in confusion and bliss,
Mark
PS - There's a FULL LUNAR ECLIPSE TONIGHT from about 9:30 to 11:30 EST!
Ah, sorry about the toDelay bug. The explanation is simple. The variable toDelay is a byte, but I was thinking it was a word when I assigned it a value of 512. But assigning a value of 512 to a byte makes that byte equal to zero--It simply discards the high bits of binary 1000000000 and makes it 00000000. So the {DO UNTIL ... toDelay=0} timed out right away because toDelay was zero, not 512.
The solution you came up with is fine, so long as the Sensirion continues to work properly, as it most likely will. However, it is an issue of robust programming. The timeout is there in case something happens, so the program can keep running and logging something and doing its other actions even if the Sensirion never comes down with ShtData=0 to break out of the loop. The fix is simple. Put the OR toDelay=0 back in, and change the initial value to toDelay=255 instead of 512. The new SHT11 sensor will complete the conversion within that timeout limit.
This has nothing to do with the initialization of the Vinculum memorystick data logger. Yes, those sorts of things can drive you cuckoo. However, in order to make the guesses more educated, try reading more of the technical docs and the example programs (students?). Try the example programs and experiment with them.
My suspicion about the logger initialization is that there is garbage present in the Vinculum receive buffer when it starts up. I notice that the DataloggerTest1.0.BS2 program from Parallax purges the data buffer even before going into the "E" synchronization routine, but your routine is not doing that. I don't have the device though, to try it.
Tracy said...
My suspicion about the logger initialization is that there is garbage present
in the Vinculum receive buffer when it starts up. I notice that the DataloggerTest1.0.BS2
program from Parallax purges the data buffer even before going into the "E" synchronization
routine, but your routine is not doing that.
I'm pretty sure that you've gotten to the root problem with the Vinculum initialization issue
both in Mark's program and mine.
Since I had left out the call to Purge, it explains why I needed extra code to keep the
Vinculum from hanging in an infinite loop at start up.
All my patch did was to perform the Purge function, albeit it a roundabout fashion.
Thanks.
phil
Post Edited (phil kenny) : 2/21/2008 2:11:41 PM GMT
In the interest of moving forward a bit I've taken the liberty of implementing Tracy's
excellent suggestion of including the GOSUB Purge code as well as the Vinculum
initialization code from The Parallax demo program.
The revised code, which compiled without any syntax errors, is attached.
Note however, that the movement command code still has major problems.
Many GOSUB statements without corresponding RETURN statements.
Also, the final statement in the movement code is GOSUB main2. Main2
is not a subroutine, but rather the label at the very top of the program.
This area needs attention
Tracy, Phil, Bruce, Mike, Andrew, and other friends,
··We've made a breakthrough, I think! I went back to an earlier working version of the program·like Tracy suggested, then deleted and added·most of the commands that Phil suggested. I didn't get to them all yet Phil,·and we'll continue to slooooooowly delete and add them·if·everyone·will continue to guide us along. Let's 'cut the dead wood' (or 1'sand 0's as the case might be.)
I worked at this for a while, with marginal results, so I went back to some tech specs and did some more reading like Tracy and Bruce suggested. I went back·at it after dinner with a full belly and a (somewhat) clear head, then began to "try" (as in trial-and-error) some possible solutions that I·had read about.·A·"EUREKA"·moment came when I added a·5-second 'PAUSE 5000' command·in the 'Check drive:' subroutine. That was where the Datalogger and flash drive had been 'hanging up' when they tried to reinitialize directly from the·robot. Though the PAUSE·seems long, that's·about how long it takes·the flash drive to finish flashing (initializing?) I changed the PAUSE 5000 command to PAUSE 4000, and nothing happens, and·I think that's because the flash drive is still initializing as the program is trying to run the next subroutine (?) In any event, the PAUSE 500 allows it time to 'reboot', and now the· program DOES run directly from the robot!···· With your help, maybe we can get it to initialize as fast from the robot as it does when 'booted' directly from the computer.
I'm sure there's a way to make it work even better (if there is, it'll take me a lonnnnnnnnnnng time to figure it out. But we got there, guys!THANKS! We'll continue to fine-tune the program as you continue to guide us toward the finish line.·Please keep posting·your debugs, suggestions, and critiques because this is one heck of an education for both (actually all seven of) my students and I. If you would, please review and run the attached updated program (to be sure it runs correctly at your end!) and offer suggestions on how·we can·make it run even better. Then... where will we go from here?! We make one heck of a team, I think.
The time required for the flash drive to boot up when power is applied will be much longer than the time it takes when you press the reset button. When the reset button is pressed, the power is already stable on the flash drive and it will already have gone through the power up part of its initialization. I think Andrew said that the power is applied when a dowel is pulled out of a phone jack. Is that what you are talking about when you say "initialize directly from the robot"? The power-up initialization is always going to take the longer time. If it is "too long" in terms of the mission, you will have to figure out some way to apply power sooner.
Forgive me for interjecting here, but I smell a possible presumption here. I'm not sure whether we know or not if the flash drive and carrier board are powered from different power sources, or whether they are powered from the same power source.
I saw ONE 9-volt battery in the pictures supplied earlier, but I'm not sure that was the only battery on the robotic platform. If someone from the team could confirm that, one way or the other, that would be most helpful.
The reason this makes a difference is in the power-up timing sequences that Tracy just mentioned. I gather Tracy is under the impression that there are two sources of power, but I don't want to put words in anybody's mouth here. That's just the way Tracy's post reads to me. FWIW, I had always presumed there was only one source of power, that single 9-volt battery that I saw in the pictures.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
··· Here's the 'power up' sequence when the program is started directly from the robot. The power supply is one 9-volt battery. Bruce suggested we·use a 9-volt lithium-ion battery for longevity.
1) Parallax board (a.k.a. the robot) switched to '0' position.
2) The nylon dowel pin is·inserted in the 'headphone jack.'·It's essentially·an on-off swtich.
3) Parallax board (robot) switched to '2' position, then laoded into the rocket's payload bay.
4) When the nylon dowel pin is pulled, the robot powers up and the data logging and ground movement sequence begin.
How does the program/sequence look to you at this point? Do you see a better and/or quicker way to get the Datalogger to initialize other than a 5 second (5000) PAUSE? At this point it does do what we want it too, even though initialization is 'slow' (5 seconds.)
Andrew····Take note of the steps above because you will·be writing·a comprehensive,·easy to read, step-by-step·"Pre-flight arming sequence"·for the Flight Readiness Review/Report (FRR) as required by NASA.
·· So what are the options for "applying power sooner"? We had considered·using a timed sequence that would start when the rocket goes on the launch pad (i.e.·program starts 10 minutes after we flip an 'on' switch.) But the big unknown is exactly·how long will the rocket be on the pad before it's launched? It could be 5 minutes, or 25 depending on·wind; whether other teams are ahead of us in·launch order; aircraft overhead, etc. Last year our rocket sat on the pad, armed, fro·almost·30 minutes before it was launched...! So Bruce's suggestion to use a lithium-ion battery is well taken.
What force exactly is it that pulls out the dowel pin? The dowel pin is inserted in the headphone jack, and I am imagining a string coming off the dowel and attached to the nosecone, and when the nosecone flies off, it pulls out the dowel and starts the robot's mission. Is that anywhere near correct? When is the robot supposed to start taking data? During the flight, or during the parachute descent, or only after it hits the ground?
My inclination would be to put the robot into SLEEP mode on the launch pad, but powered on. Did you know that the Stamp can take NAPs and draw only microamps of current, waking periodically to check status? A sensor for vibration (like the MSI sensor that Parallax sells) might be a candidate for activation. Or a tilt switch, like the Memsic accelerometer, or just a ball rolling in a tube. But there is a catch--Of course. The peripherals (servo and logger) might have to be turned off during that interval in order to conserve power. The Stamp would control an electrical switch to turn on the power to the peripherals when the time comes.
Do you have a power budget? That should be an important chapter in your Flight Readiness Report! How much current does the Stamp draw? The flash drive when running and idle? The servos when running and idle? You can glean that information from the data sheets and confirm it with measurements. Then estimate the ratio of running to idle time for each device. From that you can justify the readiness of the battery power supply to complete the mission.
Just as an aside, if Mark purchased the exact 9-volt lithium battery I recommended, it has an ampacity of 1200 mAH. The battery I suggested was an Ultralife U9VL. Here is all the technical information from the Ultralife web site: http://www.ulbi.com/datasheet.php?ID=U9VLBP
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
"The dowel pin is inserted into the headphone jack... and a string coming off the dowel·is attached to the [noparse][[/noparse]inside of the rocket]... When the robot and parachute are ejected from the rocket, [noparse][[/noparse]the force pulls the dowel out of the jack, activating the robot] and starting·the robot's mission."
How does a SLEEP command work? What activates it? Is it a timed command (like 'SLEEP FOR 10000, NEXT)? As the program is currently written, the robot and Datalogger will (should?!) activate about 5 seconds (PAUSE 5000) after the robot is ejected from the rocket. Since descent time is 2-3 minutes or so, an initial·5 second pause at ejection is nominal. Remember that we have a second, independent humidity Datalogger (the ASP, or air sampling probe)·in the nose cone. It is NOT deployed and it's sole purpose is to gather data from lift-off until we recover it. The robot is more imporant because it logs baseline data (literally on the ground), in flight, and after it lands.
Ideally we'd like both units running throughout the entire flight sequence so we can cross-check data after touchdown. It seems unlikely at this point that we will activate the humidity/movement program on the robot before take-off (because we don't want the movement sequence to activate inside the rocket prematurely!) we're thrilled·that teh robot will 'hit' (we hope not!) the ground running AND record data at this juncture.·But... this SLEEP command sounds interesting. Tell us more! How does the currrent progarm look to you?
Usually when someone new comes onboard the Stamp Forum, we recommend downloading and reading the BASIC Stamp Syntax and Reference Manual, which can be found here as the fifth item: http://www.parallax.com/tabid/440/Default.aspx .
I guess in our collective excitement to help with this project we may have failed to mention this to you earlier. Better late than never, as they say.
Another handy reference is the PBASIC Help file which can be seen by hitting the following areas in the PBASIC IDE once it's active: Help => Contents => PBASIC Reference. That will open the help file and you will see a summary of PBASIC Commands and PBASIC Compiler directives. Click on any of them to see a complete explanation of each command or directive.
The PBASIC Commands NAP, SLEEP, PAUSE and other similar commands can all be found therein. If you have any trouble understanding any of them, just let us know.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
·· Thanks for the post. The PBASIC reference/help screen is spectacular, a plethora of information (and it was right before our eyes!) I wan't sure what·'IDE' meant but I found it anyway. There are lots more commands than I expected; and the other areas of the help screen give some great examples of how to sequence the various commands. Is it feasible to even consider adding a Parallax accelerometer, to start the robot's program sequence somewhere in the flight, before deployment?
Mark
Andrew and Tim: Be sure to click and check out the 'help' button when you have the Parallax program window open. Then·click on 'contents' and browse to your heart's content... or content as the case might be (the word is pronounced two different ways!)
One thing that still has me a bit concerned is this dowel-in-the-headphone-jack connection. My specific concern is whether we need to be concerned about possible contact bounce (multiple untimely resets) and what to do about it, if so.
I visualize the dowel popping out, and the contacts going S-P-R-O-I-N-G, snap, and then doing it again. How's that for a visualization
Thoughts or comments from all are welcomed, if you think this is a potential issue.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Mr. Kibler,
I actually already have the full PBASIC·reference printed out. I guess I'll put it in my SLI binder...
-Andrew
Mark in NH said...
Andrew and Tim: Be sure to click and check out the 'help' button when you have the Parallax program window open. Then·click on 'contents' and browse to your heart's content... or content as the case might be (the word is pronounced two different ways!)
One thing that still has me a bit concerned is this dowel-in-the-headphone-jack
connection. My specific concern is whether we need to be concerned about
possible contact bounce (multiple untimely resets) and what to do about it, if so.
Or worse yet, if when the dowel is yanked out, the power circuit was miswired
and the Stamp and robot never powered up at all.
Testing the final assembly well before the actual launch may be prudent.
I didn't have time during the week to look at the latest version of the program that Mark posted (Rocket_Robot_IT_RUNS_February_21.bs2 ) , or to compare it with the additional purge routine and comments that Phil posted (New_Rocket_Robot_with_Tracy_HeaterOff_changes-Feb.20a.bs2). But I''d like to take a a look at it before your Sunday meeting. Have you made further changes? Also, have you prepared a schematic or block diagram of your project, showing how the sensors and actuators are attached to the BOE-BOT?
It looks to me like the movement sequence (servo operation) starts immediately when the dowel is pulled, even during the parachute descent. Ideally it would wait until it lands.
I don't see any big problem with the scheme to pull out the dowel. That is pretty clever, really.
But I do think it would be nice to be able to collect data on the way up. Leave the dowel and use it only to apply power to the servo system (and as a deployment signal to the Stamp. The Stamp, sensors and data logger would operate continuously, using the Stamp SLEEP command to reduce power. It should be possible to do that with an average urrent consumption of less than 5 milliamps, With the lithium battery Bruce suggested, its 1200 milliamp hour capacity projects to a 240 hours, leaving plenty for servo operation after landing. A standard alkaline capacity is around 600 milliamp hours.
The accelerometer would be an interesting and practical addition to the project. It would be interesting to log the data to look at later, and also it would be a means to detect the launch, the parachuting, and the landing events, as well as bumps on the ground.
· Yes, we've discussed the possibility that the dowel might 'wiggle' during flight causing 'contact bounce' and multiple untimely resets. There will be 12-15 gees of acceleration force at liftoff for certain, and less when·a small drogue parachute deploys a mile up... lots of not-so-small·'bumps' from liftoff until touchdown.·I agree that we have to be sure the wiring is correct, and the soldering robust. I just want to be sure that robot powers up at all.
Tracy suggested 'ground testing' and we'll hopefully start tomorrow. It's part of the NASA requirements; more importantly, it's prudent. We'll probably connect the parachute to the robot, arm the robot·as though we're preparing for launch (put the dowel rod in a slide the switch to "2", then drop·the apparatus·from the 2nd floor window of the school (last year we dropped if off of a DAM. It was windy that day and we had to chase it to avoid a literal 'splshdown!) We'llpull the dowel out as we chuck the robot and·the parachute into the air. Stay tuned for detail.
Tracy- The latest verison of the program (Rocket_Robot_IT_RUNS, below) is unchanged. It's the best 'working' program so for, though I'm sure it could use some polish. I still like this idea of a SLEEP command. As I understand it then, we could 'SLEEP' the servos but arm the data collection subroutine on the launch pad? That sounds real promising! How would the servos know when to 'WAKE UP'? What would activate that subroutine?
All - One final thought (actually, a question): We're running out of EEPROM space on the stamp (it is on the stamp, right?) Short of deleting or shortening program lines/commands, how do we get more space so we can write and run a longer program?·Does Parallax $ell·a different $tamp with more EEPROM·memory?
Mark,
You can't really expand the program memory of a Stamp. There are other Stamp models with larger EEPROMs, but they're divided into 2K byte "slots". It's possible to segment some programs into pieces that can be placed into different "slots", but it's awkward. You can't call subroutines in one slot from a program in another slot. I would suggest commenting out DEBUG statements where you can, shortening diagnostic messages, etc. They take up surprising amounts of space. You could, for example, put the sensor reading and logging code into one slot and the movement code into another slot and have each slot finish its work by RUNning the program in the other slot so they'd go back and forth alternating functions (read the description of the RUN statement in the manual or help file).
You can regain quite a bit of code space by making the DEBUG
statements at the start of your program much shorter, or even
eliminating them. However, you should include one that identifies
the current version of the code being executed.
As Mike noted, there are other versions of the Stamp have more
EEPROM memory, but getting code to run correctly in multiple slots
is challenging, to say the least.
It should be possible to reclaim quite a bit of eeprom space, by eliminating or shortening the debug messages, and by removing the unused subroutines in the SHT area and in the motion area, and by tightening up here and there. I see your <Rocket_Robot_IT_RUNS_February_21.bs2 > had the eeprom 99% full!
To show you what I mean, I've attached a program version that trims the fat and gets it down to 58% full. I took out the superfluous subroutines in the SHT code that I had mentioned, and I condensed the RH and temperature measurement. And I took out the duplicate forward2 and backward2 subroutines that PAR had pointed out earlier in the thread. And the DEBUG statements are left only at places where the program might get stuck. The program compiles fine, but I don't know if it will have problems with the flash drive. More work needed on that.
Another big suggestion: You will see that there is now one MAIN loop, all in one place. No more "main1" and "main2". It loops around taking RH and tC readings, storing them on the flash card, and going through the ground travel motions and then does it again. In the earlier version of the program, there were as Phil pointed out a lot of GOSUBs without RETURNs in the motion segment. This MAIN loop may not be exactly what you want. But at least there is more space avaiable to play with.
It is true that there are other Stamps with lots more memory. I am a big fan of the BS2pe. It is made for data logging and has enough eeprom that you might even be able to get along without the flash drive. The BS2pe has 32 kbytes total, and that is a lot of data points.
· Thanks for the posts and for the update program and subroutines. I'll have Andrew and Tim download them and try them out in about 45 minutes when practice starts. WOW! Hard to believe that the EEPROM memory was 99% full and that you were able to 'whittle' it down to 58%, Tracy. Thanks! I'm eager to see what it looks like and runs like now.
Is the BS2pe stamp taht you mention 100% compatible with the BS2 stamp? Are they directly intechangeable (without major hardware changes, rewriting the program, etc.) Could we just pop the BS2 out and the BS2pe in if we were to get one?
Here's an update, fow what it's worth. Maybe you guys can interpret what it means. Remember when I said that I added a PAUSE 5000 to allow the system initialize, and now the program·initializes and runs·great directly from the robot? After·formalizing a boot-up sequence, then CHANGING the PAUSE 5000 to PAUSE 1000, it still runs. I think before that maybe we were short-circuiting (??) the initialization process when we tried to boot the robot with the serial cable still attached to the computer. Here's the boot-up sequence that seems to work every time, with a PAUSE 5000 or a PAUSE 1000 (or anything in between, or >5000.) Any value <1000 and the 'bot won't boot...!
1) Uploadprogram from computer to robot with serial cable. Run program to make sure it uploaded.
2) Shut robot off by sliding switch to '0'.
3) Disconnect the serial cable.
4) Unplug the 9-volt adapter from the robotand from the wall. Everything is now disconnected.
5) Plug male 9-volt power supply jack into robot (NOT plugged into the wall.)
6) Slide switch from '0' to 2'- *NOTE - When you do this, the green light on the Parallax board (the robot) blinks·on and off quickly one time.
7)·Push black RESET button.
8) Plug power supply into the wall (represents what will happen when the·nylon dowel pin is pulled from the power jack on the robot.)
9) Robot and DataLogger initializes; everything runs (95% confidence interval); life is good!·
Comments
It is sometimes helpful to jettison excess baggage in order to reach greater heights. Programs have a way of carrying along usless stuff that is left over from earlier efforts. It is taking up space, and in the Stamp BS2 it is nice to keep a big chunk free when you really need it. I looked over the Sensirion code. The following are suggestions.
Delete the following:
Heater_On: and the instructions after it that are commented out. You will not use the heater.
Heater_Off: and the instructions following it up to and including the STOP
tF = soT ** 11796 - 400 delete this line only. You are not using the Fahrenheit temperature.
SHT_Write_Status: delete the entire subroutine, up to and including the next RETURN. Not being used.
SHT_Read_Status: delete the entire subroutine, up to and including the next RETURN. Not being used.
SHT_Soft_Reset: delete the entire subroutine, up to and including the next RETURN. Not being used.
Finally, I would simplify the SHT_Wait: subroutine as follows. This is code from the SHT_Wait: label and the RETURN that follows it. Ask if you have questions or concerns. This should free up quite a few bytes for more important innovations!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· Are you getting all of this? How's·your programming·coming along? I'll reprogram my robot when I get home after school this afternoon and I'll·post to the forum this evening.·I sense that we're almost there...!
Mr. Kibler
I have been following along and I have been continuing to debug the problem and trying to get the program to work properly.
-Andrew
·· I made the changes you suggested and deleted:
Heater_On:
Heater_Off:
tF = soT ** 11796 - 400 (this line only)
SHT_Write_Status:
SHT_Read_Status:
SHT_Soft_Reset:
I simplified the SHT_Wait subroutine as suggested. But when it's run as below it generates temperatures and humidity data that obviously can't be accurate: 653, 1224 (or something like that.) It repeats the same sequence of numbers,·and the program runs as before.
SHT_Wait:
··INPUT·ShtData
··toDelay=512
··DO·UNTIL·ShtData=0·OR·toDelay=0
··toDelay=toDelay-1
··PAUSE·1
··LOOP
RETURN
When I 'commented out' the command··· 'OR toDelay=0·· or when·you·change the value to anything other than '0', it runs as before, recording data and running the motors. I have no idea why, and there's still no data capture from the robot unless we push the black reset button. The program is still 'hanging up' in·the same spot.
Do programmers go cuckoo very often (because this is driving ME cuckoo!···
Mark
·· Attached is the 'New_Rocket_Robot.bs2' program (Phil's program from a few posts ago) with the deleted command lines suggested by Tracy, and with the modified SHT_Wait subroutine (see my previous post and note.)·The program still·"hangs up" in the same spot as before, and it only captures data when it's running from the robot if the black reset button is pushed.·The motors run fine, at the right time, and data feed/data capture is A-OK.
Yours in confusion and bliss,
Mark
PS - There's a FULL LUNAR ECLIPSE TONIGHT from about 9:30 to 11:30 EST!
The solution you came up with is fine, so long as the Sensirion continues to work properly, as it most likely will. However, it is an issue of robust programming. The timeout is there in case something happens, so the program can keep running and logging something and doing its other actions even if the Sensirion never comes down with ShtData=0 to break out of the loop. The fix is simple. Put the OR toDelay=0 back in, and change the initial value to toDelay=255 instead of 512. The new SHT11 sensor will complete the conversion within that timeout limit.
This has nothing to do with the initialization of the Vinculum memorystick data logger. Yes, those sorts of things can drive you cuckoo. However, in order to make the guesses more educated, try reading more of the technical docs and the example programs (students?). Try the example programs and experiment with them.
My suspicion about the logger initialization is that there is garbage present in the Vinculum receive buffer when it starts up. I notice that the DataloggerTest1.0.BS2 program from Parallax purges the data buffer even before going into the "E" synchronization routine, but your routine is not doing that. I don't have the device though, to try it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I'm pretty sure that you've gotten to the root problem with the Vinculum initialization issue
both in Mark's program and mine.
Since I had left out the call to Purge, it explains why I needed extra code to keep the
Vinculum from hanging in an infinite loop at start up.
All my patch did was to perform the Purge function, albeit it a roundabout fashion.
Thanks.
phil
Post Edited (phil kenny) : 2/21/2008 2:11:41 PM GMT
excellent suggestion of including the GOSUB Purge code as well as the Vinculum
initialization code from The Parallax demo program.
The revised code, which compiled without any syntax errors, is attached.
Note however, that the movement command code still has major problems.
Many GOSUB statements without corresponding RETURN statements.
Also, the final statement in the movement code is GOSUB main2. Main2
is not a subroutine, but rather the label at the very top of the program.
This area needs attention
phil
Tracy, Phil, Bruce, Mike, Andrew, and other friends,
·· We've made a breakthrough, I think! I went back to an earlier working version of the program·like Tracy suggested, then deleted and added·most of the commands that Phil suggested. I didn't get to them all yet Phil,·and we'll continue to slooooooowly delete and add them·if·everyone·will continue to guide us along. Let's 'cut the dead wood' (or 1'sand 0's as the case might be.)
I worked at this for a while, with marginal results, so I went back to some tech specs and did some more reading like Tracy and Bruce suggested. I went back·at it after dinner with a full belly and a (somewhat) clear head, then began to "try" (as in trial-and-error) some possible solutions that I·had read about.·A·"EUREKA"·moment came when I added a·5-second 'PAUSE 5000' command·in the 'Check drive:' subroutine. That was where the Datalogger and flash drive had been 'hanging up' when they tried to reinitialize directly from the·robot. Though the PAUSE·seems long, that's·about how long it takes·the flash drive to finish flashing (initializing?) I changed the PAUSE 5000 command to PAUSE 4000, and nothing happens, and·I think that's because the flash drive is still initializing as the program is trying to run the next subroutine (?) In any event, the PAUSE 500 allows it time to 'reboot', and now the· program DOES run directly from the robot!···
I'm sure there's a way to make it work even better (if there is, it'll take me a lonnnnnnnnnnng time to figure it out. But we got there, guys! THANKS! We'll continue to fine-tune the program as you continue to guide us toward the finish line.·Please keep posting·your debugs, suggestions, and critiques because this is one heck of an education for both (actually all seven of) my students and I. If you would, please review and run the attached updated program (to be sure it runs correctly at your end!) and offer suggestions on how·we can·make it run even better. Then... where will we go from here?! We make one heck of a team, I think.
Best regards,
Mark
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Forgive me for interjecting here, but I smell a possible presumption here. I'm not sure whether we know or not if the flash drive and carrier board are powered from different power sources, or whether they are powered from the same power source.
I saw ONE 9-volt battery in the pictures supplied earlier, but I'm not sure that was the only battery on the robotic platform. If someone from the team could confirm that, one way or the other, that would be most helpful.
The reason this makes a difference is in the power-up timing sequences that Tracy just mentioned. I gather Tracy is under the impression that there are two sources of power, but I don't want to put words in anybody's mouth here. That's just the way Tracy's post reads to me. FWIW, I had always presumed there was only one source of power, that single 9-volt battery that I saw in the pictures.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
We only have one power source connected to the robot, a single 9 volt battery.
-Andrew
··· Here's the 'power up' sequence when the program is started directly from the robot. The power supply is one 9-volt battery. Bruce suggested we·use a 9-volt lithium-ion battery for longevity.
1) Parallax board (a.k.a. the robot) switched to '0' position.
2) The nylon dowel pin is·inserted in the 'headphone jack.'·It's essentially·an on-off swtich.
3) Parallax board (robot) switched to '2' position, then laoded into the rocket's payload bay.
4) When the nylon dowel pin is pulled, the robot powers up and the data logging and ground movement sequence begin.
How does the program/sequence look to you at this point? Do you see a better and/or quicker way to get the Datalogger to initialize other than a 5 second (5000) PAUSE? At this point it does do what we want it too, even though initialization is 'slow' (5 seconds.)
Andrew··
Thanks, Tracy (and friends)!
Mark
·
·· So what are the options for "applying power sooner"? We had considered·using a timed sequence that would start when the rocket goes on the launch pad (i.e.·program starts 10 minutes after we flip an 'on' switch.) But the big unknown is exactly·how long will the rocket be on the pad before it's launched? It could be 5 minutes, or 25 depending on·wind; whether other teams are ahead of us in·launch order; aircraft overhead, etc. Last year our rocket sat on the pad, armed, fro·almost·30 minutes before it was launched...! So Bruce's suggestion to use a lithium-ion battery is well taken.
Regards,
Mark
My inclination would be to put the robot into SLEEP mode on the launch pad, but powered on. Did you know that the Stamp can take NAPs and draw only microamps of current, waking periodically to check status? A sensor for vibration (like the MSI sensor that Parallax sells) might be a candidate for activation. Or a tilt switch, like the Memsic accelerometer, or just a ball rolling in a tube. But there is a catch--Of course. The peripherals (servo and logger) might have to be turned off during that interval in order to conserve power. The Stamp would control an electrical switch to turn on the power to the peripherals when the time comes.
Do you have a power budget? That should be an important chapter in your Flight Readiness Report! How much current does the Stamp draw? The flash drive when running and idle? The servos when running and idle? You can glean that information from the data sheets and confirm it with measurements. Then estimate the ratio of running to idle time for each device. From that you can justify the readiness of the battery power supply to complete the mission.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/22/2008 6:13:18 PM GMT
Just as an aside, if Mark purchased the exact 9-volt lithium battery I recommended, it has an ampacity of 1200 mAH. The battery I suggested was an Ultralife U9VL. Here is all the technical information from the Ultralife web site:
http://www.ulbi.com/datasheet.php?ID=U9VLBP
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
You were correct when you surmised:
"The dowel pin is inserted into the headphone jack... and a string coming off the dowel·is attached to the [noparse][[/noparse]inside of the rocket]... When the robot and parachute are ejected from the rocket, [noparse][[/noparse]the force pulls the dowel out of the jack, activating the robot] and starting·the robot's mission."
How does a SLEEP command work? What activates it? Is it a timed command (like 'SLEEP FOR 10000, NEXT)? As the program is currently written, the robot and Datalogger will (should?!) activate about 5 seconds (PAUSE 5000) after the robot is ejected from the rocket. Since descent time is 2-3 minutes or so, an initial·5 second pause at ejection is nominal. Remember that we have a second, independent humidity Datalogger (the ASP, or air sampling probe)·in the nose cone. It is NOT deployed and it's sole purpose is to gather data from lift-off until we recover it. The robot is more imporant because it logs baseline data (literally on the ground), in flight, and after it lands.
Ideally we'd like both units running throughout the entire flight sequence so we can cross-check data after touchdown. It seems unlikely at this point that we will activate the humidity/movement program on the robot before take-off (because we don't want the movement sequence to activate inside the rocket prematurely!) we're thrilled·that teh robot will 'hit' (we hope not!) the ground running AND record data at this juncture.·But... this SLEEP command sounds interesting. Tell us more! How does the currrent progarm look to you?
Regards,
Mark and the Rocketeers
Usually when someone new comes onboard the Stamp Forum, we recommend downloading and reading the BASIC Stamp Syntax and Reference Manual, which can be found here as the fifth item: http://www.parallax.com/tabid/440/Default.aspx .
I guess in our collective excitement to help with this project we may have failed to mention this to you earlier. Better late than never, as they say.
Another handy reference is the PBASIC Help file which can be seen by hitting the following areas in the PBASIC IDE once it's active: Help => Contents => PBASIC Reference. That will open the help file and you will see a summary of PBASIC Commands and PBASIC Compiler directives. Click on any of them to see a complete explanation of each command or directive.
The PBASIC Commands NAP, SLEEP, PAUSE and other similar commands can all be found therein. If you have any trouble understanding any of them, just let us know.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
·· Thanks for the post. The PBASIC reference/help screen is spectacular, a plethora of information (and it was right before our eyes!) I wan't sure what·'IDE' meant but I found it anyway. There are lots more commands than I expected; and the other areas of the help screen give some great examples of how to sequence the various commands. Is it feasible to even consider adding a Parallax accelerometer, to start the robot's program sequence somewhere in the flight, before deployment?
Mark
Mr. Kibler
One thing that still has me a bit concerned is this dowel-in-the-headphone-jack connection. My specific concern is whether we need to be concerned about possible contact bounce (multiple untimely resets) and what to do about it, if so.
I visualize the dowel popping out, and the contacts going S-P-R-O-I-N-G, snap, and then doing it again. How's that for a visualization
Thoughts or comments from all are welcomed, if you think this is a potential issue.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
I actually already have the full PBASIC·reference printed out. I guess I'll put it in my SLI binder...
-Andrew
Or worse yet, if when the dowel is yanked out, the power circuit was miswired
and the Stamp and robot never powered up at all.
Testing the final assembly well before the actual launch may be prudent.
phil
I didn't have time during the week to look at the latest version of the program that Mark posted (Rocket_Robot_IT_RUNS_February_21.bs2 ) , or to compare it with the additional purge routine and comments that Phil posted (New_Rocket_Robot_with_Tracy_HeaterOff_changes-Feb.20a.bs2). But I''d like to take a a look at it before your Sunday meeting. Have you made further changes? Also, have you prepared a schematic or block diagram of your project, showing how the sensors and actuators are attached to the BOE-BOT?
It looks to me like the movement sequence (servo operation) starts immediately when the dowel is pulled, even during the parachute descent. Ideally it would wait until it lands.
I don't see any big problem with the scheme to pull out the dowel. That is pretty clever, really.
But I do think it would be nice to be able to collect data on the way up. Leave the dowel and use it only to apply power to the servo system (and as a deployment signal to the Stamp. The Stamp, sensors and data logger would operate continuously, using the Stamp SLEEP command to reduce power. It should be possible to do that with an average urrent consumption of less than 5 milliamps, With the lithium battery Bruce suggested, its 1200 milliamp hour capacity projects to a 240 hours, leaving plenty for servo operation after landing. A standard alkaline capacity is around 600 milliamp hours.
The accelerometer would be an interesting and practical addition to the project. It would be interesting to log the data to look at later, and also it would be a means to detect the launch, the parachuting, and the landing events, as well as bumps on the ground.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· Yes, we've discussed the possibility that the dowel might 'wiggle' during flight causing 'contact bounce' and multiple untimely resets. There will be 12-15 gees of acceleration force at liftoff for certain, and less when·a small drogue parachute deploys a mile up... lots of not-so-small·'bumps' from liftoff until touchdown.·I agree that we have to be sure the wiring is correct, and the soldering robust. I just want to be sure that robot powers up at all.
Tracy suggested 'ground testing' and we'll hopefully start tomorrow. It's part of the NASA requirements; more importantly, it's prudent. We'll probably connect the parachute to the robot, arm the robot·as though we're preparing for launch (put the dowel rod in a slide the switch to "2", then drop·the apparatus·from the 2nd floor window of the school (last year we dropped if off of a DAM. It was windy that day and we had to chase it to avoid a literal 'splshdown!) We'llpull the dowel out as we chuck the robot and·the parachute into the air. Stay tuned for detail.
Tracy - The latest verison of the program (Rocket_Robot_IT_RUNS, below) is unchanged. It's the best 'working' program so for, though I'm sure it could use some polish. I still like this idea of a SLEEP command. As I understand it then, we could 'SLEEP' the servos but arm the data collection subroutine on the launch pad? That sounds real promising! How would the servos know when to 'WAKE UP'? What would activate that subroutine?
All - One final thought (actually, a question): We're running out of EEPROM space on the stamp (it is on the stamp, right?) Short of deleting or shortening program lines/commands, how do we get more space so we can write and run a longer program?·Does Parallax $ell·a different $tamp with more EEPROM·memory?
Regards from the kitchen (homemade pizza!),
Mark
You can't really expand the program memory of a Stamp. There are other Stamp models with larger EEPROMs, but they're divided into 2K byte "slots". It's possible to segment some programs into pieces that can be placed into different "slots", but it's awkward. You can't call subroutines in one slot from a program in another slot. I would suggest commenting out DEBUG statements where you can, shortening diagnostic messages, etc. They take up surprising amounts of space. You could, for example, put the sensor reading and logging code into one slot and the movement code into another slot and have each slot finish its work by RUNning the program in the other slot so they'd go back and forth alternating functions (read the description of the RUN statement in the manual or help file).
You can regain quite a bit of code space by making the DEBUG
statements at the start of your program much shorter, or even
eliminating them. However, you should include one that identifies
the current version of the code being executed.
As Mike noted, there are other versions of the Stamp have more
EEPROM memory, but getting code to run correctly in multiple slots
is challenging, to say the least.
phil
To show you what I mean, I've attached a program version that trims the fat and gets it down to 58% full. I took out the superfluous subroutines in the SHT code that I had mentioned, and I condensed the RH and temperature measurement. And I took out the duplicate forward2 and backward2 subroutines that PAR had pointed out earlier in the thread. And the DEBUG statements are left only at places where the program might get stuck. The program compiles fine, but I don't know if it will have problems with the flash drive. More work needed on that.
Another big suggestion: You will see that there is now one MAIN loop, all in one place. No more "main1" and "main2". It loops around taking RH and tC readings, storing them on the flash card, and going through the ground travel motions and then does it again. In the earlier version of the program, there were as Phil pointed out a lot of GOSUBs without RETURNs in the motion segment. This MAIN loop may not be exactly what you want. But at least there is more space avaiable to play with.
It is true that there are other Stamps with lots more memory. I am a big fan of the BS2pe. It is made for data logging and has enough eeprom that you might even be able to get along without the flash drive. The BS2pe has 32 kbytes total, and that is a lot of data points.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I tried to run a Syntax check and found that the final subroutine
had to be changed slightly.
Change from
to:
phil
Post Edited (phil kenny) : 2/24/2008 2:50:32 PM GMT
· Thanks for the posts and for the update program and subroutines. I'll have Andrew and Tim download them and try them out in about 45 minutes when practice starts. WOW! Hard to believe that the EEPROM memory was 99% full and that you were able to 'whittle' it down to 58%, Tracy. Thanks! I'm eager to see what it looks like and runs like now.
Is the BS2pe stamp taht you mention 100% compatible with the BS2 stamp? Are they directly intechangeable (without major hardware changes, rewriting the program, etc.) Could we just pop the BS2 out and the BS2pe in if we were to get one?
Here's an update, fow what it's worth. Maybe you guys can interpret what it means. Remember when I said that I added a PAUSE 5000 to allow the system initialize, and now the program·initializes and runs·great directly from the robot? After·formalizing a boot-up sequence, then CHANGING the PAUSE 5000 to PAUSE 1000, it still runs. I think before that maybe we were short-circuiting (??) the initialization process when we tried to boot the robot with the serial cable still attached to the computer. Here's the boot-up sequence that seems to work every time, with a PAUSE 5000 or a PAUSE 1000 (or anything in between, or >5000.) Any value <1000 and the 'bot won't boot...!
1) Uploadprogram from computer to robot with serial cable. Run program to make sure it uploaded.
2) Shut robot off by sliding switch to '0'.
3) Disconnect the serial cable.
4) Unplug the 9-volt adapter from the robotand from the wall. Everything is now disconnected.
5) Plug male 9-volt power supply jack into robot (NOT plugged into the wall.)
6) Slide switch from '0' to 2'- *NOTE - When you do this, the green light on the Parallax board (the robot) blinks·on and off quickly one time.
7)·Push black RESET button.
8) Plug power supply into the wall (represents what will happen when the·nylon dowel pin is pulled from the power jack on the robot.)
9) Robot and DataLogger initializes; everything runs (95% confidence interval); life is good!·
More later,
Mark and the Rocketeers·
Just one puzzling question about what you said here:
"5) Plug male 9-volt power supply jack into robot (NOT plugged into the wall.)"
and
"6) Slide switch from '0' to 2'- *NOTE - When you do this, the green light on the Parallax board (the robot) blinks on and off quickly one time. "
Where is the power coming from to light that green LED? Is the battery still connected?
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison