Serial Control Protocol

I have not seen many commercial products other than the OOPic use it, but that doesn't mean it isn't a good protocol. It's described a bit more in the OOPic manual, which you can get online at the oopic.com site.

What many people aim for today is multi-drop interfaces for addressing more than one device on the same line, and an ASCII control set (with some mechanism to provide values down to 0, and over 127), so it can be used with standard terminal software. Other than that, I think most anything is fair game.

-- Gordon

Eddy Wright wrote:

Gordon, I agree that it looks like a good protocol. I was wondering if there was another serial protocol that is widely accepted that I may have missed in my searching. Doesn't look like there is though.

I think SCP will fit my needs so I plan to use it.

It looks like openscp.com is gone but I found that openscp.org wasn't taken. I am willing to build a site for SCP at openscp.org if anyone is interested collaborating on it. I'd like to promote the standard if I'm going to use it.

Eddy

Not sure how widely used it is beyond the product line it was developed for, but you might look at the protocol used in the RoboBricks project:

Wayne often posts here and he can provide the pros and cons. Certainly one benefit would be compatibility with these little modules. For a while RobotStore was selling them (before Jameco bought them), but I don't know what their current status is.

One thing to keep in mind about both of these specs: they've been proven in real-life products, and I think that's important. I think Scott has used SCP in products other than OOPic (I'm pretty sure Speakjet, for one), and Wayne has demonstrated the efficacy of the Robobricks communications platform.

Good luck with your project!

-- Gordon

Eddy Wright wrote:

Hi Eddy. You might want to send your query over to the oopic support forum. Very active.

Also, see here .... ref chapter 16.

- dan michaels

======================

I'd like to through in my $0.02 and bring to light the MojoBus protocol. It is discussed in D. Jay Newman's Linux Robotics book. It was created by Brian Dean of BDMicro, Inc. It is ASCII based with a multidrop interface for addressing more than one device on a single line. Here is a description of MojoBus from an email that I got from Brian Dean:

Regarding MojoBus. For quite a while I have experimented with variousbus protocols for use on robots. The goals of MojoBus are simplicityof sending and receiving messages and consistancy of format betweenvarying devices. A single packet format is supported which is: [>]>t[,f]:cmd;[cmd;cmd;...] Items inside [] are optional. A linefeed ends the message.Where: t = bus id of recipient (required) f = bus id of sender (optional) cmd = command to execute Command format: parameter | parameter=valueCommands can be read-only or read-write, depending on whether it makessense or not.I've defined a basic set of commands that all devices should support. These are:

RESET = ro, reset device VERSION = ro, display firmware revision ANNC = ro, display identity string, delayed by busid order WHO = ro, display identity string ID = rw, set controller bus ID BAUD = rw, set RS232/RS485 serial baud rate, units = bps The person who implements this can define whatever commands they want,of course, depending on what makes sense for they device they make.The idea is simply so that one can put an h-bridge on the bus, as well as other devices like sensors, etc, and be able to communicate with them all in a consistant way that is not too complicated yet not too constraining. For example, for MojoBridge which was the high level controller interface to the RX50, it supported the following additional commands: D = rw, set duty cycle -100 to 100, units = % ENCP = rw, set encoder sample period, units = ms TPOS = rw, set motor target position, units = encoder TVEL = rw, set motor target velocity, units = encoder APOS = ro, display actual motor position, units = encoder AVEL = ro, display actual motor velocity, units = encoder KP = rw, set PID P constant (float) KI = rw, set PID I constant (float) KD = rw, set PID D constant (float) PID = rw, set PID P, I, and D constants (float) REV = rw, set motor reverse 0 or 1 Thus, to set the duty cycle of this device to 50%, and its busid is7, one would send it the following message: >>7:d=50;In C, this could be done something like this: sprintf(buf, ">>%d:d=%d;\n", target, duty); puts(buf);Multiple commands to the same device can be strung together. I.e: >>7:d=50;rev=1;A linefeed ends the message to that device.The protocol is nice in that you can connect to a simple terminal emulator on a PC and type in commands directly and see results. This is great for testing and trying things out. Also, it is easilyparseable.A sender ID is supported also. If the sender sends its own sender ID,and if the command requires the recipient to produce any results,those results should themselves be in MojoBus protocol format. I.e.,like this: Sender: (request position from busid 7, sender is busid 3) >>7,3:APOS; Recipient (busid 7) should respond as follows: >>3,7:*APOS=359722The '*' indicates it is a result and not a command, just in case thesender might interpret that as a command instead in the case of amultimaster setup.I hope this gives you and idea of it. I hope to put up some morecomplete documentation on my web site soon.

One can 'multi-drop' up to 7 Oopics using SCP i.e. Node 1 to 7 where Node 0 will talk to all connected oopics. Having said that I have only done this with two Oopics to date.

Ian

The OOPic Yahoo group is probably the best one for this. So far I have not done this.

-- Gordon

Another good one! I remember you mentioned this here a little while ago.

Wonder if we can get Brian to post the code and description on his site. I went there and can't find it.

-- Gordon

Randall, thanks for the info! That's the stuff I'm looking for... I'll shoot Brian an email if he doesn't respond here.

So far we have:

Serial Control Protocol MojoBus

Any others?

Speaking of multi-drop, how many devices can you realistically put on an RS232 line? I can't imagine it being a large number... Guess it's time to do some experimenting.

I left one out:

Serial Control Protocol MojoBus Robobrick Protocol

Coming soon. I'm currently tied up polishing off my RX50 h-bridge and its associated companion board that runs the MojoBus protocol, so that's where my effort is going at the moment.

In D. Jay Newman's new book on Linux Robotics, he used a prototype RX50 which was named MojoBridge at that time which included not only the h-bridge but also a high level control interface which ran my MojoBus protocol. For the production board, though, I seperated out the h-bridge proper from the higher level control. The h-bridge is the RX50 (5 to 30V, up to 50 Amp, 100+ kHz PWM). The companion board which implements the high level interface including serial comms of various sorts, R/C servo pulse control, potentiometer feedback and control, quadrature feedback, and built-in PID algorithms is coming soon and will most likely carry the MojoBridge name.

Jay and I exchanged quite a bit of communication on this topic when he was writing his book. While the format of the protocol was pretty much done, Jay suggested several important refinements to the semantics based on his experience in developing Grouch. This includes refinements to the conditions when a device remains quiet or responds to queries which make more sense in bus oriented environment where this is targetted.

As you may or may not know, Jay used a pair of my "MojoBridge/RX50" h-bridges on the robot he developed in his book, as well as a MAVRIC-IIB as an "intermediate" controller. The h-bridge controller used MojoBus as I mentioned. I also provided the basis of the MAVRIC-IIB code which Jay then extended and refined for his specific application and added new functionality to make it do what he wanted. This code implements a MojoBus device and Jay used it to MojoBus-enable a variety of sensory input, including a dozen or so sonars connected to the MAVRIC-IIB. If I mis-speak here Jay, please correct me.

So currently as of this post, D. Jay Newman's book, "Linux Robotics, Programming Smarter Robots" is the best reference:

Talking to MojoBus devices is very easy - the code snippet I sent to Randall which he posted is really all there is to it.

Implementing a MojoBus device is not hard either, but does require a little parsing. Again, D. Jay Newman published the code used on his MAVRIC-IIB board on his web site that does this. We've made the source freely available in the spirit of sharing:

The core of the protocol implementation is here:

This includes an implementation of most of the "default" MojoBus commands as well as the state machine for parsing the command packet.

I do want to work in an optional checksum into the protocol. I have a few ideas on how to do that which I plan to explore shortly.

-Brian

Thanks for the information Brian, I'll check out those sites.

I like the idea of using a text based protocol to simplify parsing and improve human readability.

Eddy

Wayne Gramlich is coming out with RoboBricks2:

RoboBricks2 is based on

9-bit serial UART and CAN bus transceivers.

I have the version I used for Groucho's sensor controller (a MAVRIC-IIB) on my site:

This is strongly based on Brian's code.

-- D. Jay Newman

All:

Sorry, about the late resp> Not sure how widely used it is beyond the product line it was developed

The first set of modules, called RoboBricks 1 (or RoboBRiX) used

5Volt signalling at 2400 baud. It was a binary protocol where a master module would send a 1 or more bytes and get 0, 1 or more bytes in return. It worked well with the bit banged serial protocol that the Parallax Basic Stamp, OOPic, Javalin, etc. could do. The RoboStore used to carry them, but Jameco did not pick up the contract when they purchased RoboStore. (Actually, there is quite a bit more to the RoboBrick 1 saga, but not on this forum.)

The next set of modules, called RoboBricks 2, (as you can see, I'm not very inventive with my project names) is based on a multi-drop bus. It evolved out of an extensive discussion we had on the Home Brew Robotics Club mailing list last September. It uses the CAN bus physical layer which is a differential signalling bus that was developed by the automotive industry. We only use the CAN bus physical layer and and UART's. We do *not* require microcontrollers that support the full CAN bus stack; we just need "addressable" UART's.

The first set of RB2 modules is up and running at 625,000 baud. CAN bus is capable of 1M bps, so the next set of modules is going to have all of the microcontroller crystals and resonators changed to shoot for 1M bps. By the way, the next set of modules is sitting on my dining room table waiting for a soldering party this coming Tuesday.

The jury is still out on how well the RB2 modules will work. Hopefully, in the next few weeks we'll get a chance to get a robot or two working with them to see how they do.

With regards to protocol selection, there are plenty of them out there. Either choose one that already exists or roll your own.

-Wayne

Wayne, thanks for the info. How did the soldering party go?

I'm leaning towards a human readable text protocol. A couple of protocols use bit/byte encoding which is more efficient but requires decoding for debugging. For my purposes, sending a few more bytes of data won't make a difference.

Eddy