Combining Temp/Humidity Sensor Program with a Simple Movement Program

Andrew (ARLISS)Andrew (ARLISS) Posts: 213
edited 2008-12-14 - 15:07:46 in Learn with BlocklyProp
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
«13456711

Comments

  • phil kennyphil kenny Posts: 233
    edited 2008-02-05 - 00:52:05
    The Stamp can do one thing at a time.

    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
  • Mark in NHMark in NH Posts: 447
    edited 2008-02-05 - 02:58:18
    Andrew,

    ·· 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
  • PARPAR Posts: 285
    edited 2008-02-05 - 04:13:56
    I know you don't want to complicate your project with new hardware and additional programming considerations (and money) just yet, but do consider the relatively inexpensive Parallax servoPAL·product:

    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

  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-05 - 05:10:50
    Mark,
    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.
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-05 - 12:13:06
    Mr. Green,
    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
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2008-02-05 - 15:43:12
    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
    Chris Savage | Engineering Tech | Main Office: (916) 624-8333 | Direct to Tech Support: (888) 997-8267 | Website | Twitter | Google+
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-05 - 16:08:52
    Chris Savage,
    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·smile.gif
  • Tracy AllenTracy Allen Posts: 6,405
    edited 2008-02-05 - 19:11:15
    If it's any consolation to you, merging programs from different sources is often one of the hardest things to do in programming. Maybe not as problematic as a merger between Microsoft and Yahoo. But there can be a host of differences in program architecture and use of variables and it can take a while to iron all that out. The task on the BASIC Stamp is more daunting, because there are so few variables available, and when a program reaches a certain size, you have to share the variables, so that it is used for one purpose here and another purpose there, without zapping important data in between.

    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
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-05 - 19:22:37
    Tracy Allen,
    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
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-05 - 19:53:48
    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.
  • Mark in NHMark in NH Posts: 447
    edited 2008-02-06 - 01:09:05
    All,

    ·· 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
  • Mark in NHMark in NH Posts: 447
    edited 2008-02-07 - 02:45:43
    Andrew,

    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. shakehead.gif

    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
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-07 - 05:01:01
    Here's a copy of your current program with comments and robot movement changes.
    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.
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 12:24:24
    Mr. Green,
    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.
    forward:
       FOR i = 0 TO 60
       PULSOUT 12, 850                           ' move forward 1
       PULSOUT 13, 650
       PAUSE 20
       NEXT
       RETURN
    

    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
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2008-02-07 - 13:49:33
    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!
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 14:11:28
    Bruce,
    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
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2008-02-07 - 14:48:08
    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!
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-07 - 19:32:16
    Andrew,
    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
    
      NEXT
    
    
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 19:36:43
    Mr. Green,
    Thanks for your assistance. I'll keep tinkering with the program to see if I can find the problem.
    Andrew
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 19:57:26
    Everybody,
    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
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-07 - 20:17:19
    Here's the part of the program that closes the file:
    '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 Buffer
    
    


    When 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.
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 20:22:16
    Mr. Green,
    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
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-07 - 21:14:10
    The robot is not "notified" to close the file. The way the program is currently written, it has to go through a certain number of read sensor / write Datalogger / move robot cycles before it exits from the FOR / NEXT loop. The program then continues with the DEBUG statement that shows "Closing drive data file..." and then "*ALL DONE*". The next statement sends a close file command to the Datalogger (the $0A followed by the other stuff), then waits for the Datalogger to finish (the Get_Data call).

    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.
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 21:22:22
    Mr. Green,
    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
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-07 - 21:45:47
    Here you go ...

    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.
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-07 - 23:10:25
    Mr. Green,
    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
  • Mike GreenMike Green Posts: 22,923
    edited 2008-02-07 - 23:56:45
    This type of behavior is usually due to a shortage of power.· The battery reaches a point where it's near the lower limit of what the Stamp will operate at.· Something drops the battery voltage a little lower, usually a motor starting, and the Stamp resets and the program starts over from the beginning.· The loss of the high power drain stops for a little bit and the battery voltage recovers for a little while.· Try fresh batteries or try using an AC adapter.

    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).
  • Andrew (ARLISS)Andrew (ARLISS) Posts: 213
    edited 2008-02-08 - 00:01:27
    Mr. Green,
    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
  • Mark in NHMark in NH Posts: 447
    edited 2008-02-09 - 18:38:32
    ANDREW! Mike Green, and forum friends, (Tim? Tyler?)

    · I think we're almost there!· hop.gif· Andrew, download and run the attached Parallax program. I've also included it as a·Microsoft 'Word' file.·Now, the program·runs the robot's ground movement sequence, switches to 'record humidity data' mode, records the data, then loops back to the start and does it all over again! The only glitch is that is overwrites the previous data with the last data it measures. BUT! It does record data to the flash drive, and it does loop back and forth, making the robot run the ground movement sequence. 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
  • Mark in NHMark in NH Posts: 447
    edited 2008-02-09 - 18:41:45
Sign In or Register to comment.