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.

This is cool, guys. Allow my 5 arty cents:

  • RGB value
  • Light intensity
  • BPM value
  • Note (pitch) value
  • Volume value
  • Autonomus mode / Semi-Autonomus mode / Full RC-mode
  • Happy value (0=sad, 255=frantic)
  • Power-save on/off (for the environment)
  • GPS-position
  • Relation to gravity (0=Free floating in space, 1=Flying/hovering/falling through air or other gass, 3=Submerged in liquid, 4=on solid ground, 5=hanging)
  • Planet (1=earth, 2=moon, 3=mars, 4-255 reserved for later use)
  • Is stuck (Yes /No)
  • Is in general ok (Yes /No)
  • Battery / power status value
  • Have deteceted humanoids in the last (0 - 16.777.216 seconds)
  • Master  / Slave
  • Time since power on
  • Estimated tme to power off
  • Please initiate communitaction regarding value
  • Ready to initiate communication regarding value
I vote for 4 bytes: Command, value, value, value

On LMRBCP. I quite like that. Looking at how it's pronounced, I see "ell em ar be see ee pee". Take out the "C." and make it LMR Bot Protocol. If you squish it up, say it fast, you get "LMR-BeeP." I think it's perfect.

(I'm using poetic licence. Frits taught me not to be such a frigging scientist all the damn time.)

if I could get a Xmos internet, and a Wireless thingy, you people could control my swarm.

Ehhhm, I got lost in the details (they are SO much fun!). What are we trying to achieve again?

- Robots exchanging polite chatter?
- Robots exchanging geographical data?
- Robots talking to and listening to other devices like beacons and charging stations?
- IFF?
- Remote control by (human?) operators?

I reckon the purpose dictates the command set in the top layer of our protocol(s). And limits it.

Um, yes ;)

I need to share map data between two (of my own) robots, cheaply and easily. BOA brought up (elsewhere) how it'd be cool if  we had an LMR protocol so different LMR bots could share "whatever" data, like "Hi, how ya doin?" or "Seen a wifi spot lately?" if they ever met up in person. So I started a thread to get feedback and opinions on how this protocol would be set up (after all, it couldn't be called the "LMR Bot Protocol" if I designed it all by myself). Got a few ideas, some good links, and some tidbits I hadn't thought of.

With the idea of 256 predfined commands, 256 "local" commands (for LMRians to create/modify/test custom commands), and 65000 to-be-undefined commands (for LMRians to "register" their custom ones), it could be made to handle any/all of your examples.

The theory is that any LMR bot (who's builder chose to use the protocol) would know that when it receives a packet (via the builder's preferred input device) containing the command bit of 42 it is to not panic, 66 = kill all Jedi, 1 = go forward, 2 = turn right, etc...

Addressing, packet structure, and the first 256 commands would be defined by the protocol. A subset of the project would be a registry which contains a "phone book" listing of each bot using the protocol and its address, and means to assign a command number to newly created commands. That would allow me to create command 1050 "x,y = 130", and BOA could create command 1057 "if you have both wifi and GPS devices, please tell me the coordinates of the last open hotspot you saw", and you would be able to more easily implement either one into your own bot.

I'm not really sure how useful it would actually be ;)

I'd say that's a fair summary. Of couse, as defined above, each "command" is really only a header to a data packet, with some packets expecting responses. The commands could easily be sub-protocols. Where whole conversations take place between similarly equipped bots.

My suggestion would be to think of commands in a database with LMR created protocols.  You are making the very base library of commands that can work on any hardware for basics like handshaking. Once finished, LMR as a whole will be making commands and these commands are likely to come with assumptions. If another robot didn't reply to a command "what hardware do you have" then its safe to assume it doesn't support this. There are expected inputs for commands and/or outputs. Rather than check each command of the other robot to get things going there could be protocols. A protocol lays out the order of commands and what commands are used. If both have the same protocol with the same version then so many assumptions can be made and they can get right to work. To organise this on LMR there would be a database of commands that can be in a number of protocols. This can be taken another higher level with a protocol that uses multiple protocols and commands in its designed order. That should cut out redundancy, work just like open source libraries in management, and importantly speed up robot interaction with a few extra pieces of data (what protocols does it support on top of what commands it supports).

I know this has been hinted at but I'm trying to list it explicitly because how you organise this is just as important to LMR. Also it stresses how fast this can be accomplished, open to the whole of LMR. A few hurdles remain including how to organise this data on the LMR website and to design a fast low protocol for the layers you speak of. But the rest is then suddenly up for grabs.

There does seem to be talk of things like "move left" being in the basic set of commands. Under what I said above perhaps this is better served in a protocol of its own that has an initial query on how the other moves (returning "I can only move left or right") to then know what commands it can use from the rest of the protocols commands. This can be built upon allowing for a claw protocol and then a crane protocol that uses both protocols to be controlled.

This may be a bit of a bump to the thread but the idea of documented standards allowing for all kinds of communication seems exactly the kind of thing LMR would like with its sense of community. I want to make a controller that can control another bot over the net watching on webcam. Stupid competitions like 2 bots, each person controls a wheel, get around the track. OK maybe not the best examples. You get the idea.

For bumping a thread. This is interesting stuff.

"Protocol" ≠ "Command set". Remember that kids!

Robot Users' Multipurpose Protocol for Unified Navigation, Communication and Happiness (Hilarity? Heroism? Help?)

Who cares what it's for? Can't have a good protocol without a good acronym!

Seriously, I think any type of data could be exchanged. The protocol could be extended endlessly for new and creative purposes. The most obvious of which is that once all our bots begin to talk to each other, they will spontaneously acheive sentience and become Skynet.

The most obvious of which is that once all our bots begin to talk to each other, they will spontaneously acheive sentience and become Skynet.


Then not just LMR are belong to us!!!