Serial servos?

Help & Support Robot Parts
1

Do these exist? not, serial servo controllers, but actual serial controlled servos.
You know,
serout p3, 9600, 150
ect.
or serout p3,9600, (degrees -90/90)

I’d assume they’d be TTL.

I’m kind of winging it here, they sound like a good idea to me, and would be good for other robot builders i’d think. especially with advance commands like

serout p3, 9600, (servo #, movement\wait, movement\wait\speed, movement\wait, movement\0\speed, movement)
serout p3, 9600, “#5, -90\1s, 45\500ms\90, 0\2s, -25\0\50, 0”
It would servo 5 (0 = all) move to -90* and wait for 1 second, then move to position 45* for half a second at 90% speed, then to pos 0 for 2 seconds, then -25* for 0 seconds at half speed.

I know this can all be done with the Basic atom pro’s programming, using hservo commands and the pause command, but that is besides the point.
Especially if you daisy chain them, program each servo to be controlled individually, with advance commands, you can program an array of movements into the servos directly, so each servo knows exactly what it’s supposed to do, after being told once.
I don’t know how you would TX with daisy chain so it could send information back to the chip though.

Even better if they can be programmed to repeat the last command. IE if you send them a command to take a full step in a walking gait. You could send
serout p3, 9600, “0, repeat”
0 being all servos, it would simply repeat all movements.
Robots don’t get muscle memory, but if each servo has a simple micro controller, you could make smarter robots.
If each servo knows what it’s supposed to do, your main micro controller can be dedicated to other things.
Just an idea.

2

There are currently no standard servos available using a serial communications protocal.

Right now you’d have to go to Dynamixel servos(eg non-standard servos) for something like this or roll your own using the OpenServo code and PCB design(you can’t buy OpenServos ready to go) and gutting a standard servo. Neither of these allow you to send more than one command at a time to each servo as far as I know.

The main problem with a repeat style command is you are dealing with mechanical devices. Repeatability and sycronization would be a problem with that particular command over time. All the other commands(basically most of the same commands the SSC has) could be done in a serial servo. Doing the serial part isn’t so hard. Making the serial servo backwards compatible with RC servo pulses is a bit tricky. And you pretty much have to do that otherwise your market wouldn’t be big enough to be cost effective and competitively priced. Few people will pay $100-$200 for a serial servo, which is what you’d have to charge if you couldn’t also sell to the millions of RC users.

As for getting data back from the servos, thats pretty simple. It’s all a standard Master/Slave bus so the master(your main micro) tells a particular servo to respond with some data. Since each servo is autonomous you don’t have to keeping tell each servo what to do so there is plenty of free time on the bus for state queries and such.

The step above that is building IK routines into the servos. Then telling each servo their position in the IK chain. Then all you’d have to do is broadcast to that chain were you want it to move to and all the servos would calculate there correct movements for the time specified.

3

I have a pair of new, in the box Dynamixel AX-12 servos to sell if you are interested. Contact me off list.

Alan KM6VV

4

Pre-built V3 OpenServo boards are available for purchace; Sparkfun are selling pre-built boards too, but an older version. In both cases they would still require to be installed in a servo. In addition to that there is no support for an asynchronous serial interface built into the current firmware; however, the source code is there to add to.

One branch of the OpenServo firmware does appear to have facilities in this direction, but not quite as Fallentine has described. Again, the OpenServo firmware source code is there to add to.

Probably not has hard as it seems…

5

An approach for servo serial control (probably similar to the open servo) would be to make a very small serial servo controller for each servo. SMT soldering for small installations is not very easy.

6

According to the Sparkfun schematics on that page these are version 2.7 OpenServos. Not V3. Also I read a couple posts in the OpenServo forums that make me beleive this isn’t v3 compatible. So buyer beware and all on that.

By all means, I’m all ears on this. I have my ideas but I’d like to hear what other people come up with on automatically differentiating serial signals from the RC pulse signals.

7

It was just an idea.
I have a serial motor controller so i figured, why not a serial servo controller built into each servo.
I’d want it to do away with the standard RC pulses altogether with these servos.

I’m not looking to buy any other servos right now, besides a 360* full turn servo, and 2-3 more tower pro MG90’s. (plural, not to be mistaken with the MG90S)

8

Yes I did mention the Sparkfun one is an older version and you are correct that it is not 100% compatible with V3 - some features are missing. There may be a new OpenServo hardware version on the horizon too.

What came to mind when I read your first reply was that if one was using an asynchronous serial (USART) interface to communicate with the servo then you might want an RX (from host) and an TX for feedback: hence such a servo might have the standard RC fly lead and a second independent two way connector for serial comms. And so on. :slight_smile:

If you really want to auto detect, one possibility might be to connect (probably indirectly via a diode/resistor and so on) the input line to both a capture-and-compare pin and the USART RX pin of your microcontroller and then “run” both interfaces. If you received valid serial data (such as the string “INIT”) on your serial interface pin… or see valid servo timing pulses on the PWM pin… Feedback would need care and possibly some more thought if it were to be achieved over the same wire. And so on.

From a “manufacturers” viewpoint you probably do not need to do it that way; using a microcontroller they could add a jumper to select the interface method rather than separate leads or auto-detection. However, as you pointed out the market for such a servo is probably too small, especially with the proprietary approach Dynamixal and so forth seem to have adopted? It always struck me as odd that they did not opt for a standard serial type interface: but I guess it tends to lock customers in.

From a hobbyist doing it for themselves, I do not think one would bother jumping through the hoops for automatic interface detection.

I think Fallentine was only looking at a serial (serial as in like the SSC-32) based servo.

There are at least four possible approaches to that (depending on what one wants):

  1. OpenServo (TTL interface levels only without extra effort)
  2. Zoomkats piggyback idea (which is workable, TTL interface levels only probably because of space restrictions inside the servo)
  3. I note that the TowerPro MG996R uses an ATmega8, so reprogramming it is a potential possibility (TTL interface levels only without extra effort)
  4. DIY OpenServo style (although one might as well take on the existing board)