Let's Make Robots!

LMR Bot Communication Protocol*

My xmos project proposal included (rather, was refined to include) a communications library to make it easier for the robots to share map data. Then BOA mentioned a communication protocol to allow different peoples' robots to communicate as well. That is a pretty damn good idea, so here's a forum topic to discuss and finalize said protocol. While I really should be thinking about is SLAM, this thought is occupying my thoughts today instead...I figure if I start a post and my current thoughts maybe I can get back to other things.

Those interested in working on or using this protocol, please chime in, and feel free to trash talk my ideas. Keep in mind I'm neither an engineer nor a technical writer, so this'll be ugly ;)

I'm thinking that there doesn't really need to be a defined set of functions to act upon. Instead I'd like to see something where the talking micro spits out ($address_of_receiver, $command, $data) or something. A receiving micro looks at the packet(s), says "hey, I have a hook implemented for $command" and runs it with passed data. That way a whole command set does not have to be implemented in the library, and each user/programmer can implement whatever functions they want. Ya, it'd require extra communciation between bot builders as to who may or may not have implemented what and how, but that's not a bad thing.

That said, some commands do need to be explicitly defined. For example, "command 0" could be "Hi, my name is $name. Anybody there?". 1 could be "Hi, $sender_name, I'm $name". etc... so they're the same across all receivers.

We need to define how a command is defined and called. Maybe just a simple hex byte would be enough? 0xFF would give 256 possible commands. With however many required/predefined commands, we're looking at 200+ available for user definition. If 200+ isn't enough we could even go with a two-byte system, sending High and Low bytes and have over 65000 commands available.

An example conversation as described above could be:

  • BOA's bot sendPacket(0x00, "BOABot");
  • My bot sendPacket(0x01, "RudBot");
  • Voodoo's bot sendPacket(0x01, "VooBot");
  • // BOABot knows two bots are listening. RudBot knows of BOABot, VooBot knows of BOABot, but RudBot and VooBot don't know about each other. Yet
  • BOABot sendPacket(0x32, "wifi");  // BOA has defined 0x32 as "Anybody seen a wifi spot?", with a code key of "wifi"
  • RudBot sendPacket(0x02); //  library defined "Sorry, I don't have a function named 0x32 with a key of "wifi"
  • VooBot sendPacket(0x32, _0x32_callback);  // Voodoo does have 0x32 keyed with wifi, and sends the result of his own defined callback function for that command
  • or something like that 

Naturally BOA and Voodoo would have had to conspire ahead of time to agree upon the type/format of data sent back and forth when both parties implement a function. BOA and Voodoo wouldn't have to have the exact same implementation of the function, they'd just have to return data formatted the same way.

With a setup like this it would also be reasonably trivial to port this library to various platforms. In other words, in the long run we'd end up with libs for Xmos, Arduino, Picaxe, and anything else that someone cares to write up. After that any LMR-er could use the lib and know that they can easily chat with other LMR bots if/when they meet up in person. As such, citing previous example, BOA and Voodoo wouldn't even have to be running the same microcontroller to share data.

We'd also need to agree on a method of communicating this data, hardware wise. My only request is "as cheap as possible". It'd be nice to do all this over XBee or something, but those are quite out of my budget for the time being. While it would be rather slow, IR is likely the cheapest way to keep it wireless. Unless anybody involved is happy with requiring the bots to have a physical connection anyway. Having them meet up and connect an I2C connector could work too. While that would still require something like an IR beacon to line up, it sure would make for faster data transfer (after all, I'm looking at transferring full maps).

 

Anything obvious I missed? Any ideas, suggestions, threats, accusations? The asterisk in the title means we need to come up with a better name for it too. LMRBCP or even LBCP doesn't quite roll off the tongue.

Thanks for reading

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

68 - over and out

etc .

 What about authentication?

I hadn't really thought about authentication. Would it be necessary? I'm not sure we should be transmitting too sensitive of data ;)
I was just thinking that if a certain byte corresponded to a certain agreed-upon statement, it would be possible to program a bot to lie to other robots ...

hhmmm... I don't know whether to agree, or to maniacally laugh while rubbing my hands together ;)

Have to think on that one.