3

We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).

All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.

I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.

Eastern Monk
  • 6,395
  • 8
  • 46
  • 61
  • 2
    It's not an answer, but personally, esp at uni, I didn't like too much stuff done for me with the projects I was to work on. Learning about solving these comms issues maybe could be part of the learning experience - how do I solve multi-node broadcast comms? If you remove that aspect, maybe your students will not take as much from your course. I for one was oft given lecturers' code only to put it in the bin due to it being a bag of nails. This does not imply yours will be too ;-) – RichColours Oct 12 '11 at 16:45
  • are you thinking along the lines of ppp or slip perhaps? – old_timer Oct 12 '11 at 16:59
  • @RichColours I do agree with you that by solving those communication problems the students learn a lot. Once I make up my mind to design such protocol, it will be the students who will collaborate and build it themselves. Once developed it will speed up the project development of next batches and perhaps those batches will be able to take up more challenging problems because some problem have been taken care by their seniors. – Eastern Monk Oct 12 '11 at 19:57

5 Answers5

5

Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.

It is not ideal approach. I agree with you that it's good for students to learn good examples.

Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.

Mtr
  • 482
  • 5
  • 19
4

You can implement Modbus ASCII if you want to go with a standard protocol that's already open.

mjh2007
  • 776
  • 1
  • 8
  • 17
  • 1
    Or Modbus RTU, if you want to keep the code simple and reduce bandwidth. I wrote a low-footprint Modbus server in less than a work day. The specs are free at http://modbus.org – Sam Skuce Oct 13 '11 at 14:27
2

Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.

That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.

+--------------+    +--------------+         +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+    +--------------+         +--------+

This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.

Modbus is another serial protocol that is used a lot

I believe OPC will give you the highlevel operation that you want.

see www.opcfoundation.org www.abb.com

PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM

AndersK
  • 35,813
  • 6
  • 60
  • 86
2

Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.

Sam Skuce
  • 1,666
  • 14
  • 20
0

Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.

I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").

If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.

tomlogic
  • 11,489
  • 3
  • 33
  • 59