Reset and feedback problems with micro servo controller

Support Servo controllers and servos
1

We are using a Pololu micro servo controller for a rover project (interfaced with a BasicX24 microcontroller). The controller manages the steering servo and electronic speed control for a rock crawling robot.

After integrating this into the system I wanted to point out some important shortcomings of this controller:

  1. There is a red led indicating a communications error occurred, but there is no (documented) indicator pin which the microcontroller can use to tell there was something that went wrong. This means a human can tell there was a problem, but the microcontroller cannot. [There is a pin labeled OUT, but I don’t know what it does].

This is a big deal when reseting the servo board is much more desirable compared to locking up due to a bad communication. Handling a heartbeat message or something like that would be really great.

  1. The reset line is not documented. It’s labeled on the board, and seems to work, but there isn’t anything in the documentation about it. In particular, I would like to know how long to wait after a reset before attempting to communicate with the board (20 milliseconds seems long enough, but can I wait less, or should I wait more to be certain the board is ready to communicate again?)

  2. Resetting the board pulses the servos! Instead of leaving the servos in the off state (which makes perfect sense), resetting the controller causes the servos to twitch Since we are controlling the motor (via the electronic speed control), it would be much better if a reset left the servo lines quiet.

Some documentation and a firmware update could make this into a much more generally useful board:

  1. The reset line should be documented.

  2. Useful output should be generated via the serial port (and documented). For example, in response to any message regarding any given servo, the system could respond with the current config byte and pulse width of that servo (three bytes).

  3. An updated command 0 (command 7?) should be given that has a second data byte as a mask for which parameters you wish to update. Without this, you need to maintain the state of the servos on the microcontroller as well in order to provide a clean interface (SetDirection(), SetRange(), etc.) This also makes for a NOP command (mask is 0) to get the current config and position of the servo.

  4. A reset should not twitch the servos, but instead leaves them in the off state.

Does anyone have a work-around or know more details for these?

Thanks,

Warren

2

Sounds like a cool robot, I’d love to see a picture. In the meantime though I can give you a few more details.

During normal operation, the “Out” pin echos all the serial bytes received and processed by the servo controller. It’s not just another connection to the input serial line, it’s connected to a separate pin on the PIC that returns each byte after receiving and checking it. If a communication error occurs (or the PIC hangs for some other reason) the out pin stops echoing back bytes. So to monitor the state of the servo controller you can either read these bytes back, or even just check that the out line drops low briefly after each bit.

The reset pin on the controller board is tied directly to the reset pin on the PIC 16F628A, which is pulled high on the board, it looks like by one of those 10K resistors. I took a quick flip through the PIC’s data sheet, but I don’t see a straight answer anywhere. It should be very, very short, like a couple of microseconds, but try and see.

I totally agree with you about servo twitching, but I have never seen a (digital) servo controller that didn’t do this, not that I’ve done exhaustive trials of all the brands/models. The problem seems to be worse with cheaper servos too. I once had a Hobbico brand servo slam itself all the way to it’s mechanical limit from a startup twitch, and ever since it’s been all crunchy-sounding when it moves. It’s not a problem I’ve had with analog radio receivers though, so my guess is that servos are very sensitive to the startup transients on microcontroller pins. I can’t imagine every manufacturer of digital servo controllers thinking “Hmm, we should TOTALLY send random pulses out to all the servos whenever the controller starts up, yeah!” Generally, in projects where this is potentially going to be a problem, I add a switch for servo power and try to remember to turn the controller on first. That wouldn’t help you with remote reset twitching though.

It’s a good thing to be able to do, but you really shouldn’t need to reset the servo controller all that frequently. The only time I’ve ever had a Pololu servo controller misread a byte and get confused was when it was out at the end of a 15 foot unshielded cable, over which I was sending servo power and 5V serial logic (brilliant!). If you’re getting frequent communication errors in response to good bytes you might consider trying to shield your microcontroller, servo controller, and the lines connecting them from your drive motor (and of course, capacitors are your friends!). I’m assuming they’re all sharing the same power though, so there’s only so much shielding will do.

Good luck!

-Adam

P.S. I’m not familiar with the BasicX line, and all their pictures seem to be CG and slanted, or have a big bent-over capacitor in the way, but it looks like they’re based on AVR microcontrollers, or at least some kind of chip from ATmel. Basic on AVRs, super cool! What kind of chip does yours have?

3

Hello,

Thank you for your feedback. I’m numbering my response based on your second numbered list.

  1. The minimum low time for the reset line is 2 us (as nexisnet noted, this is the straight PIC16F628A reset line). The minimum time from reset to ready-for-data is 50 us. Typically, the reset line isn’t necessary, and if you do use it, I’d recommend waiting quite a bit longer than the minimums since there isn’t much to be gained from making the times as short as possible. If you have a 1 ms delay easily available, I’d just use that for both times.

  2. The serial output echoes your commands and stops doing so if it gets into an error state. There are a few reasons we don’t send back serial information. The main one is that the servo controller is intended as a one-way device that doesn’t really have any interesting information to send back. We want the servo controller to be able to process commands as quickly as possible, and sending back uninteresting data would slow things down without much benefit. Many small microcontrollers cannot handle full-duplex serial communication, so supporting those units would mean halving the command rate. For higher-performance installations, various buffers on both sides would complicate correlating a command and its response, still without much benefit.

  3. The parameter settings in command 0 are intended as one-time configurations, and the servo controller doesn’t change them, so it doesn’t make much sense to use the servo controller as an external memory for those few bytes. For clean higher-level implementations, we recommend using the absolute position commands and doing all range, neutral, and direction mapping in your main processor. Can you give me an example of when you would use the command you’re proposing?

  4. I think the reset behavior is an unavoidable result of the servo protocol. If the controller is in the middle of generating a pulse when it gets reset, the servo is going to get a shorter pulse and try to move to that corresponding position. Do you get twitches during reset on servos that were off?

