Shop OBEX P1 Docs P2 Docs Learn Events
Thirty-five pound Monster released by XBee — Parallax Forums

Thirty-five pound Monster released by XBee

treborz17treborz17 Posts: 76
edited 2011-08-28 10:37 in Accessories
My thirty-five pound Madeusa based robot went wild in my wife's spotless fine furnished living room. Damages yes, forgiveness of its operator no. Still under construction, and fine-tuning, I was adjusting down the high speed that the Madeusa - Robot base kit was capable of going when, I inadvertently unplugged the battery from the hand held propeller controller with the Joy Stick and XBee TX that communicates the direction and speed of my 35lb x 32" high robot named "The Parallaxian". Guess what, when the Xbee communication quits the current direction, and speed settings do not.

I need some help, not to get back into the living room -- that is out -- but to figure a way to stop the monster if and when the xbees fail. I have tried a few software changes without much success. Is there a way that the XBee RTS and or CTS connections can be used so that the propeller controller on the robot can take action to stop the unit upon a failure?

I use two XBee Pros, one on the handheld Joy Stick controller and one on the robot.


Transmitting XBee:

XB.Tx("!")
XB.Dec(TURN)
XB.Tx(",")
XB.Dec(SPEED)
XB.CR


Receiving XBee:

repeat
XB.RxFlush
DataIn := XB.RxDecTime (100)
If DataIn == "!"
Val1 := XB.RxDecTime (3000)
Val2 := XB.RxDecTime (3000)
WCtrl.Joystick (Val1, Val2)


Any suggestions appreciated,

