uSSC at 57600 bps

The user’s guide for the micro serial servo controller says that, in Pololu mode, the controller can operate at baud rates from 2,000 to 40,000 bps, but also:

Do you have any hard numbers on the exact rate/tolerances necessary to guarantee 57600bps communication? Alternatively, can I be (relatively) certain that a CP2102-based USB to Serial adapter operating at 57600 bps, which seems to work just fine, will not fail at a critical moment?

Thanks,

-Adam

Hey, Adam,

I don’t have any hard numbers, but you can measure your particular units and see their rates, which probably won’t change very much without significant environmental changes. I don’t know exactly when the CP2102 samples its input line, but if it’s around the middle of the bit, you should be able to tolerate almost a 5% difference in the speeds.

- Jan

I just checked and it’s close enough to be concerning. My CP2102 adapter is outputting 57,600 bps about 0.5% fast, and the echoed output of the uSSC is identical, but about 4.4% slow.

I’m a little confused about why when the CP2102 does its bit sampling matters. All I’m concerned with is commanding the uSSC from the CP2102 at 57,600 bps, and the odds of the high baud rate causing a problem like the servo controller going into an error state. It hasn’t so far, but if it ever does it’s sure to be during an important demo. The manual is a little cryptic about the high baud rate being a problem (I’m assuming because of the limited resolution available when dividing the 20Mhz oscillator).

-Adam

The CP2102 sampling point would only matter if you’re monitoring the echoes from the servo controller.

Your numbers are definitely not confidence-inspiring. The oscillator on the servo controller is only 8 MHz, by the way. The reason I can’t give you a more specific answer is that the servo controller measures the first byte you send and tries to match that rate without any regard for standard baud rates. If the CP2102 had been slow instead of fast, the servo controller would still be at the same speed, and the overall error would be smaller. If the CP2102 were a bit faster, it could be different enough that the servo controller would pick the next faster speed, and the error might again be smaller. However, because of the limited resolution, we really don’t expect to hit any standard speeds past 38.4 kbps reliably, and I’m surprised that 57.6k is working at all.

If you have a few CP2102 chips, you might test them to see if they are all fast. If you get one that’s a bit slower, you’d at least know that you’re not at the absolute limit.

How soon do you need to have this working?

- Jan

We need something usable right now, but it doesn’t have to be 100% reliable. At the moment it’s just for a pan-tilt camera on a robot we built to gather experimental data, so it’s not a huge deal if it goes into an error state. At some point before we actually start demonstrating the robot publicly I’ll switch over to a slower baud rate, which will be a little less painful now that the TReX firmware supports 38400 BPS.

-Adam

We might have a newer servo controller by the time you’re ready for your demos, so that might be an option, too. It’s just six channels, but it sounds like you’re probably not using all eight on the other one. I’ve been thinking it’ll be out in the next week or two for a while now; it should really be available this month!

- Jan

Nice, it’s been a while. What’s special about this new one, or do I have to wait and see?

-Adam

It should be way better, in the same way the new jrk motor controllers with feedback are way better than the first-generation units. USB, better communication options, more settings, upgradeable firmware, and so on. I guess you’ll mostly have to wait and see beyond that, though we might still be able to get some specific feature in if you ask for it.

- Jan

The only features I’ve coveted from other servo controllers (specifically from the Lynxmotion SSC-32) are the timed/grouped movement commands.

You can set the servo speed, or you can set a time for a particular motion (i.e. move at whatever speed will get you there in a particular amount of time). What’s really cool is that you can command multiple servos to move in one string, all arriving at their new positions at a particular time. That would really simplify things like like robot arm trajectory planning.

-Adam

Hello Adam,

Is the timed command basically to save you the trouble of doing the speed = (old_position - new_position)/time calculation on your main controller? Our new servo controller will definitely have the ability to read back the current position, so you should be able to get all of the information you need, even if the arm is in the middle of some motion when you want to send the new command.

