In this talk of putting a shell around the boe-bot, how is that going to affect the measurement of temperature and humidity?
Andrew, I am determined that you will have something to do to keep you busy! There is lots to do to that can improve the existing program, and make room to include the clock. You have the robot there with you, right? Are you willing to work on the program and test it to make it better before next Sunday? If so, I'm willing to give you a lot of advice. But if you don't have time, then that is ok too, because you have a program that works. But then again, it is like Dr. Frankenstein's monster, made with different ill-fitting parts that live and walk, but we wonder how and why.
I'm going to start another thread with topics that are other than the programming of the rocketeer's robot. We're up to EIGHT pages now with this thread.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
This is kind of a postscript to my previous message. Are there other students on the team involved in this process and in writing the reports and all? I read the part about all the design reviews and reports you have to come up with for your NASA contract. Wow. It is hard when the entire burden of writing reports comes at the end of a project. What is the fun in that? It is easiest when diagrams and results accumulate along the way.
Mr. Allen,
I've downloaded the data sheets for the RTC, looks like it will be very interesting . The current version of the program is working really solid for me (at least for now). What would you suggest to change in the program? I have a good amount of time this week since I am on school vacation...
Thanks for your help,
-Andrew··
Tracy Allen said...
In this talk of putting a shell around the boe-bot, how is that going to affect the measurement of temperature and humidity?
Andrew, I am determined that you will have something to do to keep you busy! There is lots to do to that can improve the existing program, and make room to include the clock. You have the robot there with you, right? Are you willing to work on the program and test it to make it better before next Sunday? If so, I'm willing to give you a lot of advice. But if you don't have time, then that is ok too, because you have a program that works. But then again, it is like Dr. Frankenstein's monster, made with different ill-fitting parts that live and walk, but we wonder how and why.
·· I'm glad to see that you're up to this new and important challenge, and I'm eager to see where it goes from here. As you saw, I've already ordered the RTC and the crystal from Parallax. They should be here in time for Sunday's practice. Run with this new challenge, and have fun with it (and be sure to let Mr. Allen knows it's not ONE report, but FIVE reports that we have to write before the project ends. That's part of the fun, right?!) I spoke with one of the engineers at Marshall Space Flight Center about an hour ago and·they seem to be 'tuning in' to the chat on our forum! They said (quote) "Keep up the good work!" (I think they want to hire you, or put you in a real space capsule, or something. Better bring an astronaut's suit with you to Alabama in April, just in case...!)
PS - YOU didn't use 'feasible', I did. And I spelled it wrong the first time.
·· Can you please post some photos of the robot to the forum again? Plug a flash drive into the DataLogger and lay a ruler beside the robot so people·can see the·robot's size.·Include top, side, end, and bottom views if you would.
First of all, are you doing the programming the Stamp using a PC using the Parallax software? If you have your robot program on screen in front of you, press CTRL-M or click on the little red and green memory map icon. A little window will open that tells at the top how much of the program memory is occupied, and it will also show you a graphic of how the memory is used up. If you have the same program I do, you will see that it says 99% full. Hit Escape or close the window to get back to the program.
Save the program with a new name. We are going to do some cutting to get to a new version of the program that will have room for some new things like the real time clock. Here is what I want you to do.
Please replace this:
DEBUG CLS, CR
DEBUG "John Stark Regional High School, NH", CR, CR
DEBUG "NASA Student Launch Initiative Rocketry Team", CR, CR
DEBUG "Humidity Data Acquisition and Robot Movement Program", CR, CR
DEBUG "______________________________________________________", CR, CR, CR
with simply this:
DEBUG CR,"top!",BELL,CR"
Now do CTRL-M again and see if the amount of free memory has changed. What do you see? Load the program into the robot and test that it still runs as it did before. It should, don't you think?
>
Now find the following code in the subroutines section, and delete it. It is not needed.
' sends "status"
SHT_Write_Status:
GOSUB SHT_Start ' alert device
ioByte2 = ShtStatW ' write to status reg command
GOSUB SHT_Write_Byte ' send command
ioByte2 = status
GOSUB SHT_Write_Byte
RETURN
' returns "status"
SHT_Read_Status:
GOSUB SHT_Start ' alert device
ioByte2 = ShtStatW ' write to status reg command
GOSUB SHT_Read_Byte ' send command
ackBit = NoAck ' only one byte to read
GOSUB SHT_Read_Byte
RETURN
' reset SHT1x with soft reset
SHT_Soft_Reset:
GOSUB SHT_Connection_Reset ' reset the connection
ioByte2 = ShtReset ' reset command
ackBit = NoAck ' only one byte to send
GOSUB SHT_Write_Byte ' send it
PAUSE 11 ' wait at least 11 ms
RETURN
Do CTRL-M again and see how the amount of free memory has changed. Better? I want you to notice that removing all that program code had much less effect on the amount of memory than just removing the debug statements.
Load the program into the robot and test that it still runs as it did before. OK?
If that works, we'll do some more. If you want something to do, look through the program now and see if you can trim down the text in some of the other DEBUG statements in the program.
I've made the changes you've suggested. Now the EEPROM is only 78% full and the program works the same as it did! Now I'll try to shorten the DEBUG commands. Thanks for your help,
· I've made the changes Mr. Allen suggested and shortened some of the debug commands. After you've done the same, see how your version of the program compares with the one I've attached. I ended up with 62% EEPROM spaced used; that gives us 38% for the RTC. See if you can do better.
*NOTE that I've shortened the pauses between robot movement subroutines·(forward, backward, etc. from PAUSE 1000 to PAUSE 500.) Cutting the pause time will, I think, allow us to capture twice as much data while the robot is descending, and on the ground. Does that seem logical to you?·You could shorten the pauses even further to allow for even more data capture.
The same logic can be applied to the 'forward' and 'backward' (etc.)·commands: if we shorten them by 1/2 (from 1 TO 680, or 1 meter forward, to 1 TO 340, or 50 cm forward), we should be able to capture twice as much data. I don't believe shortening the these commands will impact the robot's 'obstacle avoidance' capabilities: it just means the robot's range won't be as far (of course that's also a function of how long it moves--·how much ground it covers-- until we locate it after landing.) This is why I would like you to include the robot's 'range' (how far forward and how far laterally it went) in your portion of the FRR report. It's still not there, and NASA may ask you, "So how far will your robot travel?" You'll want to be able to refer to actual data and explain, "Ground testing on (carpet, or concrete, or a wood floor) showed that the robot travels a total of 5.1 meters forward and 3.8 meters laterally, and to the right, in 5 minutes and 40 seconds on concrete, which resembles hard-packed soil", etc.
The PAUSE changes become·most significant when you·consider them during·the robot's descent. Here's what happens, right?
1) Robot deployed from rocket - power on.
2) About 8 seconds after 'power on' the robot records 10 samples, then switches to the movement subroutine
3) Robot does ground movement sequence AS IT DESCENDS (wasted time..?)·A longer movement sequence = less data. A shorter sequence = more data.
Think about it and let·us all know what you think.
Tracy, Phil, Bruce, Mike:············ What are your thoughts on all this? Is my logic solid (or flawed?) Also, it was suggested that I mention that we are ultimately planning on removing the breadboard and soldering the wire and components on a like-sized Radio Shack PCB.
In the shortened program, with DEBUG lines, I get 78% full. If we comment out the DEBUG lines, you only get 40% full. That should leave plenty of room for the RTC. Also, I am pretty sure I included the forward and lateral distance in the new version of the trials... Did I? If I didn't, I'll add them in later today.
Also, it was suggested that I mention that we are ultimately planning on removing the
breadboard and soldering the wire and components on a like-sized Radio Shack PCB.
Perhaps I've misunderstood your plans, but I gather that you intend to completely replace the Board of Education with a hand soldered
RS perfboard plus the Memory Stick Datalogger, thumb drive, RTC and
miscellaneous connectors.
If you post a schematic and photo of the electronic hardware that will actually be
launched, it will go a long way toward clearing up any misinterpretation.
When do you expect to have this new hardware ready to begin testing?
·· We hadn't planned on replacing the entire 'Board of Education', just the small white perforated breadboard·ON the Board of Education. Sorry if I miscommunicated·that. We'll obviously need to solder the wires, sensor, and·DataLogger on to something more robust (won't we?) So·had planned on replacing·the breadboard (only) with·a PCB from Radio Shack that's exactly the same size as the breadboard. Thoughts, comments...? Is this OK?
·· I wouldn't necessarily delete all the debug lines quite yet. We need a few of them to see what's happening with the robot when we run the program. We can always go back later and shorten them even further, or delete ones that seem unnecessary. Just a thought.
Mark said...
We hadn't planned on replacing the entire 'Board of Education',
just the small white perforated breadboard ON the Board of Education.
Thanks for clearing up that point. Replacing everything would be a major
undertaking, given your tight schedule.
If you use the RTC, you can bypass the robot motion code until enough
time has elapsed for the payload to get close to the ground. Not having
the robot spin its wheels during the descent phase will let you spend
more time taking useful data.
Andrew, now let's talk about the Frankenstein monster.
Think about the movement routine, starting at the label "main:", which is listed below. Let's put it in context. How does the program get down to running this code? It gets here from earlier in the program where you will find a
GOSUB MAIN
How does it get out of this routine and back to running the data logging part? It does that at the bottom of the code below, with the
GOSUB main2
And where is main2? I want you to find it and report back.
main:
DEBUG CR, CR
PAUSE 1000
GOSUB forward
GOSUB backward
GOSUB turnclockwise
GOSUB forward2
GOSUB backward2
GOSUB turnCOUNTERclockwise2:
GOTO main
forward:
FOR motormovementtime = 0 TO 681
PULSOUT 15, 850 ' move forward 1
PULSOUT 14, 650
PAUSE 20
NEXT
PAUSE 1000
backward: ' move backward 1/3
FOR motormovementtime = 0 TO 266
PULSOUT 15, 650
PULSOUT 14, 850
PAUSE 20
NEXT
PAUSE 1000
turnclockwise: ' rotate clockwise
FOR motormovementtime = 0 TO 32
PULSOUT 15, 850
PULSOUT 14, 850
PAUSE 20
NEXT
PAUSE 1000
forward2:
FOR motormovementtime = 0 TO 681
PULSOUT 15, 850 ' move forward 1
PULSOUT 14, 650
PAUSE 20
NEXT
PAUSE 1000
backward2: ' move backward 1/3
FOR motormovementtime = 0 TO 266
PULSOUT 15, 650
PULSOUT 14, 850
PAUSE 20
NEXT
PAUSE 1000
turnCOUNTERclockwise2: ' rotate clockwise
FOR motormovementtime = 0 TO 32
PULSOUT 14, 650
PULSOUT 15, 650
PAUSE 20
NEXT
GOSUB main2:
Remember that GOSUB is an instruction that tells the program to go somewhere and execute some code and normally will end with a RETURN that brings the program back to the instruction after the GOSUB. Look at the code below and find the RETURN that goes with each GOSUB. It will be hard to find them, because there aren't any. Think what will happen when the program executes the
GOSUB forward.
Will it ever return to execute the
GOSUB backward?
Will it ever execute the
GOTO main?
You have to think like a computer and work through it like a computer would, step by step.
Think especially about what happens when it hits the GOSUB main2. That is the Frankenstein monster. It is a program calling itself as a subroutine. Because of the way the Stamp and PBASIC work, that does not cause the program to crash, but it is not good program logic.
See if you can come up with changes to the movement code that make it "proper", with attention to GOSUB RETURN and /or plain old GOTO. There are several ways you can do this. Be forewarned. Anything you do may take a little more thought to get back to the motion and data logging rhythm that you expect.
Let me know what you think and if you want specific suggestions.
In your last post,, "And where is main2?"... It seems that "main2" is right at the beginning of the program, after the command, "DEBUG CR,"top!",BELL,CR". "main2" is "called" when the movement program completes. Since "main2" is more of a program than a subroutine, I also have changed the "GOSUB main2" to "GOTO main2". The program is attached if you want to take a look.
Okay Andrew. I hope the robot still works after that little change! Does it? That is one step, and here is the next one. We'll do a little bit at a time, ok? In the routine main:, please make all 6 of the changes listed below.
1) change forward2 to forward. Since forward is the same as forward 2, we can save program space by using it double duty as a subroutine.
2) change backward2 to backward. Same idea.
3) change GOTO main to GOTO main2. We will do more with this later.
4) put in a RETURN instruction at the end of each of the subroutines, forward, backward, turnclockwise and turncounterclockwise2. It is the RETURN instruction that makes them bona fide subroutines.
5) DELETE the routines forward2 and backward2
6) comment out the final GOTO main2. The program will never get to that one. It will instead execute the one you put in in step (3) above.
main:
DEBUG CR, CR
PAUSE 1000
GOSUB forward
GOSUB backward
GOSUB turnclockwise
GOSUB forward '<------changed from forward2 to forward
GOSUB backward '<------- changed from backward2 to backward
GOSUB turnCOUNTERclockwise2:
GOTO main2 ' <----- make this a main2 instead of main
forward:
FOR motormovementtime = 0 TO 681
PULSOUT 15, 850 ' move forward 1
PULSOUT 14, 650
PAUSE 20
NEXT
PAUSE 1000
RETURN ' <-----
backward: ' move backward 1/3
FOR motormovementtime = 0 TO 266
PULSOUT 15, 650
PULSOUT 14, 850
PAUSE 20
NEXT
PAUSE 1000
RETURN ' <-----
turnclockwise: ' rotate clockwise
FOR motormovementtime = 0 TO 32
PULSOUT 15, 850
PULSOUT 14, 850
PAUSE 20
NEXT
PAUSE 1000
RETURN ' <-----
turnCOUNTERclockwise2: ' rotate clockwise
FOR motormovementtime = 0 TO 32
PULSOUT 14, 650
PULSOUT 15, 650
PAUSE 20
NEXT
RETURN ' <-----
' GOTO main2: ' <----- Commented out, won't ever get here
' This command previously was GOSUB, but was changed to GOTO
Do you see? The program is going to step through that series of GOSUB statements after main, exectuting each subroutine in turn, and RETURNing to execute the next movement subroutine. It gets double duty out of the forward and backward subroutines. Nice, huh? Finally back to main2.
Please try that in the robot and see if it changes anything. Let me know, and we'll move on to the next step.
It looks like I decided too quickly if the program worked or not. Everything works except it won't start up unless the RESET button is pressed or I move the power switch to '0' and back to '2'. What would be causing this and what can I do to fix it?
Just as a matter of information Tracy Allen (Mr. Alllen) is actually Dr. Tracy Allen, PhD. Here is some additional information on Dr. Allen and his company EME Systems: http://www.emesystems.com/EMEmore.htm
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's
Post Edited (Bruce Bates) : 3/6/2008 2:47:39 PM GMT
In your last post,, "And where is main2?"... It seems that "main2" is right at the beginning of the program, after the command, "DEBUG CR,"top!",BELL,CR". "main2" is "called" when the movement program completes. Since "main2" is more of a program than a subroutine, I also have changed the "GOSUB main2" to "GOTO main2". The program is attached if you want to take a look.
Thanks!
Andrew
Andrew, Take a look at "main:" (the part of the program "when the movement" happens).
Note that "main:" loops (ends at "GOTO main").· "main" calls each of the movement subroutines ("forward", "backward", "turnclockwise", etc.).
Now, look at each of those called subroutines --Does each one have the required "Return" statement at the end, which any subroutine needs ?
Once you get that question resolved, then revisit Tracy's question about the final statement in your program (the one with "GOTO main2"). How do you get there ? And, if you were to get there, why would you want to go back to "main2" anyway ?
( One other suggestion: Put a comment after each "Return" in your program, telling what subroutine that "Return" belongs to. E.g., " Return·· 'for SHT_Wait "· )
Hi Andrew, That's too bad that it is stuck until you press the RESET button or switch to 0->2. I think you are talking about the situation where the robot is no longer connected to the computer, right?
When you report that it gets stuck, it would be helpful to know where it is getting stuck. Are any lights on the logger flashing when it gets stuck? My guess is that it is getting stuck in the Check_Drive routine, which does not have a failsafe exit.
Would you like to add a "mood" light on the robot that would tell you what it is thinking inside, even when not connected to the computer, so your robot could talk to you a little bit? See if you can dig up an light emitting diode and a 1000 ohm resistor.
Bruce, thanks for the build-up. I like to give back a little. I think it was 1960, there had been Sputnik, and my 7th grade project in Michigan was a 3D satellite model made out of cardboard and wire and thread spools and assorted other stuff, and I was really into it and explaining the "parts" to my class. And look what they are doing now, actually launching a robot! I went into a space explorer scout troop in high school in Washington DC, and we visited high tech facilities and met people and through amateur radio built a little tracking station. And I got to participate in an NSF program for high school juniors, part an electronics intensive at the U. of Virginia and part an internship at the Signal Corps lab at Fort Manmouth N.J., where I was introduced to real working engineers, and a real working project involving time division multiplexed comm channels and encryption (they didn't teach any secrets about the encryption!). So I see these young people now and it reminds me of those good times and how important mentors and experiences were to me, and are.
As a couple of the "old men" of the Parallax Stamp Forums (here and on Yahoo Groups) if we don't support each other, I don't know who's going to do it for us Any "build-up" I may have given you is richly deserved, and I know I'll get no argument on that score!
I'm sorry to say that at least at this moment, it looks like they may be closing down the venerable Fort Monmouth, and many of us have tales to tell about that wonderful environment. However, there is still hope as you can read here: http://en.wikipedia.org/wiki/Fort_Monmouth#Closure_by_BRAC
As far as mentoring is concerned, for my money, that's the basis for the best kind of learning. The least we can do is give back some of what we learned to the youth who are hopefully following in our footsteps. When I entered the world of computers, back in the late 1960's, I was fortunate enough to have a mentor find me. I learned more from him, in a shorter period of time, than from any other source of learning I can recall. All he ever asked was that I pass on what I'd learned to others. Since that time, that's why I have been trying to do. Hopefully I've been successful, to one extent or another.
If they put a "mood light" on this rocket, won't they then have a "retro" rocket?
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Here is another roborocket program for you to try, and I hope it can teach a few things about PBASIC programming. This is not complete. It does not yet include the code for the thumb drive data logger. However, it does include a MAIN program loop with the real time clock, the indicator LED and the movement subroutines. And the eeprom is less than 40% full, so there is plenty of room to add back in the data logger in the next step.
This is kind of a long message, to explain what I did in the program.
-- The LED has a long blink (one second) when the Stamp powers up or resets. The LED also blinks out the temperature and humidity readings in Morse code. Do any of the rocketeers know Morse code?
Furthermore, during the robot movement sequence, the LED blinks out letters "F" "B" "C" and "W" at the start of the forward, backward, clockwise and counterclockwise sections. We can add codes for other things too, like errors that might occur or messages to help us debug the program when it is not connected to the computer.
-- The real time clock is reset to 00:00:00 at reset or power up. Subsequently as time advances, it is interrogated at the top of the main loop, and the current time is printed on the debug screen. After a certain elapsed time a flag is raised that says that it is time to start the movements. Up until that time, the program only acquires data and skips the movements. Anna thinks that the movement should delay for 5 minutes. Can you see what needs to be changed to make it 5 minutes instead of 1 minute as it is currently set?
-- The main loop is relatively short and the various functions are called as subroutines.
-- Andrew in particular, notice how the movement routines are rewritten. There is a subroutine called "movement" that is called from a GOSUB in the main program loop. The movement subroutine ends with a RETURN that brings it back to the bottom of the main program loop and from there the main program loop cycles back to its first DO.
The movement subroutine itself calls subroutines for forward, backward, etc., and each of those subroutines ends with a RETURN that brings it back to a place where it left off in the movement subroutine. Subroutine calls subroutine. This is "nesting" of subroutines, and here the nesting is "two deep" because there are two levels of RETURN to get back to the main program loop. Notice that the forward and backward subroutines are called twice. Doing that saves code space.
-- The code for the Sensirion is also tightened up. It uses an additional nested subroutine for code that had been duplicated in both the temperature and humidity sections, and that again saves code space. The calculations in the humidity and temperature sections are written to use fewer variables, reusing temporary variables where possible.
-- Generic variable names like w0 and b15 are no longer to be seen. All the variables are defined explicitly. Look at the section where the variables are defined. There are variables set aside for the temperature (degC) and the final humidity value (RH). There are variables for second, minute and hour. There is a variable I have called "waldo" (Can you find waldo?). Waldo serves several different purposed in the program, at different times, and under the name waldo you can find several of its aliases. In PBASIC, one often has to think carefully about how some variables can be used for different purposes at different times.
The first variable defined is called "primo", but the program never uses that name. Instead, primo is divided up into several smaller chunks. One is the iobyte that will be used to send commands and to receive back data. And there is a nibble "index" that will be used as a counter for loops. And there is another nibble, "flags", that is used to hold single bit values such as the signal for time to start the movements. In PBASIC, dividing a word into smaller chuncks -- bytes, nibbles and individual bits --is a very powerful capability. In my own serious programs, I almost always start by defining words, and then break them down into various smaller chunks like that. (However, in hack quick programs I don't take the trouble!)
You will see that there are 7 Word variables defined, and other variables are defined as parts or aliases that refer to those same 7 words. With the program loaded in the STAMPW.EXE IDE, press the Ctrl-M key to see the memory map. On the top bar you see that about 40% of the program eeprom space is occupied. On the left is a graphic that shows that 40% from the bottom up. And on the right is the map of the RAM, where you can see that seven word variables have been defined. There are 6 more word variables that are free. 13 total words, the same as 26 bytes, 52 nibbles or 104 bits. When we add back in the data logger, its get_data buffer will start at the seventh word and extend up into the undefined space.
Well, that's it for now. Rocketeers, please try out this program and see if it works (except for the data logging). If it doesn't please tell me in detail where it messes up and what messages it sends or doesn't send correctly.
I do hope these young rocketeers have the time and the patience to learn Morse code in the short time left. Perhaps I'm just envious of retentive young minds
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's
I should have mentioned to the rocketeers that it will be easy to eliminate the morse code later on. I'm a bit curious to know if the young minds have even heard of it and how it originated. I know of people who have sent up rockets to gather weather data, and have the data radioed back to earth in real time in Morse code.
It is in the rocket program temporarilty for feedback during debugging. Just look at it as a groups of long and short flashes that can convey information.
Bruce, you are up early and in the peanut gallery too! My retention is sticky and slow like molases, Sometimes in one ear and out the other.
Comments
Andrew, I am determined that you will have something to do to keep you busy! There is lots to do to that can improve the existing program, and make room to include the clock. You have the robot there with you, right? Are you willing to work on the program and test it to make it better before next Sunday? If so, I'm willing to give you a lot of advice. But if you don't have time, then that is ok too, because you have a program that works. But then again, it is like Dr. Frankenstein's monster, made with different ill-fitting parts that live and walk, but we wonder how and why.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I'm going to start another thread with topics that are other than the programming of the rocketeer's robot. We're up to EIGHT pages now with this thread.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I've downloaded the data sheets for the RTC, looks like it will be very interesting . The current version of the program is working really solid for me (at least for now). What would you suggest to change in the program? I have a good amount of time this week since I am on school vacation...
Thanks for your help,
-Andrew··
·· I'm glad to see that you're up to this new and important challenge, and I'm eager to see where it goes from here. As you saw, I've already ordered the RTC and the crystal from Parallax. They should be here in time for Sunday's practice. Run with this new challenge, and have fun with it (and be sure to let Mr. Allen knows it's not ONE report, but FIVE reports that we have to write before the project ends. That's part of the fun, right?!) I spoke with one of the engineers at Marshall Space Flight Center about an hour ago and·they seem to be 'tuning in' to the chat on our forum! They said (quote) "Keep up the good work!" (I think they want to hire you, or put you in a real space capsule, or something. Better bring an astronaut's suit with you to Alabama in April, just in case...!)
PS - YOU didn't use 'feasible', I did. And I spelled it wrong the first time.
Mr. Kibler
·· Can you please post some photos of the robot to the forum again? Plug a flash drive into the DataLogger and lay a ruler beside the robot so people·can see the·robot's size.·Include top, side, end, and bottom views if you would.
Thanks,
Mr. Kibler
Attached are some pictures of the robot, as requested.
-Andrew
First of all, are you doing the programming the Stamp using a PC using the Parallax software? If you have your robot program on screen in front of you, press CTRL-M or click on the little red and green memory map icon. A little window will open that tells at the top how much of the program memory is occupied, and it will also show you a graphic of how the memory is used up. If you have the same program I do, you will see that it says 99% full. Hit Escape or close the window to get back to the program.
Save the program with a new name. We are going to do some cutting to get to a new version of the program that will have room for some new things like the real time clock. Here is what I want you to do.
Please replace this:
with simply this:
Now do CTRL-M again and see if the amount of free memory has changed. What do you see? Load the program into the robot and test that it still runs as it did before. It should, don't you think?
>
Now find the following code in the subroutines section, and delete it. It is not needed.
Do CTRL-M again and see how the amount of free memory has changed. Better? I want you to notice that removing all that program code had much less effect on the amount of memory than just removing the debug statements.
Load the program into the robot and test that it still runs as it did before. OK?
If that works, we'll do some more. If you want something to do, look through the program now and see if you can trim down the text in some of the other DEBUG statements in the program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I've made the changes you've suggested. Now the EEPROM is only 78% full and the program works the same as it did! Now I'll try to shorten the DEBUG commands. Thanks for your help,
-Andrew
· I've made the changes Mr. Allen suggested and shortened some of the debug commands. After you've done the same, see how your version of the program compares with the one I've attached. I ended up with 62% EEPROM spaced used; that gives us 38% for the RTC. See if you can do better.
*NOTE that I've shortened the pauses between robot movement subroutines·(forward, backward, etc. from PAUSE 1000 to PAUSE 500.) Cutting the pause time will, I think, allow us to capture twice as much data while the robot is descending, and on the ground. Does that seem logical to you?·You could shorten the pauses even further to allow for even more data capture.
The same logic can be applied to the 'forward' and 'backward' (etc.)·commands: if we shorten them by 1/2 (from 1 TO 680, or 1 meter forward, to 1 TO 340, or 50 cm forward), we should be able to capture twice as much data. I don't believe shortening the these commands will impact the robot's 'obstacle avoidance' capabilities: it just means the robot's range won't be as far (of course that's also a function of how long it moves--·how much ground it covers-- until we locate it after landing.) This is why I would like you to include the robot's 'range' (how far forward and how far laterally it went) in your portion of the FRR report. It's still not there, and NASA may ask you, "So how far will your robot travel?" You'll want to be able to refer to actual data and explain, "Ground testing on (carpet, or concrete, or a wood floor) showed that the robot travels a total of 5.1 meters forward and 3.8 meters laterally, and to the right, in 5 minutes and 40 seconds on concrete, which resembles hard-packed soil", etc.
The PAUSE changes become·most significant when you·consider them during·the robot's descent. Here's what happens, right?
1) Robot deployed from rocket - power on.
2) About 8 seconds after 'power on' the robot records 10 samples, then switches to the movement subroutine
3) Robot does ground movement sequence AS IT DESCENDS (wasted time..?)·A longer movement sequence = less data. A shorter sequence = more data.
Think about it and let·us all know what you think.
Tracy, Phil, Bruce, Mike:···
Thanks, and good morning,
Mark
In the shortened program, with DEBUG lines, I get 78% full. If we comment out the DEBUG lines, you only get 40% full. That should leave plenty of room for the RTC. Also, I am pretty sure I included the forward and lateral distance in the new version of the trials... Did I? If I didn't, I'll add them in later today.
Thanks,
Andrew
Perhaps I've misunderstood your plans, but I gather that you intend to
completely replace the Board of Education with a hand soldered
RS perfboard plus the Memory Stick Datalogger, thumb drive, RTC and
miscellaneous connectors.
If you post a schematic and photo of the electronic hardware that will actually be
launched, it will go a long way toward clearing up any misinterpretation.
When do you expect to have this new hardware ready to begin testing?
phil
·· We hadn't planned on replacing the entire 'Board of Education', just the small white perforated breadboard·ON the Board of Education. Sorry if I miscommunicated·that. We'll obviously need to solder the wires, sensor, and·DataLogger on to something more robust (won't we?) So·had planned on replacing·the breadboard (only) with·a PCB from Radio Shack that's exactly the same size as the breadboard. Thoughts, comments...? Is this OK?
Mark
·· I wouldn't necessarily delete all the debug lines quite yet. We need a few of them to see what's happening with the robot when we run the program. We can always go back later and shorten them even further, or delete ones that seem unnecessary. Just a thought.
Mr. Kibler
I didn't delete the necessary ones. Just the ones that seemed okay to comment out for some more space.
Andrew
Thanks for clearing up that point. Replacing everything would be a major
undertaking, given your tight schedule.
If you use the RTC, you can bypass the robot motion code until enough
time has elapsed for the payload to get close to the ground. Not having
the robot spin its wheels during the descent phase will let you spend
more time taking useful data.
phil
Think about the movement routine, starting at the label "main:", which is listed below. Let's put it in context. How does the program get down to running this code? It gets here from earlier in the program where you will find a
GOSUB MAIN
How does it get out of this routine and back to running the data logging part? It does that at the bottom of the code below, with the
GOSUB main2
And where is main2? I want you to find it and report back.
Remember that GOSUB is an instruction that tells the program to go somewhere and execute some code and normally will end with a RETURN that brings the program back to the instruction after the GOSUB. Look at the code below and find the RETURN that goes with each GOSUB.
GOSUB forward.
Will it ever return to execute the
GOSUB backward?
Will it ever execute the
GOTO main?
You have to think like a computer and work through it like a computer would, step by step.
Think especially about what happens when it hits the GOSUB main2. That is the Frankenstein monster. It is a program calling itself as a subroutine. Because of the way the Stamp and PBASIC work, that does not cause the program to crash, but it is not good program logic.
See if you can come up with changes to the movement code that make it "proper", with attention to GOSUB RETURN and /or plain old GOTO. There are several ways you can do this. Be forewarned. Anything you do may take a little more thought to get back to the motion and data logging rhythm that you expect.
Let me know what you think and if you want specific suggestions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/27/2008 6:50:10 PM GMT
BRAVO! Challenge young Andrew····
Thanks for mentoring,
Mark
In your last post,, "And where is main2?"... It seems that "main2" is right at the beginning of the program, after the command, "DEBUG CR,"top!",BELL,CR". "main2" is "called" when the movement program completes. Since "main2" is more of a program than a subroutine, I also have changed the "GOSUB main2" to "GOTO main2". The program is attached if you want to take a look.
Thanks!
Andrew
1) change forward2 to forward. Since forward is the same as forward 2, we can save program space by using it double duty as a subroutine.
2) change backward2 to backward. Same idea.
3) change GOTO main to GOTO main2. We will do more with this later.
4) put in a RETURN instruction at the end of each of the subroutines, forward, backward, turnclockwise and turncounterclockwise2. It is the RETURN instruction that makes them bona fide subroutines.
5) DELETE the routines forward2 and backward2
6) comment out the final GOTO main2. The program will never get to that one. It will instead execute the one you put in in step (3) above.
Do you see? The program is going to step through that series of GOSUB statements after main, exectuting each subroutine in turn, and RETURNing to execute the next movement subroutine. It gets double duty out of the forward and backward subroutines. Nice, huh? Finally back to main2.
Please try that in the robot and see if it changes anything. Let me know, and we'll move on to the next step.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I've made the suggested changes, and the robot is still working! Also, the program is only taking up 38% of the EEPROM now.
Andrew
It looks like I decided too quickly if the program worked or not. Everything works except it won't start up unless the RESET button is pressed or I move the power switch to '0' and back to '2'. What would be causing this and what can I do to fix it?
Thanks for your help,
Andrew
Just as a matter of information Tracy Allen (Mr. Alllen) is actually Dr. Tracy Allen, PhD. Here is some additional information on Dr. Allen and his company EME Systems:
http://www.emesystems.com/EMEmore.htm
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's
Post Edited (Bruce Bates) : 3/6/2008 2:47:39 PM GMT
Note that "main:" loops (ends at "GOTO main").· "main" calls each of the movement subroutines ("forward", "backward", "turnclockwise", etc.).
Now, look at each of those called subroutines --Does each one have the required "Return" statement at the end, which any subroutine needs ?
Once you get that question resolved, then revisit Tracy's question about the final statement in your program (the one with "GOTO main2"). How do you get there ? And, if you were to get there, why would you want to go back to "main2" anyway ?
( One other suggestion: Put a comment after each "Return" in your program, telling what subroutine that "Return" belongs to. E.g., " Return·· 'for SHT_Wait "· )
PAR
Post Edited (PAR) : 3/1/2008 4:47:13 PM GMT
When you report that it gets stuck, it would be helpful to know where it is getting stuck. Are any lights on the logger flashing when it gets stuck? My guess is that it is getting stuck in the Check_Drive routine, which does not have a failsafe exit.
Would you like to add a "mood" light on the robot that would tell you what it is thinking inside, even when not connected to the computer, so your robot could talk to you a little bit? See if you can dig up an light emitting diode and a 1000 ohm resistor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
As a couple of the "old men" of the Parallax Stamp Forums (here and on Yahoo Groups) if we don't support each other, I don't know who's going to do it for us
I'm sorry to say that at least at this moment, it looks like they may be closing down the venerable Fort Monmouth, and many of us have tales to tell about that wonderful environment. However, there is still hope as you can read here:
http://en.wikipedia.org/wiki/Fort_Monmouth#Closure_by_BRAC
As far as mentoring is concerned, for my money, that's the basis for the best kind of learning. The least we can do is give back some of what we learned to the youth who are hopefully following in our footsteps. When I entered the world of computers, back in the late 1960's, I was fortunate enough to have a mentor find me. I learned more from him, in a shorter period of time, than from any other source of learning I can recall. All he ever asked was that I pass on what I'd learned to others. Since that time, that's why I have been trying to do. Hopefully I've been successful, to one extent or another.
If they put a "mood light" on this rocket, won't they then have a "retro" rocket?
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
This is kind of a long message, to explain what I did in the program.
-- The LED has a long blink (one second) when the Stamp powers up or resets. The LED also blinks out the temperature and humidity readings in Morse code. Do any of the rocketeers know Morse code?
Furthermore, during the robot movement sequence, the LED blinks out letters "F" "B" "C" and "W" at the start of the forward, backward, clockwise and counterclockwise sections. We can add codes for other things too, like errors that might occur or messages to help us debug the program when it is not connected to the computer.
-- The real time clock is reset to 00:00:00 at reset or power up. Subsequently as time advances, it is interrogated at the top of the main loop, and the current time is printed on the debug screen. After a certain elapsed time a flag is raised that says that it is time to start the movements. Up until that time, the program only acquires data and skips the movements. Anna thinks that the movement should delay for 5 minutes. Can you see what needs to be changed to make it 5 minutes instead of 1 minute as it is currently set?
-- The main loop is relatively short and the various functions are called as subroutines.
-- Andrew in particular, notice how the movement routines are rewritten. There is a subroutine called "movement" that is called from a GOSUB in the main program loop. The movement subroutine ends with a RETURN that brings it back to the bottom of the main program loop and from there the main program loop cycles back to its first DO.
The movement subroutine itself calls subroutines for forward, backward, etc., and each of those subroutines ends with a RETURN that brings it back to a place where it left off in the movement subroutine. Subroutine calls subroutine. This is "nesting" of subroutines, and here the nesting is "two deep" because there are two levels of RETURN to get back to the main program loop. Notice that the forward and backward subroutines are called twice. Doing that saves code space.
-- The code for the Sensirion is also tightened up. It uses an additional nested subroutine for code that had been duplicated in both the temperature and humidity sections, and that again saves code space. The calculations in the humidity and temperature sections are written to use fewer variables, reusing temporary variables where possible.
-- Generic variable names like w0 and b15 are no longer to be seen. All the variables are defined explicitly. Look at the section where the variables are defined. There are variables set aside for the temperature (degC) and the final humidity value (RH). There are variables for second, minute and hour. There is a variable I have called "waldo" (Can you find waldo?). Waldo serves several different purposed in the program, at different times, and under the name waldo you can find several of its aliases. In PBASIC, one often has to think carefully about how some variables can be used for different purposes at different times.
The first variable defined is called "primo", but the program never uses that name. Instead, primo is divided up into several smaller chunks. One is the iobyte that will be used to send commands and to receive back data. And there is a nibble "index" that will be used as a counter for loops. And there is another nibble, "flags", that is used to hold single bit values such as the signal for time to start the movements. In PBASIC, dividing a word into smaller chuncks -- bytes, nibbles and individual bits --is a very powerful capability. In my own serious programs, I almost always start by defining words, and then break them down into various smaller chunks like that. (However, in hack quick programs I don't take the trouble!)
You will see that there are 7 Word variables defined, and other variables are defined as parts or aliases that refer to those same 7 words. With the program loaded in the STAMPW.EXE IDE, press the Ctrl-M key to see the memory map. On the top bar you see that about 40% of the program eeprom space is occupied. On the left is a graphic that shows that 40% from the bottom up. And on the right is the map of the RAM, where you can see that seven word variables have been defined. There are 6 more word variables that are free. 13 total words, the same as 26 bytes, 52 nibbles or 104 bits. When we add back in the data logger, its get_data buffer will start at the seventh word and extend up into the undefined space.
Well, that's it for now. Rocketeers, please try out this program and see if it works (except for the data logging). If it doesn't please tell me in detail where it messes up and what messages it sends or doesn't send correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I do hope these young rocketeers have the time and the patience to learn Morse code in the short time left. Perhaps I'm just envious of retentive young minds
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's
It is in the rocket program temporarilty for feedback during debugging. Just look at it as a groups of long and short flashes that can convey information.
Bruce, you are up early and in the peanut gallery too! My retention is sticky and slow like molases, Sometimes in one ear and out the other.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
··..··· -···· .-.··· ..-··· -.··· ...
··-.··· ---··· -..··· .-··· -··· .-··· .-..··· ----··· --.
··