Combining Temp/Humidity Sensor Program with a Simple Movement Program
Andrew (ARLISS)
Posts: 213
Hi everybody,
I have two programs: The first program takes data from a temperature/humidity sensor and saves it to a log file on a USB drive. The second program is just a simple program that makes our robot move forward, backward, turns, etc...
What we would like to do, is combine the first program with the second program so we can have our robot move, and sample the temperature at the same time. I do not know a lot about the PBASIC language. What should I do? (I've attached both programs to this post)
Andrew
Using a 'Board of Education' with a BS2 Stamp
I have two programs: The first program takes data from a temperature/humidity sensor and saves it to a log file on a USB drive. The second program is just a simple program that makes our robot move forward, backward, turns, etc...
What we would like to do, is combine the first program with the second program so we can have our robot move, and sample the temperature at the same time. I do not know a lot about the PBASIC language. What should I do? (I've attached both programs to this post)
Andrew
Using a 'Board of Education' with a BS2 Stamp
Comments
If you want to sample and log for a while, then move the robot
in a certain direction after it is done moving, then sample and log
again, then a Stamp can be used.
To do both at the same time will require a different approach, such as
using two separate Stamps, etc. No doubt, others that have robotic
experience can offer different solutions.
phil
·· I was talking with Christopher when we took him back to school this afternoon and here's what we think:
1) It may not be possible to run both programs at once on the Parallax board. You might have to run·one program as a subroutine of the·other, then switch the two back and forth.
2) We theorize that if we do this, each time you switch from 'run the robot mode' back to 'capture humditiy data mode', the original·humidity data·will be overwritten!
3) Mrs.Kibler disagrees. She believes that each time the 'capture humidity' subroutine runs, that·data that's captured will be saved and written as separate data 'packets'. I'm uncertain. Can someone else on the forum clarify?
Andrew, did you cut and paste the two programs yet and try to 'debug' them? That seems like a good starting point. Try the 'capture data' program as a subroutine of the 'run the robot' main program and see what happens. Read teh book I gave you, and experiment. Try different permutations of the program sequence and see what happens. Try to figure it out, and ask for help when you need it.
Good work!
Mr. Kibler
10 PM Monday
http://www.parallax.com/Store/Accessories/MotorServoControllers/tabid/160/ProductID/481/List/1/Default.aspx?SortField=ProductName,ProductName
It will relieve your Stamp from "constantly" running the two wheel-driving servos and give you time to collect and process the data from the sensors, getting back to controlling the wheels on a more casual basis.
As for where you write your sensor data observations, check out this section of your Program 1 - temp and humidity.bs2··program:
· DEBUG "Opening USB Flash Drive Data File ..."········· ' First Delete File
· SEROUT TX\CTS, Baud, [noparse][[/noparse]$07, $20, "datafile.txt", CR]
· GOSUB Get_Data······················· ' Purge Receive Buffer
······································· ' Then Create File
· SEROUT TX\CTS, Baud, [noparse][[/noparse]$09, $20, "datafile.txt", CR]
Note the use of the "$07" and "$09" sub-arguments to the SEROUT command.
Those are the key to how your program is treating a pre-existing data file and its contents.
To find out what those two values ($07, $09) do, see this documentation, page 11, Table 4.1:
http://www.parallax.com/Portals/0/Downloads/docs/prod/comm/VDAPFirmwareSpec.pdf
There may be other parts of the program that you might want or have to change,·(I didn't scrutinize it that closely), but the above should get you started, to find out whether you or your wife is correct, and whether there is a solution at hand.
PAR
The program that reads the sensor and writes the data to the file consists of three parts. Part one initializes the Datalogger and prepares it to receive data. Part two reads data from the sensor and writes it to the file after any existing data is written. There is a short part three that closes the file at the end of the mission. The key to moving the robot and continuing to log data is that the movement stuff has to be incorporated into part two, not part one or three.
There's a FOR / NEXT loop that makes up part two and there's a PAUSE 1000 statement in that loop that just waits a second between measurements. You need to have a subroutine to do the movement and the GOSUB for that subroutine takes the place of the PAUSE. Essentially, after writing a line of data to the file, the subroutine does some movement, then returns. Another measurement is done and written to the datalogger, then another possible movement is done.
I'm not sure I understand where everything is supposed to go. What exact part of the movement program goes into part two of the datalogger program, and exactly where? If you want, both programs are attached to the original post above [noparse]:)[/noparse]
Thanks for your help,
Andrew
I re-read this thread a couple of times and it is still unclear what the BOE-Bot will be doing. You want it to move, but you don’t specify what it will be doing. Will it be roaming? It is monitoring sensor for obstacle avoidance? How often will the readings to the sensor be logged? One important thing in any design is to clearly define all the details in advance. This saves time later trying to add something to existing code that could have been factored in at the beginning. As you have seen, trying to combine two pieces of code is not trivial when you’re not familiar with either piece of code.
After watching your previous thread trying to merge the Sensirion Temp/Humidity code with the Datalogger code I had hoped that would give you a good understanding of what was happening within the code. Of course, reading the “What’s a Microcontroller?” tutorial or Robotics with the BOE-Bot would certainly have helped in that sense. Most programs have a declarations section where constants and variables are defined. This is usually followed by an initialization routine where I/O pins are setup and devices may be initialized (such as the Datalogger). This is usually followed by a main program loop in which most of the program flow occurs. This main loop will often branch to various subroutines which handle repetitive tasks. I think this is very important to understand in order to realize your design goals. Experimentation also helps. The DEBUG command can be used to follow sections of code and where they are executing, as well as the state of variables at that point within the program. I hope this helps. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Our robot's movement program is just written to make the robot go forward, back, turn, etc... over and over again. We would like our robot to not only move, we would like it to move, and then every few seconds we would like it to stop moving, record the temperature, then continue moving.
Like I had said before, I do not know a lot about the PBASIC language. I do have the book, Robotics with the BOE-Bot, and I will be reading it trying to learn more about programming.
Thanks for your help,
Andrew·
It really does, as Chris pointed out, help to have an understanding of what the code does. The best procedure is to take two different programs that you want to merge, and essentially rewrite them using your own template and with careful allocation of the variables.
In a couple of ways it would be easier if you were working with a multi-slot Stamp, like the BS2pe, instead of the single slot BS2. For one thing, in your earlier thread, you had almost filled up the program memory with the Sensirion and USB-logger code, and now you need to add the Robot motion code to that. It may take some fine trimming of the code to fit it all in. With the multislot Stamps, that is much less of a problem, because you could allocate different slots to each function. The multislot Stamps have other resources as well, such as the scratchpad RAM that takes the pressure off the number of variables you can have. There is a learning curve to that, too, as with everything. I'm not saying it can't be done with the vanilla BS2, but it looks like you will have to do some careful pruning to make it all fit.
The routines will be scheduled so that data from the sensors can be safely written and the same variables can be used for other purposes for robot motion. Careful consideration has to be given to which variables serve temporary purposes and can be shared, and which ones need to be dedicated to one particular task. In programming a single-tasking controller like the Stamp, the tasks take turns and it may happen so fast that it seems that the tasks are occurring simultaneously.
Your robot is not running a time trial, and it does not have to measure temperature and humidity so frequently on the ground. It may move more like an ant than like a figure skater, but that is okay!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/5/2008 7:21:21 PM GMT
Thanks for your help. It seems so annoying that it would be so difficult to just add a simple movement program to the datalogger program. I guess I'll be working it out throughout the week. I'll let you know how things work out.
Thanks again,
Andrew
The main difficulty is that you have two cyclical operations going on. The data logging operation is getting a reading, then writing it to the Datalogger, then repeating. The movement operation is performing certain movements in order, then repeating.
If you don't need to overlap them, you could get a sensor reading, then write it to the Datalogger, then do a set of movements, then repeat this whole thing. If you do need to overlap them, then you need to keep track of what movement you've done and what comes next. You have to read the sensor, write the values to the Datalogger, then do a single movement or part of a movement, then go back for another cycle where you'll do another single movement or part of a movement, then go back again.
·· Thanks for your replies to young Andrew (and I, who monitors his, and other teammates' progress.) To clarify, here's what our robot is supposed to do. You can see·the robot·in the 'CDR' report on our team's website (www.wearerocketry.org)
1) Deploy robot from a rocket.
2) Parachute to the ground (recording humidity and tempertaure data as it descends.)
3) Land, then move forward 1 meter. Collect humidity and temperature data the entire time (if possible.)
4) Stop, then·reverse for 30 cm. (in·case there is an obstacle in front of the robot. This is our very simplified 'obstacle avoidance subroutine...!')
5) Stop, turn 45 degrees, then motor ahead 1 meter.
6) Repeat as above to infinity (until we locate the robot, that is,·or until the batteries expire.)
Ideally we would like to capture humidity data as the robot moves. Realisitically it looks like we'll have to program our robot (Phidippides) to move, stop, then sample data, repeating these subroutines as needed.
I can't say how much I really appreciate everyone's willingness to dive in and share your expertise. We are new to programming, but (as you once did) we are learning. Each of you will be able to rightfully say that you·had a very active part in programming a robot that was launched at Marshall Sapce Flight Center, Alabama (April 26, 2008.) How many people can say that? What an absolute thrill it would be for EVERYONE if you could come and watch (y)our rocket launch, and (y)our robot descend and motor across the ground this April. You are certainly invited to join us. You, too, are teachers! Thanks so much for your help.
Mark Kibler
Attached as file is a (rough) program that makes the robot run a VERY simple movement routine, just enough that we can see it move. Then the humidity sensor program·starts. However, the humidity sensor program seems to get 'hung up' when it tries to initialize the Datalogger.
That's as far as I could get tonight;I'm still trying to get over this cold.· See what you can do with it. The robot's entire ground movement ('obstacle avoidance') program is·pasted·at the end of the attached program as text. I'd like to see the robot run, then stop and collect data, then move one meter, collect data,·then do it all over again to infinity (until we locate the robot.)
If anyone has any suggestions on how we can accomplish this, and more efficiently, we would certainly appreciate your help debugging the program.
Thanks!
Mark
Note that there's not enough room in the EEPROM as it stands. You'll have to remove
some of the DEBUG statements to make room and I'm not sure how many or what your
priorities are for keeping them. At some point it will all fit.
I downloaded your attachment, Robot and Humidity Sensor.bs2.·Since the EEPROM was full, I·have shortened some of the phrases on the DEBUG lines like "Opening USB Flash Drive Datalogger File" to "Opening Drive File". I did that with several lines and now the EEPROM is no longer full. However, I'm getting a new error message that states, "Error 135, Expected a variable". Then it goes and automatically highlights the letter 'i' in the following section of the program.
What does "expected a variable" mean? Why does it jump to the letter, 'i', and what should I do to fix this? I've attached the current version of the program to this post.
Thanks,
Andrew
That kind of error would certainly imply that the variable "i" was not defined, or if it was at one time, it has been removed, commented out, or otherwise lost. Check to make sure there is a variable definition for it. It should look something like this:
i VAR BYTE
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
I have added the variable definition, i VAR BYTE, and now the program downloads to the robot and runs. The robot appears to record data, move, record data, move, etc... However, after it records data and runs the movement program, the robot 'erases' the last chunk of data, so the only data from my flash drive when I plug is from the last cycle. What might be wrong with the program that I need to change?
Thanks,
Andrew
To be perfectly honest, I haven't looked at your program, as there seemed to be an ample number of others assisting. That being said, my crystal ball tells me to look for some variable which is not being incremented, or is not being incremented properly. Another cause might be only visiting the write routine on the last pass rather than on each pass. In this case the GOTO or GOSUB may be in the wrong place.
The problem may be elsewhere, but that's the kind of thing I'd check for first.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
Is the file being closed before the memory stick is removed (or before the power is turned off)? That's the only obvious issue.
If you read the Vinculum firmware description from the link on the Datalogger's webstore page, you'll see that the first byte
sent to the Datalogger is a command. The $07 is a delete file (for any previous datafile). The $09 is an open file for writing.
The $08 is a write file data and the $0A is a close file. The $08 is followed by a space ($20), then a write count in 4 bytes in
binary format (0,0,0,14), then a carriage return ($0D), then the data. There's a final carriage return that's optional, but
forces a standard error response. The 14 bytes of data include all punctuation including the final carriage return and line feed.
I looked at the code in the section involved and it looks like it should work properly. I'm not sure why it's behaving like it does.
Perhaps someone else can spot the problem. The portion of code involved is:
FOR counter = 1 TO 100 GOSUB SHT_Measure_Temp GOSUB SHT_Measure_Humidity DEBUG "#",DEC counter," ",REP "-"\tC.BIT15,DEC ABS tC/10,".",DEC1 ABS tC DEBUG ", ",DEC rHLin/10,".",DEC1 rHLin,CR,LF SEROUT TX\CTS, Baud, [noparse][[/noparse] $8,$20,0,0,0,14,CR,tC.BIT15*13+32,DEC3 ABS (tC/10)] SEROUT TX\CTS, Baud, [noparse][[/noparse]".", DEC1 ABS tC,",",DEC3 (rhLin/10),".",DEC1 rhLin] SEROUT TX\CTS, Baud, [noparse][[/noparse]CR,LF,CR] PAUSE 100 ' Delay in Writing Data is 100 ms GOSUB Get_Data ' Purge Receive Buffer IF counter > startRobot THEN SELECT (counter - startRobot) // 6 CASE 0 GOSUB backward CASE 1 GOSUB forward CASE 2 GOSUB turnclockwise CASE 3 GOSUB backward CASE 4 GOSUB forward CASE 5 GOSUB turncounterclockwise ENDSELECT ENDIF NEXTThanks for your assistance. I'll keep tinkering with the program to see if I can find the problem.
Andrew
I've looked into the program a little and I couldn't quite understand when and where in the program is supposed to "close" the datafile. I'm only getting blank files on my USB flash drive, and I'm not sure why. Any suggestions?
Thanks in advance,
Andrew Mahn
'EVERYTHING AFTER THIS POINT IS EITHER TERMINATION STUFF (TO CLOSE THE ******* 'USB FLASH DRIVE FILE) OR SUBROUTINES USED BY THE PROGRAM IN GENERAL. ******* 'THIS SHOULD REMAIN INTACT NO MATTER WHAT IS ADDED FOR ROBOT MOVEMENT. ******* DEBUG CR, "Closing drive data file..." DEBUG "*ALL DONE*", CR, CR, CR SEROUT TX\CTS, Baud, [noparse][[/noparse]$0A, $20, "datafile.txt", CR] GOSUB Get_Data ' Purge Receive BufferWhen you're reading someone else's program, read the comments.
Comments are supposed to tell you what the program is doing in
general terms or functional terms. Keep that in mind when you
write your own programs.
Thanks, but I do not understand at what point the robot is notified to close the file. Why am I getting blank data files?
Thanks in advance,
Andrew
If you read the Datalogger firmware manual, you'll see (in the description of the close command) that all files opened for writing have to be closed in order for the flash drive directory to be updated with the final file size. When the file is opened, the Datalogger doesn't know the file size, so it's set to zero. If the drive is removed or the Datalogger is turned off without closing the file, the directory entry still has the incorrect file size and, when you try to read the file on your PC or later on the Datalogger, the file will show up as empty.
The "open file for write" command will normally append new data to the end of an existing card. What you may need to do is to move the "open file for write" command into the FOR loop and move the "close file" command into the loop at the end as well. This will cause the flash drive directory to be updated with every sensor reading, but it will take more time to do the open and close with each reading. It should still be fast enough for your purposes. If I have time later this evening, I'll post an example of this. See if you can figure out how to do it based on what I've described.
I will try to modify the program myself based on what you have told me, but, if you could also post an example, it would be greatly appreciated. Thanks for your time,
Andrew
I downloaded the last version from the forum, added the declaration for "i", and moved the open and close commands (SEROUT, then GOSUB Get_Data) into the FOR loop.
Thanks again for all of your time. So, when I took your program and downloaded it to our robot, it took about 20 samples from the SHT11, ran the movement program, and sampled the temperature every few seconds. After about a minute into the program, it would restart and it would say "DELETING OLD FILE" and I lost whatever it had before. I know the program is supposed to loop, but why does it keep looping "deleting old file". Is there a way to change this, and how?
Thanks again,
Andrew
Another possibility is a programming error like the use of a RETURN without a matching GOSUB or too many GOSUBs without a RETURN, but I don't think there's anything like that in your program (you should look again at it, but I don't remember that).
There is a good chance my batteries are low. I guess I'll pick up a new pack of batteries tomorrow. I will post back here when I find out a solution.
Thanks for your help,
Andrew
EDIT: Attached is the most recent version of the program.
Post Edited (Andrew Mahn) : 2/8/2008 11:30:51 AM GMT
· I think we're almost there!·
Andrew, the debug was as simple as adding·a subroutine (GOSUB), as Mr. Green suggested, that you see below between the two lines
:
· NEXT
··· DEBUG CR, "Closing File..."
··· DEBUG " * DATA SAVED*", CR, CR, CR
··· DEBUG "*RESTART ground movement and data collection sequence*", CR
··· SEROUT TX\CTS, Baud, [noparse][[/noparse]$0A, $20, "datafile.txt", CR]
··· GOSUB Get_Data
'
··· GOSUB MAIN
'
········································
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
In my excitement I forgot to attach the program files! Here they are...
Mr. Kibler