Is the intent of the grouped motion to start all the servos moving at exactly the same time? Will it cause problems in your application if two of the servos are 10 ms out of sync during a motion?

While we are on the topic, do you have any opinions on saved points / sequences / gaits / etc. for servo controllers?

-Paul

I realized there’s another potential problem while thinking about the other throughput thread: I’m not sure how well the servo controller can handle processing the commands. It’s possible that the serial input buffer could overflow if it’s getting filled faster, and I can’t easily figure out what the worst case processing time is.

- Jan

Hi Paul,

Reading back the current positions and doing speed calculations isn’t a big deal, I just thought it would give you more flexibility and options for how to structure a program with or without reading back the current positions. Sending separate commands to each servo is hardly any trouble though, who cares about 10 ms when the control pulse is only output every 20 ms?

Saved sequences would be incredible, and would elevate the servo controller into a whole different class of device in my mind (a programmable serial servo controller?). I’ve gotten a lot of use out of Lin Engineering stepper motor controllers with a similar sounding feature. You can directly serially command the controller, or you can use a few special commands to store strings of commands to be independantly executed on startup, or when you ground a particular pin. You can do simple pauses and loops, and even command other devices daisy chained to the master motor. Something similar with a servo controller would be really great. Obviously you couldn’t make a terribly smart robot with just one of these, but it would make them very attractive for things like cheap laboratory automation, animatronics, etc.

I’m imagining having space to store a few strings made up of the normal protocol commands, one that would execute on startup, and a few others tied to pins for external buttons or switches. A special command for timed pauses in between stored commands would be a must, and some basic looping would be good too. It would be nice to have a smart pause command that simply waits until the previous command (say, moving a motor at a slow speed) is finished. Again, you could get around this by figuring out how long it will take the signal to change at a particular speed and just inserting a pause of that length. It would also be neat to have the serial out pin echo the motion command bytes for debugging or so you could run other servo/motor controllers from one master controller.

Now I’m all excited.

-Adam

P.S. Jan, yet another reason to switch to a lower baud rate. I’ve been putting it off because I have one UART split to transmit to a uSSC and a TReX, and receive serial reports from other sensors. I can select the baud rate and report frequency of the sensors, but I would rather keep both high. This will all be a moot point soon though, as I just ordered my first ATXMega chips. Hello five UARTS!

Oops, I was hoping not to get you too excited with my questions! I like all of your suggestions very much, but I really am not quite ready to commit how much of all of that we are going to manage to cram into the microcontroller. But we will definitely make sure that we give you a flexible enough set of commands and options to make it easy to do this kind of thing in a couple of different ways. Maybe an easy way of polling for whether the controller is done moving would be a useful and easy way to get most of what you are asking for?

EDIT: As for saved sequences, loops, and so on, do you know of any example applications that you would have for such things right now?

-Paul

I can think of a some research lab projects, and student projects in engineering, art and architecture around the University that either use servos, or would if there were a cheap programmable servo controller. These would mainly be for basic repetitive tasks like turning knobs or throwing levers. Every year the college of engineering here has a design expo to showcase all of the student senior design projects, and a good number of them use servos for basic repetitive motions. Usually there is a laptop computer completely dedicated to generating these motions.

For example, we recently had some interest in building a simple servomechanism that would squeeze a rubber bulb a set number of times for medical device testing, so it would just have to shuttle back and forth between two positions with set delays a particular number of times in response to a button press.

I also helped some students in an art class last year where they were given a servo, an Arduino, and a Maxbotix sonar sensor and told to make responsive sculptures of some sort. They end results were pretty cool, but a lot of the students struggled with the Arduino programming for reading the analog output of the sonar and generating the servo pulses, which wasn’t the point of the class at all. If motions could be pre-programmed, then triggered by, say, a sharp digital distance sensor, the students would have had a lot more time to focus on the art pieces themselves, and might have gone for more complex motions. I would imagine this controller will cost less than an Arduino, so it could allow future versions of that class to take more students, or buy more servos per student at the same cost.

-Adam