Rtc_rocket_robot
Mark in NH
Posts: 447
All,
·· The RTC runs! Thank you!···
··· <
( Me, bowing down and worshipping your infinite wisdom yet again.) The the program that we used to get it running is attached; I'll keep trying to upload the wiring schematic (it won't load right now for some reason.) We even managed to figure out how to set the date the correct day, month, and year "all on on own" (you got us here!) We ran the RTC as a stand-alone unit, by itself·on a separate Board of Education from the robot.·Instantly we·saw our first·two hurdles:
1) PO and P1 are already being used by the humidity/temperature sensor... Can we put two wires in one 'hole' (e.g. share PO and P1 with both sensors?)
2) Every hole down the center of the board is occupied-- from end to end-- by the RTC ('bottom'), humidity sensor (middle), and DataLogger (top). Where and how do we begin to figure out 'rewiring'?
We tried to remedy hurdle #1·'simply' by moving the two wires for the humidity sensor from P0 and P1, to P3 and P4. Uh, not so simple.... Help! Here we go again.
Regards,
Mark and the Rocketeers
·· The RTC runs! Thank you!···
··· <
( Me, bowing down and worshipping your infinite wisdom yet again.) The the program that we used to get it running is attached; I'll keep trying to upload the wiring schematic (it won't load right now for some reason.) We even managed to figure out how to set the date the correct day, month, and year "all on on own" (you got us here!) We ran the RTC as a stand-alone unit, by itself·on a separate Board of Education from the robot.·Instantly we·saw our first·two hurdles:
1) PO and P1 are already being used by the humidity/temperature sensor... Can we put two wires in one 'hole' (e.g. share PO and P1 with both sensors?)
2) Every hole down the center of the board is occupied-- from end to end-- by the RTC ('bottom'), humidity sensor (middle), and DataLogger (top). Where and how do we begin to figure out 'rewiring'?
We tried to remedy hurdle #1·'simply' by moving the two wires for the humidity sensor from P0 and P1, to P3 and P4. Uh, not so simple.... Help! Here we go again.
Regards,
Mark and the Rocketeers
Comments
Kudos on your success! Now what you need to do, before going any further, is to draw up a simple wiring diagram. This will serve two purposes. First it will help us answer your various questions, and second it will serve as important, additional documentation for the rocket project.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
I am attaching a much simplified program for the record, that just does the essentials of getting the RTC running and displaying data. Yes, there will be some work to get this integrated into your system, electrically, physically, and also into the program.
It looks to me, yes, your program is using pins p0 and p1 for the Sensirion. But pins p2 thru p7 seem to be unoccupied. p8 thru p11 are used for the datalogger, p12 and p13 are unused, and p14 and p15 are used for the servos. Is that correct? If so, you have plenty of free pins for the RTC. There is no reason that you have to use certain pins for certain functions. For example, in the program below, you can change the pin declarations at the top from 0, 1, and 2 and make them 2, 3, and 4 instead in that order. And don't forget to move the corresponding electrical wires up in the same manner. The same thing goes for the program in the App notes, where the pin numbers are declared as constants, but the same idea applies.
When you say, "Every hole down the center of the board is occupied", I think you must mean something other than the electrical connections. Maybe they crowd one another physically. That is a different matter, but I'm confident the team will find a solution.
' {$STAMP BS2} ' {$PBASIC 2.5} ' program to demo simple operation of the DS1302 real time clock ' sets time and starts operation ' displays second by second on debug screen DSclk PIN 0 ' <--- you can move these pins numbers to 2, 3, and 4, instead of 0, 1 and 2. DSdta PIN 1 DSce PIN 2 second VAR Byte minute VAR Byte hour VAR Byte date31 VAR Byte ' day of month month VAR Byte day7 VAR Byte ' day of week year VAR Byte second0 VAR Byte initialize: OUTS= %0000000000000000 INS = %0000000000000111 DEBUG CR,"top",CR ' send $00 to clock control register (command $8E) to enable write HIGH DSce SHIFTOUT DSdta,DSclk,LSBFIRST,[noparse][[/noparse]$8E,$00] LOW DSce ' set the clock time using burst command $BE ' second=0, minute=0, hour=0, date31=2, month=3, day7=1 (Sun), year=08 ' you can set it to whatever date and time you want HIGH DSce SHIFTOUT DSdta,DSclk,LSBFIRST,[noparse][[/noparse]$BE,$00,$00,$00,$02,$03,$01,$08] LOW DSce tick_time: ' display time advancing at one second intervals DO HIGH DSce SHIFTOUT DSdta,DSclk,LSBFIRST,[noparse][[/noparse]$BF] ' burst mode read $BF command SHIFTIN DSdta,DSclk,LSBPRE,[noparse][[/noparse]second,minute,hour,date31,month,day7,year] LOW DSce IF second<>second0 THEN ' only display when seconds change DEBUG CR,HEX2 month,"/",HEX2 date31,"/20",HEX2 year DEBUG 32,HEX2 hour,":",HEX2 minute,":",HEX2 second second0=second ' track old seconds for change ENDIF LOOP▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· It seems as though we have the RTC wired where it actually works along side (but independently of) the humidity sensor and robot motors. Tracy's suggestion that we reassign pin numbers·seemed to be·the solution.··
(NOT)·Attached is a JPEG of the robot-RTC-humdity sensor wiring in situ (SORRY, IT DIDN'T UPLOAD. I have dial-up Internet. I'll get to Andrew to post it after practice today.)
Attached are·three programs.·Two are for the RTC ('RTC_Tracy_March_01.BS2' and 'Elapsed time.BS2'). The third program ('ROCKET_ROBOT_WITH_RTC_March_02.BS2') is a hybrid of 'Elapsed time' and the current version of 'ROCKET_ROBOT.BS2' that we're running. This program·LOOPS the time/clock sequence but the humidity sensor and motors do not initialize (because the program is looping 'above' it in the sequence.)
We've·already experimented·with adding·a GOSUB routine (GOSUB Get_Data) into the RTC/clock subroutine. It works somewhat in that it succeeds in initializing the humidity sensor and running the robot/motors subroutines quite well... at the expense of shutting the clock off···
Guys, it seems like we got·over·some hurdles fast. The RTC works, we have a program that makes it run, and the RTC, robot, and sensor even run on the same board. So where do we go from here? The rest of the team arrive in about an hour and we all afternoon to play! (But the power's out because of a wind storm. Glad we have a battert back-up system!)
Regards,
Mark
This is Andrew, posting from Mr. Kibler's house during our practice time. We've·tried to·"paste" various RTC programs in to our current program with no luck. All of the programs seem to do something, but not what we want. How can we properly add one of these RTC programs into our current program so we can have the time displayed at the end of each piece of data? Also, I've attached the photo of the robot's wiring. Thanks for your help!
Andrew
Photo available at: http://i26.tinypic.com/p9dfk.jpg
Can you at least show us one of the programs you're using, so that we can try to adapt it to your needs. Otherwise you're asking one of us, here on the Stamp Forum, to write an entire subroutine to "add the time ... at the end of each piece of data". It's not that we're unwilling, but where's the education for you in our writing the subroutine?
Please choose one that you feel comes closest you your needs. We'll handle the rest from there. Please use the attachment manager, as you've done before, to upload the program you've selected.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's
But again you need to combine different projects into one, and troubleshoot that. The RTC is a new element. It is a much more difficult process as you are finding out, and you generally can't simply "paste" one to another. That ends up with Frankenstein's monster. To combine these projects you really do have to rebuild them so as to be consistent with one another, and to do that, you have to understand the basics. We will help with that here. I do hope you will have a chance to go through the Stamps in Class texts at some point in time and develop you own basic skills in PBASIC programming. You can't expect any project to work the first time! (Although it is very satisfying when it does!) So don't throw up your hands in despair. Troubleshooting is a fine art, and again, it depends on understanding, logic and/or educated intuition.
None of the RTC programs that were presented as examples are in any way appropriate for "pasting" into the existing rocket_robot program.
Please provide clear answers to questions and follow instructions.
Is the following the current pin deployment?:
p0 and p1 for the Sensirion.
p2, p3 and p4 for the RTC
p5, p6 and p7 unused
p8, p9, p10 and p11 for the datalogger
p12 and p13 unused
p14 and p15 for servos
I an going to ask you (as have others here) to install one LED and one 1kΩ resistor as a status indicator on one of the unused pins. I'll send you a photo of how I'd like you to do that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
You asked that we "please provide clear answers to questions and follow instructions.·
Is the following the current pin deployment?:"
A) Question: Are p0 and p1 for the Sensirion? Answer: Yes, p0 and P1 are used by the Sensirion
C) Question: Are p5, p6 and p7 unused? Answer: p5 and p7·ARE currently being used by the RTC (see Andrew's photo two posts before this)
D) Question: Are p8, p9, p10 and p11 used for the datalogger? Answer: Yes,·p8, p9, p10 and p11 used for the datalogger
E) Question: Are p12 and p13 unused? Answer: Yes, p12 and p13 are unused.
F) Question: Are p14 and p15 for servos? Answer: We are not sure. Nothing is plugged into p14 and p 15 on the 'p0-p15 column'. The servos ARE plugged in to #14 and #15 3-pin ports on the X4 'vdd'.
Other: On the 'p0-p15 column', p3, p4, p6, p12, p13, p14 have nothing in them.
We·hope this helps. And we hope the the photo is helpful too. What instructions do you want us to follow?
Thank you,
The Rocketeers (and Mr. Kibler!)
We posted three programs earlier today,·a few posts back. 'ROCKET_ROBOT_WITH_RTC_March_02.bs.2' is the robot movement and humidity sensor program with a preliminary RTC program pasted into it. None of the variables, constants, etc. seem to be duplicated in this cut-and-paste attempt at making the program work, because the program does upload to the Parallax Board of Education. It just runs one part of ther program, not all of it(looping and showing the elapsed time display, for example.)
The other two programs run the RTC by itself, displaying the 'running time' and date in·two different formats. The programs are called "Elapsed_time.bs2" and 'RTC_Tracy_March_01.b2s."
Practice was long today. We went from before noon until after 8 PM on a sunny Sunday when·most other students were out enjoying the last day of February school vacation. These·rocketeers didn't, and they are feeling the weight of the project, and all the long hours they've graciously given to try and understand programming in order to achieve their project goals. It's hard stuff if you're new to it, especially if you're only·in 7th grade (or old and feeble-minded like me.) I give them lots of credit for sticking with it this far, and I am proud of them. I am also very thankful for everyone's kind and generous help. "It takes a village to raise a child" they say, and together we're raising a vertitable small family. WE are the change we wish to see in the world (Ghandi). Thank you for making a difference.
Mark
What I'd like you to do is to add a signal light to the board, at least temporarily, to help with troubleshooting when the robot is not attached to the PC.
Please locate an LED (light emitting diode) and a 1/4 watt resistor in the range of 270 to 1000 ohms. The color of the LED does not matter and the exact value of the resistor in that range does not matter. If you do not have one in the kit, it is possible to buy one at Radio Shack.
Notice that one leg of the LED is longer than the other. Cut that one off short, as shown in the first photo below, and also cut off one lead of the resistor short and solder them together. You can hold the opposite leads in a vice, and a light touch with the soldering iron will make quick work of it. Then trim off the other lead of the resistor so that it is even with the uncut LED wire.
Plug the assembly into your boe as shown in the second picture, across the expansion holes that are labeled p12 and p13. Resistor to p12. Incidentally, those are the same signals as the ones labeled p12 and p13 in the single long row next to the white block. The BASIC Stamp simply has 16 i/o signals, and the BOE has several different places where you can connect up to the same signals. That is also true of the servo signals, which are the same as p14 and p15.
Then power up and run the following program. The LED should turn on and off at a leisurely 1 second pace.
'{$STAMP BS2} '{$PBASIC 2.5} LOW 13 HIGH 12 DO NAP 6 TOGGLE 12 LOOP▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· The LED-resistor device you showed us how to make is made. It gives a nice steady, 1 second blink-blink-blink (in green nonetheless.) What's its purpose: to show·that the RTC/crystal are working?
Believe it or not, my students and I learn something new every day. Maybe it's not 'big potatoes' or a new theory or relativity, but we are learning. Much of what we're learning-- teaming, problem solving, deductive reasoning, time management, for starters--- finds its way into my classroom, others students' schools, and beyond. Thanks for your mentoring and patience.
Off to bed now. It's late, and I'm up and out early in the morning (which is coming all too soon) to teach more bright and eager minds. Thanks·again.
Good night·from (yawnnnnnn) NH,
Mark (the Rocketeers better be in bed!)
The next step will be to integrate the RTC routine into the program. As you noted, the program posted above, "ROCKET_ROBOT_WITH_RTC_March_02.bs2 " simply patches the RTC routine onto the front end of the program and the program is stuck forever in the clock loop. I'll help you implement the following structure:
INITIALIZE powerup delay, clock, datalogger and pins
MAIN:
DO
sychronize to clock, read clock
open datalogger file for append
write elapsed time to file
read Sensirion and write its data to file (10 times, why?)
close the datalogger file
execute movement sequence (best when on ground?)
LOOP
As it stands, the real time clock will be reset to time=00:00:00 when the power is applied to the robot. You are still planning on the nylon dowel scheme to apply power at the zenith, right? The data logger will record the time elapsed from that instant. That is the first step in the new program. Keep in mind that it would be possible to have real clock time instead of elapsed time. That will take a little more work later on, because the RTC would have to have backup power. It depends on what you want it to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
sequence, a command to delete the old data file. This code was dropped long
ago.
Perhaps now is the time for it to be restored?
The command for deleting the old file is:
Unless the old file is deleted, the flash drive will keep accumulating
records every time the Stamp is powered on or reset. Probably not
what is wanted for the actual flight.
Post Edited (phil kenny) : 3/3/2008 5:55:33 PM GMT
··· We wanted to read and write data 10 times so we can take the average of the data at·that particular spot (rather than risk having only one data point per sampling.) If the robot can simulataneously read, record, move,·and log elapsed time, all the better. But at this juncture I'm reminded of Sir William Of Occam (of Occam's Razor fame): "The simplest solution is usually the best", especially in our case, and time is not on our side.
You commented: "As it stands, the real time clock will be reset to time=00:00:00 when the power is applied to the robot." That's a good plan, and·it should work well to allow us to·compare flight time with altitude/flight·time·(on our altimeters).
You asked: "Are you are still planning on the nylon dowel scheme to apply power at the zenith (apogee), right?" Yes, that's still the plan. It worked well last year to power up the robot, and the rocket and·the robot are·already hardwired for it.
You also mentioned: "Keep in mind that it would be possible to have real clock time instead of elapsed time. That will take a little more work later on, because the RTC would have to have backup power." I sorta figured that out because the RTC/elapsed time showed 1:30:35 (for example) an hour and a half after I thought I shut things down (the power to the board·was still plugged in and so the RTC was reading the whole time.) Then, when I expected to see elapsed time (another time) it was at zero (because I had unplugged the power supply!)·Can we·save this project ( a fully powered real clock time) for another project?!
So what do we do next? I see several items on·your 'to do' list; it looks like INITIALIZING the power-up delay, clock, datalogger and pins is first, then a MAIN: subroutine. What can I do to help? By the way, Andrew ordered two more RTC's and crystals today·so he can install them on the other Board, and so we have a back-up.
Andrew and Tim, what questions do you have? Please post them, and/or comment.
Regards,
Mark
· Thanks for your post. Yes, the flash drive does accumulate data (and lots of it!) if we forget to delete the 'old' date from Notepad each time. Hopefully, adding an elapsed time and a date 'timestamp' will remedy this glitch. Where in the program would you suggest that we add the 'delete old data file' command that you posted? Thanks for hanging in here with us!
Mark and the Rocketeers
your enter the loop that opens the data file.
Unless the battery backup feature is added to your RTC, every time
you turn power on to the Stamp, the clock starts at
01/01/00 00:00:00
The backup battery is just a small Lithium type, but does need a battery
holder.
Once that is working, you just set the clock and it will keep ticking
even when the Stamp power is turned off. These batteries are good for
a number of years.
If you manage to get that wired up, the time stamp logged to the flash
drive will let you see the time of day when the various data sets were
recorded.
I brought up the old idea of deleting the data since the backup battery
circuit was not yet functioning and I was thinking that there wouldn't be
any way to tell new data from old data. Reflecting a little more, there is
a way. Each new record would start with a time stamp of 01/01/00 00:00:00.
So, maybe you don't need the delete command after all.
It is much safer not to have the command for deleting the old data. Then
there's no danger of accidentally erasing the flash drive if the power glitches.
phil
Post Edited (phil kenny) : 3/4/2008 12:52:36 AM GMT
I think you will want to log data frequently during the descent, when conditions are changing rapidly. Right? And there is no point in running the servos during that period. It would be nice to take data once per second during the descent. So I would suggest delaying the movements until one of the following conditions is met, whichever comes first:
1) a certain amount of clock time has elapsed (do you know about how long the descent will take?)
or
2) the temperature and humidity readings stabilize within some tolerance, as you would expect (?) to happen once the robot is sitting in one spot on the ground.
By the way, will the robot be landing assuredly on smooth enough ground for boebot motions?
Another thing. If you are interested in an average reading, PBASIC could do that on board using your 10 separate readings, and then log only the average for each point in the file along with the elapsed time stamp. Then move to the next location, and so on. However, it is not an issue of storage space on the thumb drive. You have plennnnnnty of room there. Incidentally, I agree that data should only be appended to the file on the thumb drive, and only delete the file when you have it attached to the PC.
I looked at your programs last evening, and will come up with my take on a restructured program later on today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I have been reading the forum at my school through their wireless connection. It is still not working at my house for some reason...
Andrew
You commented:
* I think you will want to log data frequently during the descent, when conditions are changing rapidly. Right? And there is no point in running the servos during that period. It would be nice to take data once per second during the descent.
Yes, we would like to record data as frequently as possible upon descent. One second intervals would be good.
We also agree that running the servos during descent is relatively pointless. The only reason we have the robot·moving and collecting data·is for proof of concept (and·as visual verification, and gratification·to a bunch of kids for whom delayed gratification is sometimes a stretch. We've been fortunate to keep them so engaged, at such a high level, for so long...!)
·* So I would suggest delaying the movements until one of the following conditions is met, whichever comes first:
·
1) a certain amount of clock time has elapsed (do you know about how long the descent will take?)
·· or
2) the temperature and humidity readings stabilize within some tolerance, as you would expect (?) to happen once the robot is sitting in one spot on the ground.
I just spoke with Anna at rocket team practice. She feels that option #1 is preferable over option #2, and I agree. We would like to have the robot's ground movement subroutine start five minutes·after the data logger has been initialized·during descent, then have the 'get-data' subroutine loop back and forth with the·ground·movement subroutine (as it is right now) to infinity (until we locate the robot.)
*By the way, will the robot be landing assuredly on smooth enough ground for boebot motions?
Last year's launch was at Marshall Space Fligth Center's Redstone Aresenal #1. It's a lonnnnnnnnnnnnnnnng field with very low cut grass, similar to a sod farm. It's probably 2 miles long and a mile wide. The robot will assuredly be landing on a surface that's smooth enough to run on (assuming the·parachutes come out...!) They did last year.·If not, then it's scrambled 1's and 0's.
Thanks for your reply!
From the lab,
Mark (the Rocketeers have left gone home)