...The only glitch is that is overwrites the previous data with the last data it measures. ...
Does anyone have any suggestions on where we need to change the attached program so it does not overwrite the last data set? Thanks for your replies. This is starting to get fun!
Mark and the NH Rocketeers
Mark, I think the place to start looking is where I suggested earlier --Posted 2/4/2008 8:13 PM (GMT -8)
In this statement, the $07 is a command to the Memory Stick Datalogger
to DELETE the file named 'datafile.txt'. The original purpose for having
this in the code is to start with a clean data file.
If you want to keep the previously recorded data, just comment out
this line.
· Thanks for your post. We 'commented out' the command line that you suggested and... BINGO! We have streaming data capture now! I feel that we are finally getting over the hump, thanks to your and everyone else's time and patience. How do all of you·know so much about programming? Do you do it all day long? How long did it take you to really understand programming well enough so·that you can just look at a program and know where, and how, to fix it? I'm a clever guy and everything but...GEESH! It seems like it could take a looooooooooong time to get even somewhat proficient at programming.
Anyway, (y)our robot now moves; stops; measures humidity and temperature; backs up and turns·(to avoid obstacles); and repeats the sequence, just as we dreamed it would.·Yippee!
We still have other hurdles to cross (like how will we know what altitude each of the data sets is collected at, etc.). But this, to us at least, is real progress. Thanks again for your help. I'm sure you'll see·my students and I·on the forum soon with other questions. We're all learning tons, and it's·starting to·become·fun, and rewarding.
Do keep in mind that the file delete statement is there for a reason. If it's commented out, every time you run the program, you'll write all the new data on the end of any existing data ... without any indication that it's from a new run. That may work for you. You can always delete the data file using your PC before a run (just don't forget).
On the other hand, you probably have a good size flash drive. You can fit a lot of data in 1GB.
·· Yes, I noticed that if the line command Phil mentioned is commented out, 'old' data (from the last time the program runs) remains. The 'new' data is (as you probably already know!) simply added on at the end of the·'old' data file. I tried to muddle through·debugging it·on my own·so that it writes only new data (as packets of 10, etc.·NumSample data points) until after midnight by reading the information he suggested. But sleep prevailed over excitement and I leftshut things down along about 1 AM.
We have rocket team practice today (Sunday) from 12:30 - 4:00 and that's where we'll start. Do you have any suggestions on parsing and writing 'new' data ? Do you have any ideas·on a·relatively simple way that we can correlate·the data with altitude (especially as the robot and nose cone module descend by parachute from 1 mile up?) I know that Parallax makes an accelerometer/altimeter, a GPS module, etc. But that entails more expense(we have virtually no budget except my wallet),·and it adds another layer of programming complexity. We're very open to your suggestions and help, and I'll find a way to get an altimeter(s) if that's what you think the best solution is.·Thanks again, Mike!
Good morning. Mama K says 'breakfast is ready!'
Mark (Andrew, Tyler, Anna, Christopher, Tim, and Mollie)... the NH Rocketeers!
Rocketeers,
Post the current code you're working with and we'll have a look at it to see what's up with the "delete file" statement.
What's wrong with writing one set of data at a time? Is it too slow? It's really convenient for later analysis to have one
dataset per "line" in the file.
A GPS module is not likely to work in that it needs a good signal and that's not available inside the nose cone.
It also may not give you updates often enough to be useful. Options could be: 1) a real time clock, 2) a true altimeter
(air pressure sensor), 3) an accelerometer.
Most RTC chips will give you the time only to the nearest second which may not work for you. Think about it.
On the other hand, during the descent phase, you'll have lots of seconds going by. You should be able to determine
the apogee time, height (visual angle and distance to launch site) and approximate landing time by observation.
If the measurement time is recorded, you can correlate it to estimated altitude.
Parallax doesn't carry air pressure sensors. There are some nice ones available used in the automotive industry,
but you'd need some expertise that your group just doesn't have and would be hard to supply via the forum.
An accelerometer could give you indirect evidence of altitude, but you'd need a good time reference
·· Attached is the current verison of the robot ground movement and humidity sensor program. As we said, it records 'streaming' data, not parsed data (0.21.9,35.4, etc.) for whatever NumSamples we set. Thanks for taking a look at it.
·We actually do have two altimeters/accelerometers mounted in the rocket. Both (primary and back up) are used to deploy a small drogue parachute and the modules at the peak of the rocket's flight. They·also initiate an electrical charge that fires the ejection sequence at 1,200 feet, to deploy the 10-foot main parachute. They both record altitude and flight time and we had considered using them to correlate the humidity data with altitude, as you suggested. That seems like a good starting point. What other options do you see?·Would the Parallax accelerometer serve any practical purpose?
I suspect it will help if you mention what type (manufacturer and model no) accelerometers you are already using. If they're a solid state (MEMS) type like the ones Parallax sells, the chances are quite good that the output from those can be used for data logging purposes.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
Mark,
Please look at what I did in an earlier version. This last one you posted is all messed up and won't work reliably.
The piece labelled "main:" is sort of ok, but you're calling the movement loops (forward, backward, turnclockwise, turncounterclockwise) as subroutines, but they don't have RETURNs at the end of the routines. They each "fall through" to the next, then they fall through to the part of the code that does the measurements and recording (Initialization comment). The first GOSUB in that section is a call to Get_Data which works, then does a RETURN which goes back to the "main:" loop. Anyway, I'm surprised it does anything useful at all. This all is part of the problem with the file getting erased when it shouldn't.
I've rearranged the program. Please look carefully at what I've done and don't put it back the way you had it unless you really understand what's going on and what you're trying to do.
Mike
· The altimeters/accelerometers are Black Sky AltAcc's. They are installed, and they work completely independently of, the Parallax board. All they're used for is to fire a charge that deploy two parachutes at two different altitudes (along with ejecting the robot on it's own parachute.
Mike - Thanks for your post! We'll look at the program carefully, as you suggested, to try and understand at a fundamental level which commands are being called on to run; where; and why they work. Thanks so much for·being patient with us, and·for sticking·with us as we (slowly) work our way toward deeper understanding. We've been programming for all of three weeks now, and as much as it seems like we've 'learned' (to us anyway!), I do realize that there is SO much more to learn.
You're a great teacher, Mike! · Thanks for sharing your wealth of information with us, and thanks for your patience and candor. I can't wait to get home and run the new program. Last night some of the·'rocketeers', and their parents!, were at my house until 9:30 PM (practice started at 12:30 PM!) We were tinkering, talking, and eating, and I was up until·after·midnight again. I love it!
Mark,
When you look at the program, focus in one of four ways:
1) Look at the comments and other documentation of the program (if it's well documented). This should give you a general idea of what the program is intended to do and how it's supposed to do it. Specifically, comments should give you the intention of the programmer as well as notes describing specific details that may not be obvious from looking at the code.
2) Look at the variables, I/O pins, and constants. In particular, look at how the variables are laid out in memory and which ones are shared.
3) Look at the "flow of control". This means labels, GOTOs, GOSUBs, RETURNs, IF / THEN / ENDIFs, FOR / NEXTs, anything that affects the order of execution. While you're doing this, you can mostly ignore what's in between.
4) Look at what's actually done in the little clumps of statements in between the "flow of control" statements.
·· If you would, download the attached program, run it on the robot, then let me know on the forum and by e-mail what it does. I·simply duplicated·the 'forward' and 'backward' line commands to make the robot go the distance we want it to move (even though I'm sure there's a simpler way to make it do the same thing-- sorry, Mike Green, I couldn't figure it out. I tried!) I did learn that the Vex and Parallax servomotors DON'T run the same way with the same program. I'm guessing that they each 'read' the PULSOUT pulses from the Board to the motors slightly differently, on different 'frequencies' ??(*OK, I'll admit it: I'm a rookie and it shows. But I'm trying things, and we're all learning lots!)
Andrew and Tim: be sure to report back and let me, and our friends on the forum, know what the robot does. I think this program runs the ground routine that Tim explained in the Preliminary Design Review. Tyler, be sure to drop of the ASP at my house before you leave for your grandmother's house!
Andrew,·after working at this on and off all day (and trying to build another robot at the same time, and shoveling snow for Mrs. Kibler, the grading sciene essays!) I don't know that it's feasible to try and incorporate·a CO2 sensor on the robot. Now's an excellent time to explain to our friends on the forum what we'd like to do with the CO2 sensor (be sure to include the brand name of the CO2 sensor and a web link where people can access the technical specifications.) As much as I hate to admit it I think we're in way over our heads with the CO2 sensor (programming it, etc.) Remember that I'm also coaching two other TARC rocketry teams. After thinking it through, I think the best·option for the CO2 sensor is to use the PASport module and install it in the nose cone with the ASP (Air SAmpling Probe). We still have lots to do, and the Flight Readiness Review (the report, Powerpoint presentation, and the·video teleconference with NASA) are due in a little over·a month. ut There's tons left to do on the rocket, too, but we're almost there with the robot. Think it through and let me know what you think. Andrew, if you really believe that you CAN figure it out an get it working in a month, I'm 'game' for ordering it. Remember that we have less than $75 left in our budget, and one sensor costs $40 (we would need three.)
Keep up the great work, team!··· I look forward to hearing abck from you. Practice at my·house on Sunday from 1-4 PM. Tim, remember that you have·a practice SAT test scheduled with me right after practice.
Sorry I wasn't on the forum before, the phone lines in my area were working like crazy yesterday. Since I have dialup, I couldn't even get on the internet. Everything is working now, though.
I've thought about the CO2 sensor, which is a IRceL Miniature Infrared Gas Sensors, and I'm not really sure we would want to try (with our current budget, and, time left) to add the IRceL sensor at this point. What does everybody on the forum think? How hard would it be for us to program it in, how much time would it take? Do you think the sensor would even work? We are looking to record the CO2 data as fast as we can (which looks like about 30 seconds) on to our flash drive very similar for what we did with the temperature/humidity sensor. Here is a link to the specifications for the IRceL sensor - http://www.edinst.com/ircel.htm.
Also, Mr. Kibler, I will download and try to run the program you attached to your post today and let you know how it works. I don't have to go to school today because my class is going skiing and I didn't sign up this year.
I downloaded the movement program you attached to your last post. It is very similar to the one I had made, by just duplicating the movement instructions. Everything seems to work just fine, except for the data acquisition portion, because I didn't have a data logger to test it with.
Rocketeers,
I don't think it's a good idea to add any new functionality to your program at this late date as tempting as it may be. This is a good time to test, to make sure what you already have works and works in different circumstances. For example, do you have any idea how long the batteries would last? What happens to the stored data when the batteries quit? You might lose all your data if the program restarts briefly because the batteries became exhausted and the Stamp turned off (as it does when the supply voltage drops too low to function), then the battery voltage rebounded a bit, enough for the Stamp to start up again for a second or two. This might be a good reason to remove the "delete" statement from the program's initialization and plan to erase any existing data file manually with a PC. Make sure you go through your pre-launch checklist and simulated "test flight" to be sure no other surprises turn up.
Mike
It probably is a good idea not to complicate things by adding the CO2 sensor, especially since we have very little time. We will probably end up just adding the PASport CO2 recorder in to the nose cone of the rocket.
You also made a good point about losing data if low batteries cause the Stamp to reset. We originally added the 'delete' statement so we wouldn't mix up our data and get confused. I guess we'll change that back to not delete anything, and we'll just have to make sure no old files are on the drive when we launch the rocket.
I agree with your analysis of our situation: we simply don't have enough time to buy, then figure out how a (non-Parallax brand) CO2 sensor works on a Parallax circuit board. You also bring up some simple but important points I hadn't considered:
1) What happens to the data if the batteries run low or somehow get disconnected in flight. We will take your suggestion and remove the 'delete data' command that runs during initialization.
2) How does the robot run under various, conditions? Our launch is in April in Alabama and so the 'weather' conditions will be different than ambient conditions inside a classroom or (dry) house.
3) How long will the batteries last (and what are the 'best' batteries to use for longevity? (Y)our robot is programmed to run indefinitely (which is until we locate it, the batteries run out, or it drives itself into a swamp...!) Last year, one team's rocket ended up sprawled across the top of a very tall tree, beeping loudly but completely out of reach. Another team's rocket deployed the parachute prematurely (a mile up in the air) and it drifted nearly two miles, into a swamp that had alligators in it (or so we were told.) OUR rocket and robot landed safely, but someone from Redstone Arsenal found our robot (moving fearlessly forward) and tried to shut it off before chucking it into the back of an Army pickup truck! He apparently thought the idler wheel mechanism-- which was installed to count tread rotations and measure distance-- was the 'off' button and so he pushed it. This reset the rotation count to zero! When this didn't shut the robot off he tugged at wires until it did!
This year we're putting a highly visible and colorful notice on the robot's housing that says, "DO NOT SHUT OFF IF FOUND!" Last year we didn't anticipate that someone else other than our team would recover the robot. Now we know that could happen, and so your suggestion of storing the data BEFORE someone shuts the robot off (or if the batteries run down) is an excellent idea.
Can you explain how we can make the robot run twice as long when it goes forward (instead of just duplicating the forward sequence as a 'NEXT' command? Which part of the program command controls 'time forward'? Thanks again!
I tend to agree about not trying to incorporate the CO2 sensor at this point. Nonetheless, I am wondering about having three CO2 sensors on board. What would be the objective?
I've just completed a project that involved a CO2 sensor, not the one you pointed to, but also a dual wavelength device from a different manufacturer (SenseAir). Incidentally, thanks for that link to Edinburgh Instruments. I was not familiar with their products.
The Stamp programming for the sensor we used was trivial, because the sensor had an on-board microprocessor that handled all the drive, signal read, temperature and long term compensation and so forth. All my program had to do was to read the analog voltage and apply some simple math. However, the description of the IRcel you were looking at includes the phrase, " Supporting electronics available from Edinburgh Instruments Ltd", which (in addition to the low price of $40 each) leads me to believe that some additional electronics might be required. Do you have the datasheet and/or application guide? The effort to make it work might quite possibly be a big project for both electronics and programming.
A couple of other points...
• This type of sensor draws a pulse of current when the light sources (IR) turn on. Ours pulsed to around 300 milliamps. So that is another factor to consider in your power budget
• A sensor that relies on passive diffusion (rather than aspiration) will have a relatively slow response time, and the response time will depend on the local air velocity outside.
• The IRcel has a range of 0-5% CO2, and I don't know what the attainable resolution might be. But keep in mind that normal atmospheric concentration is between 0.03% and 0.05%, and continued exposure to levels above 0.1% (1000ppm) is considered unhealthy, and 1% (10000ppm) is quite toxic. Exhaled air is around 0.45%. The sensor I'm using in my project covers 0 to 5000 ppm (0 to 0.5%).
...
Can you explain how we can make the robot run twice as long when it goes forward (instead of just duplicating the forward sequence as a 'NEXT' command? Which part of the program command controls 'time forward'? Thanks again!
You don't need "forward2" and "backward2". They just duplicate the "forward" and "backward" code. So, instead of calling· GOSUB forward2 and GOSUB backward2, just call GOSUB forward and·GOSUB backward·again, at that same place in the program· where the current "forward2" and "backward2" statements are located (and delete the code for the forward2 and backward2 subroutines).
If you want to change the amount of time that the "forward" ("backward") subroutine causes the bot to move forward (backward), change the number of times the "for ... next" block loops. E.g., instead of:
forward: ·· FOR i = 0 TO 240····...··· next
use, for example,
forward: ·· FOR i = 0 TO·480··· ...·· next
That would cause the time spent in the "forward" subroutine to be twice as long.
· Thanks for the feedback. I'm interested in your recent CO2 sensor project. You said:
"I've just completed a project that involved a CO2 sensor... a dual wavelength device from a different manufacturer (SenseAir)... The Stamp programming we used was trivial... All my program had to do was to read the analog voltage and apply some simple math."
Can you give us more details onyour Sensair CO2 sensor? How big is it? How much does one cost? I mentioned that we need three; that's because we have two air sampling modules, and we would need one for me to 'bench test.' One Parallax board/ sensor set is on the robot itself, which measures samples in flight AND after it lands (to gather baseline data to compare against atmospheric readings.) The second unit is a Parallax board mounted on a platform that goes inside the rocket's nose cone. We named the second unit the ASP (air sampling probe) and it, too measures atmospheric humidity (and ideally, CO2.) *We thought about naming it the Gaseous Atmospheric Sampling Probe... then thought better of the acronym!
The students I work with range from 7th grade to juniors in high school, and it's alomst a 50-50 split between boys and girls. They come from five different schools·but none are students that I have Monday through Friday (I teach 8th grade science.) Accordingly, the Parallax boards, sensors, etc. are shared by team members who are spread across several different communities (hence the need for me to have at least one unit to work with and bench test, so I can figure this out, with your and everyone else's help, before we meet for our next practice.) I've bought a lot of the circuit boards, sensors, etc. out-of-pocket (and out of necessity), and we meet Sunday afternoons at my house. One student's mother drives him an hour each way just to participate, a credit to·our endeavours I suppose.
Anyway, I'd like to hear more about·your Sensair CO2 sensor and whether you think it is a viable option for us to figure out within the next month or so. We have our last report and video teleconference to NASA in mid-March (the Flight Readiness Review report) and we have to be, well... flight ready! Thanks again for your post. I'll look for your reply.
·· Thanks for the suggestion to delete "forward2" and "backward2" from the program.·It works fine, as you said it would, using just the forward and backward commands.
However, when I set i = 0 TO 240 to anything greater than 0 TO 250, the motors run indefinitely...? I read through the 'What's A Microcontroller" and it said that some commands are 'limited' (because of the number of pulses sent/received.) But I really didn't understand it too well. Can someone explain, simply, what these commands mean and do:
PAUSE· - Is the a time duration pause (where 1000 is a literal 1 second motor pause)? Or does it refer to a pause (in microseconds?) between electric impusles sent from the circuit board to the motors?
O TO 240 - '0' what? and '240' what? Why do the motors run for an exact amount of time when 0 TO 60, 4 times as long when set to 0 TO 240, but cycle indefinitely when set above 0 TO 250?
I hooked up a Vex servomotor to the Parallax board and, using the same program, the Vex motors run differently (not as long, backwards, with choppy 'pulses', etc.) Why the difference?
Thanks for all your help. You guys are genuises! I bow to your infinite knowledge. ·· <
Me, bowing. But I'm not really green (well I suppose you COULD say that I'm green at programming!)
Mark,
1) Check to make sure that "i" is declared as a word. You can't just change the definition because these variables are shared. There are a few unused word variables that you could use for "i". I think the declared ones go up to W11 (B22/B23). A byte can only hold values from 0 to 255.
2) Read the Parallax Basic Manual for the description of the PAUSE statement. The operand is the time in milliseconds.
3) Different servo motors are different. There's no standard for how much movement or how fast the movement should be for a given control pulse timing except that the center value is approximately 1.5ms (750 for a PULSOUT value) and most servo controllers and servo motors do not use control pulses shorter than about 0.5ms or longer than about 2.5ms.
· So 'PAUSE 500' is a 500 millisecond pause then? Is this pause·a·real 'motor pause' command·(i.e., a pause in the output time between 'run' commands to the motors?) What is the pause between pulses the microcontroller book talks about? I'll go back and re-read it as you suggested. There's so much to read, digest, and·(try to) understand.·Sometimes (as you've seen)·all this·new information gets muddles together and it becomes a bit overwhelming (even frustrating) trying to figure it out solo.
I typed this from the Parallax book, and it works to make the motors run.·But I don't understand why. As I understand it, "i" is a VARiable, but what does 'byte' mean afterwards? Does 'i = 0' mean that the input value (i) = 0?
i·· VAR·· byte
i = 0
FOR·i = 0 to 120
Would the commands (?) below·do exactly the same thing, or are certain words ('i', for example) 'reserved'?
fish·· VAR··· byte
fish = 0
FOR fish = 0 to 120
Is this any different? If so, how, and why?
counter··· VAR·· byte
counter = 0
FOR counter = 0 to 120
Thanks again for the input on the CO2 sensor, Mike.·We have a month or so to get it all dialed in!
and, as you said, this·expands the '0 TO 120' (etc.) command to '0 TO 1000 (or whatever value I entered) so the motors run as long as we want them to. Thanks!
I also tried my own medicine: I changed
····· i···VAR·· Byte····· to ····· i·· VAR·· Word···· then to ····· fish·· VAR·· Word
and it ran! (of course I changed all the instances of "i" to "fish")
I think we'll probably change:
····· i···VAR·· Byte······ to ······motormovementtime· VAR·· Word
so that we start to understand and internalize what the commands really do. Any reason why we shouldn't do this?
Also, if we want to LOOP a 'forward' command, what do we loop UNTIL or WHILE (assuming we want to run two loops, then go to the NEXT command)?
forward:
DO (?)
FOR motormovementtime = 0 TO 120 ·· PULSOUT 15, 650 ·· PULSOUT 13, 850 ·· PAUSE
LOOP UNTIL (WHILE) for two loops???
NEXT
·· We're located in southern New Hampshire, about 10 miles southwest of Concord in the town of Weare. My students qualified to compete in the Team America Rocketry Challenge, or TARC·(www.rocketcontest.org) national finals the past two years. The top 25 teams at the TARC nationals are allowed to submit a (very comprehensive, 75-85 page) proposal to NASA's Student Launch Initiative (SLI) program (http://education.nasa.gov/edprograms/descriptions/Student_Launch_Initiative.html). Of these, only·about 50% of the proposals are accepted. Proposals must·be written for·"a reusable aerospace vehicle designed to achieve a target·altitude of 1·mile, with a student-designed scientific paylaod on board."
The proposal, if accepted, is followed by a NASA-style Preliminary Design Review report, Critical Design Review report, and a Flight Readiness report. Students must also design and build their rocket and payload (in our case, a robot and an air sampling probe) and partcipate in 2, hour-long video teleconferences where NASA engineers question and critique their work. I mentor the team, a menagerie of students from different five schools, on Sunday afternoons, though we 'practice' all week long·through e-mail, forums, etc. It is, to say the least, rigorous, exacting, and time-consuming·work, with a big reward in April: the opportunity to launch our rocket at Marshall Space Flight Center, Alabama!
Where are you located, Bruce? Want to help out with the team?!
...However, when I set i = 0 TO 240 to anything greater than 0 TO 250, the motors run indefinitely...?
Yeah, sorry. As Mike explained, "i", as a byte was a small bucket and can hold integers only as large as 255; changing "i" to be a word-sized bucket means it can hold numbers as large as 64K (approx). You get those maximum byte- or word-sized values because a byte is 8 bits long (so it can represent integers from 0·up to 2 to the 8th power -1), while a word is 16 bits (so it can hold an integer up to 2 to the 16th power -1).
·... Can someone explain, simply, what these commands mean and do:
PAUSE· - Is the a time duration pause (where 1000 is a literal 1 second motor pause)?
Yes --it is a·timed·pause. Time is in milliseconds. But it is your program that is pausing --the motor will stop too because there is no pulseout command being sent to the motor while your program is paused.
Or does it refer to a pause (in microseconds?) between electric impusles sent from the circuit board to the motors?
Yes and no. During a PAUSE the program isn't doing anything else so in effect no signal is being sent to the motor. But, it is PAUSE-ing everything, and not specifically --only-- ·the motors.
O TO 240 - '0' what? and '240' what? Why do the motors run for an exact amount of time when 0 TO 60, 4 times as long when set to 0 TO 240, but cycle indefinitely when set above 0 TO 250?
The FOR ...· NEXT block of program code is being "looped through" 240 (or 60) times. So, the pulseout command is being sent to the motors 240 times before your program moves on (out of the FOR ... NEXT loop) to the next section of the main·program following the GOSUB Forward statement).
So, the·more times you·loop through the pulseout statements, the longer the motor will run.
I hooked up a Vex servomotor to the Parallax board and, using the same program, the Vex motors run differently (not as long, backwards, with choppy 'pulses', etc.) Why the difference?
Different servo. Lots of elements of the servo's circuit and mechanics·can influence its behavior in response to a given series of signals. This is true even within a brand/model of servo.
·· Thanks for the reply and clarification. Yes, I'm catching on····to the fact that a PAUSE between FOR/NEXT commands is a timed pause, where 1000 (milliseconds) = 1 second. But when PAUSE is used inside a FOR/NEXT command (as below) it sometimes wreaks minor havoc on how the motors run. They run 'choppy' if the·PAUSE is long (120, 200, etc. instead of the 20 we're using.)Is the PAUSE below-- inside a FOR/NEXT command-- pausing the motors?
FOR ·· motormovementtime = 0 TO 120 ·· PULSOUT 15, 650 ·· PULSOUT 13, 650 ·· PAUSE 20···
> a value above 100 or so makes the motors run choppy (i.e. pulsate)
NEXT
Comments
PAR
statement:
SEROUT TX\CTS, Baud, [noparse][[/noparse]$07, $20, "datafile.txt", CR]
In this statement, the $07 is a command to the Memory Stick Datalogger
to DELETE the file named 'datafile.txt'. The original purpose for having
this in the code is to start with a clean data file.
If you want to keep the previously recorded data, just comment out
this line.
You can find the full command set in this file:
http://www.parallax.com/Portals/0/Downloads/docs/prod/comm/VDAPFirmwareSpec.pdf
Look at pages 10 and 11.
phil
· Thanks for your post. We 'commented out' the command line that you suggested and... BINGO! We have streaming data capture now! I feel that we are finally getting over the hump, thanks to your and everyone else's time and patience. How do all of you·know so much about programming? Do you do it all day long? How long did it take you to really understand programming well enough so·that you can just look at a program and know where, and how, to fix it? I'm a clever guy and everything but...GEESH! It seems like it could take a looooooooooong time to get even somewhat proficient at programming.
Anyway, (y)our robot now moves; stops; measures humidity and temperature; backs up and turns·(to avoid obstacles); and repeats the sequence, just as we dreamed it would.·Yippee!
We still have other hurdles to cross (like how will we know what altitude each of the data sets is collected at, etc.). But this, to us at least, is real progress. Thanks again for your help. I'm sure you'll see·my students and I·on the forum soon with other questions. We're all learning tons, and it's·starting to·become·fun, and rewarding.
Regards from NH,
Mark and the Rocketeers
·
On the other hand, you probably have a good size flash drive. You can fit a lot of data in 1GB.
·· Yes, I noticed that if the line command Phil mentioned is commented out, 'old' data (from the last time the program runs) remains. The 'new' data is (as you probably already know!) simply added on at the end of the·'old' data file. I tried to muddle through·debugging it·on my own·so that it writes only new data (as packets of 10, etc.·NumSample data points) until after midnight by reading the information he suggested. But sleep prevailed over excitement and I leftshut things down along about 1 AM.
We have rocket team practice today (Sunday) from 12:30 - 4:00 and that's where we'll start. Do you have any suggestions on parsing and writing 'new' data ? Do you have any ideas·on a·relatively simple way that we can correlate·the data with altitude (especially as the robot and nose cone module descend by parachute from 1 mile up?) I know that Parallax makes an accelerometer/altimeter, a GPS module, etc. But that entails more expense(we have virtually no budget except my wallet),·and it adds another layer of programming complexity. We're very open to your suggestions and help, and I'll find a way to get an altimeter(s) if that's what you think the best solution is.·Thanks again, Mike!
Good morning. Mama K says 'breakfast is ready!'
Mark (Andrew, Tyler, Anna, Christopher, Tim, and Mollie)... the NH Rocketeers!
Post the current code you're working with and we'll have a look at it to see what's up with the "delete file" statement.
What's wrong with writing one set of data at a time? Is it too slow? It's really convenient for later analysis to have one
dataset per "line" in the file.
A GPS module is not likely to work in that it needs a good signal and that's not available inside the nose cone.
It also may not give you updates often enough to be useful. Options could be: 1) a real time clock, 2) a true altimeter
(air pressure sensor), 3) an accelerometer.
Most RTC chips will give you the time only to the nearest second which may not work for you. Think about it.
On the other hand, during the descent phase, you'll have lots of seconds going by. You should be able to determine
the apogee time, height (visual angle and distance to launch site) and approximate landing time by observation.
If the measurement time is recorded, you can correlate it to estimated altitude.
Parallax doesn't carry air pressure sensors. There are some nice ones available used in the automotive industry,
but you'd need some expertise that your group just doesn't have and would be hard to supply via the forum.
An accelerometer could give you indirect evidence of altitude, but you'd need a good time reference
·· Attached is the current verison of the robot ground movement and humidity sensor program. As we said, it records 'streaming' data, not parsed data (0.21.9,35.4, etc.) for whatever NumSamples we set. Thanks for taking a look at it.
·We actually do have two altimeters/accelerometers mounted in the rocket. Both (primary and back up) are used to deploy a small drogue parachute and the modules at the peak of the rocket's flight. They·also initiate an electrical charge that fires the ejection sequence at 1,200 feet, to deploy the 10-foot main parachute. They both record altitude and flight time and we had considered using them to correlate the humidity data with altitude, as you suggested. That seems like a good starting point. What other options do you see?·Would the Parallax accelerometer serve any practical purpose?
Thanks again!
The NH Rocketeers
I suspect it will help if you mention what type (manufacturer and model no) accelerometers you are already using. If they're a solid state (MEMS) type like the ones Parallax sells, the chances are quite good that the output from those can be used for data logging purposes.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
Please look at what I did in an earlier version. This last one you posted is all messed up and won't work reliably.
The piece labelled "main:" is sort of ok, but you're calling the movement loops (forward, backward, turnclockwise, turncounterclockwise) as subroutines, but they don't have RETURNs at the end of the routines. They each "fall through" to the next, then they fall through to the part of the code that does the measurements and recording (Initialization comment). The first GOSUB in that section is a call to Get_Data which works, then does a RETURN which goes back to the "main:" loop. Anyway, I'm surprised it does anything useful at all. This all is part of the problem with the file getting erased when it shouldn't.
I've rearranged the program. Please look carefully at what I've done and don't put it back the way you had it unless you really understand what's going on and what you're trying to do.
Mike
· The altimeters/accelerometers are Black Sky AltAcc's. They are installed, and they work completely independently of, the Parallax board. All they're used for is to fire a charge that deploy two parachutes at two different altitudes (along with ejecting the robot on it's own parachute.
Mike - Thanks for your post! We'll look at the program carefully, as you suggested, to try and understand at a fundamental level which commands are being called on to run; where; and why they work. Thanks so much for·being patient with us, and·for sticking·with us as we (slowly) work our way toward deeper understanding. We've been programming for all of three weeks now, and as much as it seems like we've 'learned' (to us anyway!), I do realize that there is SO much more to learn.
You're a great teacher, Mike!
Good morning from the classroom,
Mark
When you look at the program, focus in one of four ways:
1) Look at the comments and other documentation of the program (if it's well documented). This should give you a general idea of what the program is intended to do and how it's supposed to do it. Specifically, comments should give you the intention of the programmer as well as notes describing specific details that may not be obvious from looking at the code.
2) Look at the variables, I/O pins, and constants. In particular, look at how the variables are laid out in memory and which ones are shared.
3) Look at the "flow of control". This means labels, GOTOs, GOSUBs, RETURNs, IF / THEN / ENDIFs, FOR / NEXTs, anything that affects the order of execution. While you're doing this, you can mostly ignore what's in between.
4) Look at what's actually done in the little clumps of statements in between the "flow of control" statements.
Andrew, Tim, and Tyler,
·· If you are following along on the forum and reading this (which you should be), please post a reply to the forum.
Thanks,
Mr. Kibler
I have been following this thread along with all of you. I have also been looking through the most recent version of the program.
Andrew
·· If you would, download the attached program, run it on the robot, then let me know on the forum and by e-mail what it does. I·simply duplicated·the 'forward' and 'backward' line commands to make the robot go the distance we want it to move (even though I'm sure there's a simpler way to make it do the same thing-- sorry, Mike Green, I couldn't figure it out. I tried!) I did learn that the Vex and Parallax servomotors DON'T run the same way with the same program. I'm guessing that they each 'read' the PULSOUT pulses from the Board to the motors slightly differently, on different 'frequencies' ??(*OK, I'll admit it: I'm a rookie and it shows. But I'm trying things, and we're all learning lots!)
Andrew and Tim: be sure to report back and let me, and our friends on the forum, know what the robot does. I think this program runs the ground routine that Tim explained in the Preliminary Design Review. Tyler, be sure to drop of the ASP at my house before you leave for your grandmother's house!
Andrew,·after working at this on and off all day (and trying to build another robot at the same time, and shoveling snow for Mrs. Kibler, the grading sciene essays!) I don't know that it's feasible to try and incorporate·a CO2 sensor on the robot. Now's an excellent time to explain to our friends on the forum what we'd like to do with the CO2 sensor (be sure to include the brand name of the CO2 sensor and a web link where people can access the technical specifications.) As much as I hate to admit it I think we're in way over our heads with the CO2 sensor (programming it, etc.) Remember that I'm also coaching two other TARC rocketry teams. After thinking it through, I think the best·option for the CO2 sensor is to use the PASport module and install it in the nose cone with the ASP (Air SAmpling Probe). We still have lots to do, and the Flight Readiness Review (the report, Powerpoint presentation, and the·video teleconference with NASA) are due in a little over·a month. ut There's tons left to do on the rocket, too, but we're almost there with the robot. Think it through and let me know what you think. Andrew, if you really believe that you CAN figure it out an get it working in a month, I'm 'game' for ordering it. Remember that we have less than $75 left in our budget, and one sensor costs $40 (we would need three.)
Keep up the great work, team!·
ZZZZZZZZZZZZZZ,
Mr. Kibler
Sorry I wasn't on the forum before, the phone lines in my area were working like crazy yesterday. Since I have dialup, I couldn't even get on the internet. Everything is working now, though.
I've thought about the CO2 sensor, which is a IRceL Miniature Infrared Gas Sensors, and I'm not really sure we would want to try (with our current budget, and, time left) to add the IRceL sensor at this point. What does everybody on the forum think? How hard would it be for us to program it in, how much time would it take? Do you think the sensor would even work? We are looking to record the CO2 data as fast as we can (which looks like about 30 seconds) on to our flash drive very similar for what we did with the temperature/humidity sensor. Here is a link to the specifications for the IRceL sensor - http://www.edinst.com/ircel.htm.
Also, Mr. Kibler, I will download and try to run the program you attached to your post today and let you know how it works. I don't have to go to school today because my class is going skiing and I didn't sign up this year.
-Andrew
I downloaded the movement program you attached to your last post. It is very similar to the one I had made, by just duplicating the movement instructions. Everything seems to work just fine, except for the data acquisition portion, because I didn't have a data logger to test it with.
Andrew
I don't think it's a good idea to add any new functionality to your program at this late date as tempting as it may be. This is a good time to test, to make sure what you already have works and works in different circumstances. For example, do you have any idea how long the batteries would last? What happens to the stored data when the batteries quit? You might lose all your data if the program restarts briefly because the batteries became exhausted and the Stamp turned off (as it does when the supply voltage drops too low to function), then the battery voltage rebounded a bit, enough for the Stamp to start up again for a second or two. This might be a good reason to remove the "delete" statement from the program's initialization and plan to erase any existing data file manually with a PC. Make sure you go through your pre-launch checklist and simulated "test flight" to be sure no other surprises turn up.
Mike
It probably is a good idea not to complicate things by adding the CO2 sensor, especially since we have very little time. We will probably end up just adding the PASport CO2 recorder in to the nose cone of the rocket.
You also made a good point about losing data if low batteries cause the Stamp to reset. We originally added the 'delete' statement so we wouldn't mix up our data and get confused. I guess we'll change that back to not delete anything, and we'll just have to make sure no old files are on the drive when we launch the rocket.
Thanks for your help,
Andrew
I agree with your analysis of our situation: we simply don't have enough time to buy, then figure out how a (non-Parallax brand) CO2 sensor works on a Parallax circuit board. You also bring up some simple but important points I hadn't considered:
1) What happens to the data if the batteries run low or somehow get disconnected in flight. We will take your suggestion and remove the 'delete data' command that runs during initialization.
2) How does the robot run under various, conditions? Our launch is in April in Alabama and so the 'weather' conditions will be different than ambient conditions inside a classroom or (dry) house.
3) How long will the batteries last (and what are the 'best' batteries to use for longevity? (Y)our robot is programmed to run indefinitely (which is until we locate it, the batteries run out, or it drives itself into a swamp...!) Last year, one team's rocket ended up sprawled across the top of a very tall tree, beeping loudly but completely out of reach. Another team's rocket deployed the parachute prematurely (a mile up in the air) and it drifted nearly two miles, into a swamp that had alligators in it (or so we were told.) OUR rocket and robot landed safely, but someone from Redstone Arsenal found our robot (moving fearlessly forward) and tried to shut it off before chucking it into the back of an Army pickup truck! He apparently thought the idler wheel mechanism-- which was installed to count tread rotations and measure distance-- was the 'off' button and so he pushed it. This reset the rotation count to zero! When this didn't shut the robot off he tugged at wires until it did!
This year we're putting a highly visible and colorful notice on the robot's housing that says, "DO NOT SHUT OFF IF FOUND!" Last year we didn't anticipate that someone else other than our team would recover the robot. Now we know that could happen, and so your suggestion of storing the data BEFORE someone shuts the robot off (or if the batteries run down) is an excellent idea.
Can you explain how we can make the robot run twice as long when it goes forward (instead of just duplicating the forward sequence as a 'NEXT' command? Which part of the program command controls 'time forward'? Thanks again!
Mark
I've just completed a project that involved a CO2 sensor, not the one you pointed to, but also a dual wavelength device from a different manufacturer (SenseAir). Incidentally, thanks for that link to Edinburgh Instruments. I was not familiar with their products.
The Stamp programming for the sensor we used was trivial, because the sensor had an on-board microprocessor that handled all the drive, signal read, temperature and long term compensation and so forth. All my program had to do was to read the analog voltage and apply some simple math. However, the description of the IRcel you were looking at includes the phrase, " Supporting electronics available from Edinburgh Instruments Ltd", which (in addition to the low price of $40 each) leads me to believe that some additional electronics might be required. Do you have the datasheet and/or application guide? The effort to make it work might quite possibly be a big project for both electronics and programming.
A couple of other points...
• This type of sensor draws a pulse of current when the light sources (IR) turn on. Ours pulsed to around 300 milliamps. So that is another factor to consider in your power budget
• A sensor that relies on passive diffusion (rather than aspiration) will have a relatively slow response time, and the response time will depend on the local air velocity outside.
• The IRcel has a range of 0-5% CO2, and I don't know what the attainable resolution might be. But keep in mind that normal atmospheric concentration is between 0.03% and 0.05%, and continued exposure to levels above 0.1% (1000ppm) is considered unhealthy, and 1% (10000ppm) is quite toxic. Exhaled air is around 0.45%. The sensor I'm using in my project covers 0 to 5000 ppm (0 to 0.5%).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
You don't need "forward2" and "backward2". They just duplicate the "forward" and "backward" code. So, instead of calling· GOSUB forward2 and GOSUB backward2, just call GOSUB forward and·GOSUB backward·again, at that same place in the program· where the current "forward2" and "backward2" statements are located (and delete the code for the forward2 and backward2 subroutines).
If you want to change the amount of time that the "forward" ("backward") subroutine causes the bot to move forward (backward), change the number of times the "for ... next" block loops. E.g., instead of:
forward:
·· FOR i = 0 TO 240····...··· next
use, for example,
forward:
·· FOR i = 0 TO·480··· ...·· next
That would cause the time spent in the "forward" subroutine to be twice as long.
PAR
· Thanks for the feedback. I'm interested in your recent CO2 sensor project. You said:
"I've just completed a project that involved a CO2 sensor... a dual wavelength device from a different manufacturer (SenseAir)... The Stamp programming we used was trivial... All my program had to do was to read the analog voltage and apply some simple math."
Can you give us more details onyour Sensair CO2 sensor? How big is it? How much does one cost? I mentioned that we need three; that's because we have two air sampling modules, and we would need one for me to 'bench test.' One Parallax board/ sensor set is on the robot itself, which measures samples in flight AND after it lands (to gather baseline data to compare against atmospheric readings.) The second unit is a Parallax board mounted on a platform that goes inside the rocket's nose cone. We named the second unit the ASP (air sampling probe) and it, too measures atmospheric humidity (and ideally, CO2.) *We thought about naming it the Gaseous Atmospheric Sampling Probe... then thought better of the acronym!
The students I work with range from 7th grade to juniors in high school, and it's alomst a 50-50 split between boys and girls. They come from five different schools·but none are students that I have Monday through Friday (I teach 8th grade science.) Accordingly, the Parallax boards, sensors, etc. are shared by team members who are spread across several different communities (hence the need for me to have at least one unit to work with and bench test, so I can figure this out, with your and everyone else's help, before we meet for our next practice.) I've bought a lot of the circuit boards, sensors, etc. out-of-pocket (and out of necessity), and we meet Sunday afternoons at my house. One student's mother drives him an hour each way just to participate, a credit to·our endeavours I suppose.
Anyway, I'd like to hear more about·your Sensair CO2 sensor and whether you think it is a viable option for us to figure out within the next month or so. We have our last report and video teleconference to NASA in mid-March (the Flight Readiness Review report) and we have to be, well... flight ready! Thanks again for your post. I'll look for your reply.
Regards,
Mark
·· Thanks for the suggestion to delete "forward2" and "backward2" from the program.·It works fine, as you said it would, using just the forward and backward commands.
However, when I set i = 0 TO 240 to anything greater than 0 TO 250, the motors run indefinitely...? I read through the 'What's A Microcontroller" and it said that some commands are 'limited' (because of the number of pulses sent/received.) But I really didn't understand it too well. Can someone explain, simply, what these commands mean and do:
PAUSE· - Is the a time duration pause (where 1000 is a literal 1 second motor pause)? Or does it refer to a pause (in microseconds?) between electric impusles sent from the circuit board to the motors?
O TO 240 - '0' what? and '240' what? Why do the motors run for an exact amount of time when 0 TO 60, 4 times as long when set to 0 TO 240, but cycle indefinitely when set above 0 TO 250?
I hooked up a Vex servomotor to the Parallax board and, using the same program, the Vex motors run differently (not as long, backwards, with choppy 'pulses', etc.) Why the difference?
Thanks for all your help. You guys are genuises! I bow to your infinite knowledge.
Me, bowing. But I'm not really green (well I suppose you COULD say that I'm green at programming!)
Mark in NH
1) Check to make sure that "i" is declared as a word. You can't just change the definition because these variables are shared. There are a few unused word variables that you could use for "i". I think the declared ones go up to W11 (B22/B23). A byte can only hold values from 0 to 255.
2) Read the Parallax Basic Manual for the description of the PAUSE statement. The operand is the time in milliseconds.
3) Different servo motors are different. There's no standard for how much movement or how fast the movement should be for a given control pulse timing except that the center value is approximately 1.5ms (750 for a PULSOUT value) and most servo controllers and servo motors do not use control pulses shorter than about 0.5ms or longer than about 2.5ms.
Where are you folks located in New Hampshire?
How did you manage to connect up with NASA?
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
· So 'PAUSE 500' is a 500 millisecond pause then? Is this pause·a·real 'motor pause' command·(i.e., a pause in the output time between 'run' commands to the motors?) What is the pause between pulses the microcontroller book talks about? I'll go back and re-read it as you suggested. There's so much to read, digest, and·(try to) understand.·Sometimes (as you've seen)·all this·new information gets muddles together and it becomes a bit overwhelming (even frustrating) trying to figure it out solo.
I typed this from the Parallax book, and it works to make the motors run.·But I don't understand why. As I understand it, "i" is a VARiable, but what does 'byte' mean afterwards? Does 'i = 0' mean that the input value (i) = 0?
i·· VAR·· byte
i = 0
FOR·i = 0 to 120
Would the commands (?) below·do exactly the same thing, or are certain words ('i', for example) 'reserved'?
fish·· VAR··· byte
fish = 0
FOR fish = 0 to 120
Is this any different? If so, how, and why?
counter··· VAR·· byte
counter = 0
FOR counter = 0 to 120
Thanks again for the input on the CO2 sensor, Mike.·We have a month or so to get it all dialed in!
Mark
·
· I just changed:
····· i···VAR·· Byte····· to
····· i·· VAR·· Word
and, as you said, this·expands the '0 TO 120' (etc.) command to '0 TO 1000 (or whatever value I entered) so the motors run as long as we want them to. Thanks!
I also tried my own medicine: I changed
····· i···VAR·· Byte····· to
····· i·· VAR·· Word···· then to
····· fish·· VAR·· Word
and it ran! (of course I changed all the instances of "i" to "fish")
I think we'll probably change:
····· i···VAR·· Byte······ to
······motormovementtime· VAR·· Word
so that we start to understand and internalize what the commands really do. Any reason why we shouldn't do this?
Also, if we want to LOOP a 'forward' command, what do we loop UNTIL or WHILE (assuming we want to run two loops, then go to the NEXT command)?
forward:
DO (?)
FOR motormovementtime = 0 TO 120
·· PULSOUT 15, 650
·· PULSOUT 13, 850
·· PAUSE
LOOP UNTIL (WHILE) for two loops???
NEXT
Tacos for dinner!
Mark
·· We're located in southern New Hampshire, about 10 miles southwest of Concord in the town of Weare. My students qualified to compete in the Team America Rocketry Challenge, or TARC·(www.rocketcontest.org) national finals the past two years. The top 25 teams at the TARC nationals are allowed to submit a (very comprehensive, 75-85 page) proposal to NASA's Student Launch Initiative (SLI) program (http://education.nasa.gov/edprograms/descriptions/Student_Launch_Initiative.html). Of these, only·about 50% of the proposals are accepted. Proposals must·be written for·"a reusable aerospace vehicle designed to achieve a target·altitude of 1·mile, with a student-designed scientific paylaod on board."
The proposal, if accepted, is followed by a NASA-style Preliminary Design Review report, Critical Design Review report, and a Flight Readiness report. Students must also design and build their rocket and payload (in our case, a robot and an air sampling probe) and partcipate in 2, hour-long video teleconferences where NASA engineers question and critique their work. I mentor the team, a menagerie of students from different five schools, on Sunday afternoons, though we 'practice' all week long·through e-mail, forums, etc. It is, to say the least, rigorous, exacting, and time-consuming·work, with a big reward in April: the opportunity to launch our rocket at Marshall Space Flight Center, Alabama!
Where are you located, Bruce? Want to help out with the team?!
Regards,
Mark (rhymes with TARC)
·· Thanks for the reply and clarification. Yes, I'm catching on··
FOR
·· motormovementtime = 0 TO 120
·· PULSOUT 15, 650
·· PULSOUT 13, 650
·· PAUSE 20···
> a value above 100 or so makes the motors run choppy (i.e. pulsate)
NEXT
Ciao!
Mark in NH