Xbee Communications with propeller.

medelman

Maybe I don't have a very good understanding of serial communication, but I want to try and use the zig bee chips from max stream for communication between my robot and the pc. I have all of the hardware interfaced properly as I can send a few AT commands from the Propeller to the PC through the xbee. My idea is to create an interface to control the robot remote via the pc. Eventually it will be autonomous. For the PC interface I'll using some programming language such as C#, I want to have buttons or use a joystick to control my tread based robot. Eventually a video feed from the wireless camera on board the robot will also be displayed on screen so that I can see where I'm actually moving. I found Martin Hebel's xBee object and understand how to call it within my program, but I'm trying to understand the methodology behind the communication process.

Let's say I press the button on the computer that says go forward.. Do I keep sending the command until the propeller sends back a command saying it got it? What happens if a command gets passed more then once, but I only want to go forward once? There is some sort of api command mode for the xbee protocol, but I don't really understand the format that I would need to send from the PC to the Propeller or even if it's necessary for my application.

Thanks

Matt

Mike Green

The xBee devices provide the radio transmitter/receiver and include their own processor to handle sending the information from one xBee to another. There are several levels to this "protocol" and its handling. The API stuff is sort of mid-level and provides for sending individual small packets of information from one specific xBee to another. Successive packets can go to different xBees. The xBee takes care of error checking and resending if necessary. The "default" mode for the xBee is to simulate a single serial channel. Once you set up the xBee with the AT commands, it will look and act like a wired bidirectional serial channel, connected through another specific xBee to something like a PC. If the PC sends some information, the robot will receive it (although it can ignore the information). If the PC sends something twice, the robot will receive two copies.

The xBee devices are pretty good at error checking and retrying the transmission and all of that is hidden from the outside world. You will still need some kind of "fail-safe" behavior between the robot and the PC. Periodically, the PC ought to send a command to the robot that's just an "are you still there?" and the robot should respond with something that the PC recognizes as "yep". Sometimes, systems like these number the messages going back and forth with the numbers wrapping around (like 0-15, then back to 0 again). If a message gets dropped, it's easy to detect and to reinitialize everything to a known state on both ends.

medelman

So ideally, would I have a cog that runs in the background and then takes the serial data and calls functions based on what is in the stream? I guess I am trying to visualize how the serial data comes in. Is there a buffer where the data is stored and then when an action is executed its removed from the data buffer?

Mike Green

If you use the "virtual" serial port scheme, you would probably use the FullDuplexSerial driver which already has a cog that runs in the background reading characters into a 16 character buffer and/or writing characters from another 16 character buffer to the serial port. You probably would have your main program reading from the serial buffer when it had nothing else to do, interpreting the character stream and calling other routines to do the actions requested. I would suggest you increase the buffer size to 32 or 64 bytes. There's a modified version of FullDuplexSerial that has a larger buffer. You might want to use the Extended FullDuplexSerial object from the Object Exchange. It makes some input processing easier (like converting a string of digits to a number).