- Jan

4

I tried it again just now, and connected (and powered) servos twitch more often than not when the controller is brought out of reset. This happens when I connect power to the controller, and when I bring the reset line high after manually holding it low for a while. I’ve found that servos generally don’t twitch when you pull the reset line low or cut power to the controller.

The exact same thing happens with the MiniSSC-II controllers. When I was working on servo snake robots we always had a line of switches to flip in order, and power to the MiniSSC-II’s came before power to the servos specifically so the snake wouldn’t twitch. I kind of got used to it as a fact of digital servo control.

-Adam

5

Hmm, that’s surprising. Time to go look at the details on an oscilloscope!

- Jan

6

My thoughts exactly.

When there are no servos hooked up, the signal lines look very clean coming out of reset.

I plugged in an HS-422 with 5V servo power, spliced into it’s signal line, and saw something odd. While the controller is in reset the signal line is getting pulled up to around 0.85V. This drops back down to zero when I let the controller wake up, sometimes with a bounce or two in the proper servo pulse range:

The vertical divisions are one volt each, and the horizontal divisions are 500us (the vertical cursors spaced 2ms apart). The bounces only show up sometimes though, while the servo twitches almost every time. The twitches can go towards either direction, but one direction is much more common than the other. I wonder if the servo is reacting to the long low pulse by twitching towards one extreme, and the occasional short bounce pulses by twitching towards the other.

-Adam

7

Thanks for the screenshot. I just tried it here, and I couldn’t get any noise on the output, with or without a Futaba S148 servo attached. If it is servo dependent, there’s not much we can do about it. Could you try your experiment again, but with a pull-down resistor of around 4.7k on the pulse line? When the reset is asserted, the PIC I/O lines go to high Z, and perhaps the servo input is floating to something bad but could be persuaded to stay low with that pull-down.

- Jan

8

I haven’t really used Futaba servos much, so they might deal with the high-floating signal better. I know I’ve seen this effect on analog Hitec and FMA servos, and a smattering of cheap re-badged brands.

The pull-down resistor seems to do the trick quite nicely. With it in place my Hitec servos still pull the signal line up, but only to about 120mV, and they don’t twitch a bit. They also still accept position commands just fine. I happened to come across that super-twitchey Hobbico servo I mentioned earlier (that twitched itself into a stop and lost some gear teeth) and the pull-down resistor keeps it from twitching too.

Since your servos don’t do it I made a little video to give you an idea of the behavior of different brands of servo. I didn’t realize this before, but I think the Hobbico servo interprets the high-floating signal line as a series of extremely long pulses. As you can see in the video, while I hold the reset line low it drives itself hard to one side and gets jammed!

This might be something to take into account in whatever special software/hardware you whip up for that guy who wants to make the 300 servo architectural installation. I’ve had some twitchey troubles with powered servos on long, but unplugged, signal extension cables. You would think that if they were so sensitive they would have internal pull-down resistors already. Hey, maybe Futaba servos do!

-Adam

9

Nice video; thanks! Looks like we have yet another feature to add to the next-generation servo controllers.

- Jan

10

Thanks for the great feedback. Aren’t there fuses on the PIC’s to configure how the pins are configured on a reboot? Seems like output low would fix the problem for the reset (are off servos left in high-Z or output low?) I’ll add the pull-down resistors. The OUT pin info should be enough to know when to ask for a reset.

I noticed the twitch on some hitech servos (sorry don’t have the # right now), but we’re steering with futabas (and I can’t tell you if they twitch because we didn’t have a reliable way to determine if we should reset)

So far as the output, I don’t see it as a problem. For micros that can’t handle full-duplex, they can just ignore the output. (maybe a header of F0 would be nice so that there would be an easy pin check to see that the command was received).

So far as feedback, we need to sweep an antenna to determine the location of a beacon. Setting the position in a loop from the uC results in a jittery motion of the antenna. The pololu however has a speed, so we can ask for a smooth sweep of the antenna. However, at any given time I can’t tell where the antenna actually is during the sweep, nor can I tell when it finished.

preliminary photos are at

home.mesastate.edu/~wmacevoy/spa … /index.htm

and the uC code is at

home.mesastate.edu/~wmacevoy/spa … basicx.zip

in particular, the module for the pololu is

home.mesastate.edu/~wmacevoy/spa … Pololu.bas

The place where the mask would be nice (but admittedly not necessary) is with the

ServoOff(ID)

I would like to be able to turn off a servo without having to reset all the other config bits.

Since you asked, the uC is a BasicX24, which is based on the AVR with a great development
environment and API (ridiculously better than parallax, even for a beginner), although it needs a RAM update (only 400 bytes / 64K flash )

The BX24 stamp supports two com ports. One is a dedicated UART which we use to upload new firmware and monitor for debugging. The other is a (AFAIK) software port configurable to any output pin and supports a maximum communication rate of 19200 baud. We use the software port to talk to the pololu board (the distances are very short, less than 3 inches for TTL communication)

I think we are working the stamp pretty hard and so this might be why we are getting errors on the software port, but I don’t really know. No matter who is to blame, I need to be able to reset when we do get a communication error.