Robert

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-08-15 13:33
    A spritzer bottle filled with water works with cats when they threaten to harm furniture. I'm sure the same would work with your Madeusa. Adding salt to the water would no doubt enhance the short-circuit effect and stop it more quickly. :)

    -Phil
  • W9GFOW9GFO Posts: 4,010
    edited 2011-08-15 13:39
    I have my XBee transmitting continuously a character, "D" I think, so that the receiving Propeller chip will halt all operations if this character is not received.
  • ercoerco Posts: 20,256
    edited 2011-08-15 15:50
    You could also add an auto-stop triggered by an acceleration/deceleration over X amount, or one big impact or sound (loud bump).

    Maybe a smart bumper is for you: http://forums.parallax.com/showthread.php?132260
  • johnfosjohnfos Posts: 59
    edited 2011-08-15 16:03
    +1 to W9GFO

    This is "watchdog" technology. The robot needs to expect to hear reassuring words from its controller every so often (every few milliseconds or every few seconds, depending on how much damage it can cause in the meantime). If the robot doesn't hear the reassuring words within the timeout period it shuts down.

    That way, it doesn't matter whether it's the controller or the communication channel that fails. The robot can tell that something has gone wrong. and it can stop until the problem is fixed.
  • treborz17treborz17 Posts: 76
    edited 2011-08-15 22:52
    Thanks everyone for the suggestions. I am still hopeful that I'll come up with the use of RTS/CTS. I need to do a little more research on the XBee. I kinda favor the hardware approach if it's possible.

    Robert
  • John R.John R. Posts: 1,376
    edited 2011-08-16 04:39
    johnfos wrote: »
    +1 to W9GFO

    This is "watchdog" technology. The robot needs to expect to hear reassuring words from its controller every so often (every few milliseconds or every few seconds, depending on how much damage it can cause in the meantime). If the robot doesn't hear the reassuring words within the timeout period it shuts down.

    That way, it doesn't matter whether it's the controller or the communication channel that fails. The robot can tell that something has gone wrong. and it can stop until the problem is fixed.

    "Shut Down" may not be the best choice, depending on the robot configuration. "Stop" or "Go Safe" (defined per robot) are often better choices. Think about "shutting down" a Medusa or other wheeled robot on an incline might not be a good deal. Shutting down a robot with something like an Arm can have negative consequences. I'd prefer not to think about "shutting down" something with an automatic paint ball gun...
  • Blue WolfBlue Wolf Posts: 7
    edited 2011-08-16 17:32
    You could also look at "reading" the RSSI signal that the XBee puts out, but it would be delayed. If the signal strength goes away, shut down your system. However I have to agree with an earlier user. Watchdog programming would be much "safer" and easier to accomodate for a system. Start a timer every time you send something from the "remote". If is doesn't hear something within XX amount of time, disable the motors. If it sees something come in, then reset the timer.
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2011-08-16 18:37
    RxDecTime returns a -1 if no data received in time.

    You could increase the initial rx grab to ensure data should be received in that time, if no "!", but a value of -1, stop the bot.

    -Martin
  • treborz17treborz17 Posts: 76
    edited 2011-08-17 07:07
    I like the "Watchdog" Technologies idea, especially using some of the code that I am already using and, are familiar with, but I hate to omit it but I don't see where the -1 would be coming from if the scenario is that the transmitting XBee and controller fail while motors are in motion. As usual I'm missing one little thought on how this is to be coded.

    Thanks for all the help everyone -- I'll work on it. I'm bound and determined to make this idea work. This safety shut down is important to me -- after the bugs are worked out the ideas are going to be used on my Power Wheel Chair I need when out of the house -- the thought being that a person with the JoyStick could could walk along side and guide the power chair for those that may not be able to satisfactorily guide it themselves or for just a safety standby while out in the real world. Also, I am working on autonomous safety sensors for obstacles, stair wells, etc..

    ====================

    Transmitting XBee:

    XB.Tx("!")
    XB.Dec(TURN)
    XB.Tx(",")
    XB.Dec(SPEED)
    XB.CR


    Receiving XBee:

    repeat
    XB.RxFlush
    DataIn := XB.RxDecTime (100)
    If DataIn == "!"
    Val1 := XB.RxDecTime (3000)
    Val2 := XB.RxDecTime (3000)
    WCtrl.Joystick (Val1, Val2)

    ====================

    Robert
  • johnfosjohnfos Posts: 59
    edited 2011-08-17 07:31
    treborz17 wrote: »
    I like the "Watchdog" Technologies idea, especially using some of the code that I am already using and, are familiar with, but I hate to omit it but I don't see where the -1 would be coming from if the scenario is that the transmitting XBee and controller fail while motors are in motion. As usual I'm missing one little thought on how this is to be coded.

    Ok, let's try for a "little thought"

    I'm making a few assumptions here, but as I see it there are many possible points of failure:
    1. Software error in the joystick controller causing loss of transmission.
    2. Battery failure in the controller (your original problem...)
    3. Hardware failure causing loss of transmission
    4. Loss of transmission due to interference or to the remote going out of range of the controller
    5. Software error in the remote
    6. etc etc

    A robust system is going to have to deal with all of these. As I see it, there needs to be a piece of hardware on the remote that will have an input pin that's normally at (say) logic high and that will force the remote into whatever you define as a safe state if that pin ever goes low. No, let's amend that. Better if the hardware expects to see a pulse train and will take action if the pulses stop, whichever state the line remains stuck in.

    To check the whole communication chain, the pin can be driven from the processor in the remote, which toggles the pin each time a particular command sequence is received from the joystick controller. The software in the joystick controller is then programmed to transmit the command sequence at regular intervals.

    This way, the pulses will stop and the remote will fail safe when any component in the chain fails.

    Well, that's my thought for the day anyway :-)
  • treborz17treborz17 Posts: 76
    edited 2011-08-17 12:21
    The following code worked fine so far, for at least the two dozen times I tested it:

    Receive:

    repeat
    XB.RxFlush

    DataIn := XB.RxTime (100) ' Wait for byte with timeout
    If DataIn == "!" ' Check if delimiter
    Val1 := XB.RxDecTime (3000) ' Wait for 1st decimal value with timeout
    Val2 := XB.RxDecTime (3000) ' Wait for next decimal value with timeout
    WCtrl.Joystick(Val1, Val2) ' -100% to +100% Speed, -100% to +100% Turn
    else
    Val1 := (0) ' Turn Motors off
    Val2 := (0) ' Turn Motors off
    WCtrl.Joystick(Val1, Val2) ' -100% to +100% Speed, -100% to +100% Turn

    Transmit:

    XB.Tx("!") ' Delimiter
    XB.Dec(CH1) ' First value
    XB.Tx(",") ' Comma seperator
    XB.Dec(CH0) ' Second value
    XB.CR

    Robert
  • sylvie369sylvie369 Posts: 1,622
    edited 2011-08-21 06:48
    One vote for testing this out on a robot that weighs quite a bit less than 35 pounds.
  • treborz17treborz17 Posts: 76
    edited 2011-08-22 11:03
    sylvie369 wrote: »
    One vote for testing this out on a robot that weighs quite a bit less than 35 pounds.

    Sylvie,

    Did your robot test work?
    Good?
    Bad?

    Robert
  • treborz17treborz17 Posts: 76
    edited 2011-08-22 11:28
    Martin Hebel wrote: »
    RxDecTime returns a -1 if no data received in time.

    You could increase the initial rx grab to ensure data should be received in that time, if no "!", but a value of -1, stop the bot.

    -Martin

    Martin, I'm not sure what you are referring too by "initial rx grab". Even though I believe I have the robot working properly I am interested in your suggestion which appears to be faster and more reliable. I'm not sure yet what happens when I happen to receive a delimiter of "," instead of "!". I am going to set up the program in Viewport and maybe duplicate the scenario.

    Robert
  • johnfosjohnfos Posts: 59
    edited 2011-08-23 03:42
    The software watchdog looks like a big improvement. I still think, though, that a piece of hardware monitoring a pulse train would be even better. Turning the motors off directly from an I/O pin runs the risk that a code error in some other cog could turn them straight back on again, or kill the cog that was doing the watching.
  • treborz17treborz17 Posts: 76
    edited 2011-08-26 18:54
    Posted by Martin Hebelviewpost-right.png
    RxDecTime returns a -1 if no data received in time.

    You could increase the initial rx grab to ensure data should be received in that time, if no "!", but a value of -1, stop the bot.
    treborz17 wrote: »
    Martin, I'm not sure what you are referring too by "initial rx grab". Even though I believe I have the robot working properly I am interested in your suggestion which appears to be faster and more reliable. I'm not sure yet what happens when I happen to receive a delimiter of "," instead of "!". I am going to set up the program in Viewport and maybe duplicate the scenario.
    Robert

    Martin, let me do some testing -- after review I believe I know what your refering too. I will work on that and give it a try.
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2011-08-28 10:37
    Sorry I had missed your last - The initial grab where you look for the "!".

    Here's the pro's and cons - the way this is done:
    If you do an RxFlush in your loop, there's a chance you could be flushing as data is arriving. This would wipe out the start delimiter, and your code would shut your bot down until the next time data arrives.

    With out the RxFlush, you may get out of synch, and if the first character you read is not "!" then it will cycle through the rest until if finally hits the "!" or no more data and it has to wait for the next incoming data.

    Using a short timeout on that (100mS), if data doesn't get received every 100mS, it will see no data and shutdown the bot until the next packet finally arrives. I don't know how quickly you are sending data, but that time may need to be extended.

    Another means to help ensure you receive good, synched data is instead of flushing, to loop while data is in the buffer, looking for the "!" to ensure things are synched:

    (may be rusty on my spin, but you can get my meaning)
    DataIn = XB.RxTime(100)
    If DataIn <> "!"
    ...Repeat
    .....DataIn := XB.Rx
    ...While (DataIn <> "!" AND DataIn <> -1)

    -Martin
Sign In or Register to comment.