Saturday, February 10, 2007

Microsoft Robotics Studio Communications Protocol

Ah – the weekend, time to do a little coding for fun! One of my on-going projects it to build out the functionality of my latest robot NiVek I. Although the robot itself has a little computer it doesn’t have much of a user interface, that is provided via a PC. Therefore for the PC to configure and display the telemetry from the robot a communications channel needs to be established.

There is a cool little card that you can get at Parallax called the Embedded Blue transceiver, this little devices takes TTL (+5v) level signals from a microcontroller and allows for serial communications with another BlueTooth device (such as a computer). So I can hookup a couple lines on my Javelin Stamp chip to the Embedded Blue device, then establish a BlueTooth connection and it’s just like having a two way serial cable between my computer and the robot, very nice!

Now that we have our serial link we need a nice general purpose (and simple) protocol to exchange data. In a past life I worked on a lot of embedded systems that needed to talk to the outside world. This is very similar to what I wanted to do with my robot. Here’s what I came up with.

<STX> - Start of Transmission Character (0x03)

<LEN_MSB> - Most Significant Byte of the size of the data packet.

<LEN_LSB> - Least Significant Byte of the size of the data packet

<DEVICE_TYPE> - Single byte that identifies the device (Enum type in C#)

<DEVICE_ID> - Since there may be many of these devices, we have a simple numeric id

<DEVICE_ACTION> - An additional byte that describes the action (Also an Enum type in C#)

<PAYLOAD> - An additional set of bytes that represent any data to be passed.

<CHECK_SUM> - A single byte check sum to validation the message

<ETX> - End of Transmission character (0x04)

Once we’ve defined this protocol, two chunks of code need to be written on each device that will be “talking”. We need some simple methods to build up the packets. We also need a simple state machine that will look at the bytes coming in on the serial port and build up these packets.

On the PC side, a simple state machine was built that progresses through each of the bytes from the serial port, once the ETX is received, an event is fired to pass the message to host that decides how to handle the message. Creating the new packets to send is even easier, it’s just simply a static method that takes the DeviceType Enum, DeviceId, DeviceAction Enum and Payload and constructs a byte array. Once complete that byte array is then dropped into a queue to be sent out on the serial port.

For my Java robot, our options are fairly limited, the Javelin is a cool little chip however the Java Interpreter is not very complete, no Garbage Collection and no real multi-tasking.  So here I did kind-of a round-robin type of thing where I have a main program loop, then I established the different services such as checking the sensors, checking the in buffer, performing actions etc..  One of those tasks was to check the serial port in buffer for new characters, if new characters are available, they are parsed via a state machine, once a message is complete it's dropped into a queue.  Then when the main loop checks the queue it pulls out the message, and based upon the DeviceType, it just hands the message off to the Java class that handle that device in a nice clean Handle Method.  Sending out a message isn't all that clean but since the Serial UART built into the Javelin chip works in the background it may not be that bad.  Basically each device calls a method on the Communications interface within the program to just dump the bytes into the output buffer that follows the protocol defined above.

If anyone is interested in getting a copy of this code, just drop me an email.

-ec

No comments:

Post a Comment