reliable RF (Xbee) communication.
I have one last issue before my web controlled bot is finally to a point I'd call finished. the issue is reliable RF communication. So I'm looking for some pointers.
I'm currently using 9600 baud xbee to xbee. and from what I can tell the sending and receiving gets out of sync. even though I'm using ask-answer type of communication (don't know the technical term). the bot ask for the direction command from the receiver, and then waits for an answer. I think something gets garbled, junk gets sent and then junk gets received and then it just repeats.
I'm wondering if I need to speed up the communication, slow it down or perhaps I need to add pauses in between each command. I have to add that I can get the control to work just fine is that's all that's happening. I started adding LEDs to indicates modes, and timeout's and this is when I ran in to issues. I know I could add checksums but that just adds communication and CPU time. and I'm already concerned with Lag when web controlled.
when I use XT.RX (FDS) it hold up the processing until something is received, if the bot thinks it just sent a command and the receiver didn't get it, they both end up in wait loops. if I use XB.RXtime(30) it waits for the full 30ms before it continues. this either adds a big delay and really slows down communication or if I lessen the time, won't work for all the different commands.
any thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner
I'm currently using 9600 baud xbee to xbee. and from what I can tell the sending and receiving gets out of sync. even though I'm using ask-answer type of communication (don't know the technical term). the bot ask for the direction command from the receiver, and then waits for an answer. I think something gets garbled, junk gets sent and then junk gets received and then it just repeats.
I'm wondering if I need to speed up the communication, slow it down or perhaps I need to add pauses in between each command. I have to add that I can get the control to work just fine is that's all that's happening. I started adding LEDs to indicates modes, and timeout's and this is when I ran in to issues. I know I could add checksums but that just adds communication and CPU time. and I'm already concerned with Lag when web controlled.
when I use XT.RX (FDS) it hold up the processing until something is received, if the bot thinks it just sent a command and the receiver didn't get it, they both end up in wait loops. if I use XB.RXtime(30) it waits for the full 30ms before it continues. this either adds a big delay and really slows down communication or if I lessen the time, won't work for all the different commands.
any thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner
Comments
So send your telemetry data from the bot at regular intervals say 10 or 100 times per second. Depending on message length and baud rate.
Don't bother with the bot waiting for any confirmation of reception by the PC. Lets just assume a high proportion of the message packets arrive at the PC intact else we have a problem anyway. There is no point in resending old data if the PC fails to respond what matters is the state now.
Leave some time between the telemetry packets from the bot to PC for the PC to send commands.
The PC must wait for telemetry data before sending a command in the gaps between packets received.
Now, what if the commands from the PC are not received ? Well either A) the PC works this out from the incoming telemetry data and sends the commands again or
I think I prefer A). For example PC sends STOP command to bot. PC notices from telemetry data that the bot continues to move. PC sends STOP command again, and again if need be, and again....
In
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You can learn a lot by studying the protocols used by industrial PLCs. AutomationDirect's DirectNet protocol is but one example.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
a move command: F,B,L,R
CamX position: 0-255
CamY Position: 0-255
Pingdata: tells receiver to receive PING data
then sends 5 Pings value:A-H
the problem I'm running into with sending back an "OK" is that one the program waits for a response, if something happens and one isn't received, the bot just locked up. or if I use RXtime it adds a big delay. even if I used 10MS that adds almost a 100ms by time it waits 10ms for each piece of data.
I'll work on these and see what happens. I wand to send a lot more data but if I can get this to work adding data will only make it worse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner
The master/slave concept requires knowing which is master and which is slave. At a high level the PC "master" sends commands to the bot "slave" but at a communications level perhaps the bot is the master. For example sending requests for commands in Dgswaner's current set up or controlling packet timing in my simple suggestion.
I'm not convinced of the value of complicated protocols with time outs, ACKs/NACKs, retries, sequence numbers etc in cases like this. As I said there is no point in resending old bot data messages. It's state is changing all the time. Might as well send the current state continuously. I could argue that sending old commands from PC to bot when they get lost is not necessarily useful either. E.g. The PC commands a STOP, but the bot continues to move(Lost message maybe). Do we really want to command STOP again? perhaps by that time stopping is not the best course of action, perhaps its time for FULL SPEED REVERSE or perhaps the operator (human or otherwise) has changed his mind and wants to go LEFT instead.
However one end has to be "master" of the time slots in which data is sent to avoid packet collisions. Or is an xbee full duplex ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
and yes my PC (PINK + PROP + XBEE) is the master, but as far as the communication my bot does all the asking. at least for now.
.... no on mentioned baud? would changing the baud help?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner
Things might get tricky if you have more than one bot. Then the PC should be probably be the master of communications timing and indicate which bot can transmit next.
I know nothing of XBEE so cannot speak on the baud rates in might be happy with. At 9600 you have about 1000 bytes/characters per second which seems plenty enough for your application. But perhaps XBEE is more reliable at slower speeds.
By the way what is "PINK" ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The master's command set should also include a "query" command, which tells the slave to respond with the current states of all its settings. This would be the command to use when the master first communicates with the slave on startup or after it loses contact. From there, an occasional "ENQ/ACK" command/response is all that's needed during quiet times when no other commands are being sent.
The XBee is transparently full-duplex on the device side — probably half-duplex on the RF side.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yep, bot returns it's state after every command.
But Phil, why do we need a special "query" command on start up or interruption? Seems to me there is enough bandwidth here to reply the complete state after every command anyway. In effect the complete state returned is the "ACK" and the periodic commands are the "ENQ".
In fact I think it's almost a requirement to have the full state all the time, not just that which pertains to a command. This is a bot in the real world I guess, slipping on it's wheels and bumping into obstacles etc. The controller needs to know all this all the time.
I'm going to assume commands are sent 10 or 100 times per second CONTINUOUSLY. Perhaps if only a "NULL" command, when nothing new needs to happen. Keep sending a STOP command until the returned state indicates zero speed, or the same POSITION command until it is seen that the position is reached. Then send do nothing (NULL) commands. Maybe slightly more tricky with things like LEFT and RIGHT. Do you keep sending LEFT till the bot has actually turned through, say, 90 degrees or until it has replied with "I'm turning left now" included in its state data? You don't want multiple LEFT commands causing it to spin around forever!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm getting no where near 1000 Xmits per second. more like 2-3 a cycles. I know I'm losing a lot of time reading 5 ping sensors, so I think I'll work on getting that done in a separate cog. as well as sending data to the PINK.
I'm definitely going to need to offload some of the work to a separate cog, on both sides.
thanks for the input, I'm going to start simple and then build on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner
as far as xbee goes I have managed to get 1/2mile with no problems with the 60mw wire ant versions @ 19200, ymmv but not that much [noparse]:)[/noparse] if you have to sparkfun xbee breakout boards they have a stress test feature you can use that spams both side hard to check the radios
Jimmy
I would also consider setting up·timing where you are always·sending a message at regular intervals along with a "heartbeat" message if no data or commands need to be sent.· When something is sent, it should be sent at that regular interval.· This can free your code up to do other things without having to constantly monitor the channel.· Once the receiver synchronizes on that message interval, it only needs to check for messages when they are due to arrive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
for what I'm doing I though that the ask-answer method would be more than adequate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner