Tim WilkinsonThe eventual robot is going to have *lots* of these joints. If I took a traditional servo approach, I'd need three wires per devices - power, ground and PWM. Assuming I bus the power and ground, that still leaves one wire per device for control; so with 30 devices that's 30 wires to thread and terminate on some eventual controller. I wanted something better.
My first plan was be to implement these joints as 1-wire devices. That way I could bus the control wire between all the devices and have just a single control wire at the controller. Unfortunately, while there are some nice Arduino libraries to implemented 1-wire slaves, my boards only run at 8MHz (the internal clock rate) which isn't fast enough to make them work, or at least work reliably.
Fortunately I had a fallback plan. I'm old enough to remember the Cambridge Ring - not some kind of upper class network of students spying for Russia - but an early networking protocol. Leaving aside the specific implementation details, it was essentially a ring of serial lines where each transmitter was connected to the next receiver (the last being connected back to the first). Messages are passed round the ring until they reach the destination.
So I build a ring network which works on a similar principles. Each Arduino TX is connected to the next Arduino RX, and then messages are encoded and sent around the network. To operate any given device a message is send along the network to the desired target where it is executed. The result is a large network of devices (~250) with just two wires and usable by anything with a serial line.
The RingNet is IOS level 3/4 - ordered, reliable delivered at least once, datagrams (Update 9/5/16 - originally the network was unreliable, but fix that today).
The networking code is here: https://github.com/aanon4/RingNet
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Nice, sounds like you really got into it, and actually created something much more interesting than just a stopgap solution. May your token never get lost!
I guess we rely on PWM so much because the main use cases for those servos are still radio-controlled hobby models, and because PWM signal can be generated and used with purely analog setups, without any need for microcontrollers (the analog servos just have a simple comparator inside).
Are you sure? yes | no
I remember looking at these servos a while ago, but I'd forgotten about their protocol - which seemed like a good idea (never understood why we still reply on PWM so much - it works I suppose).
I ultimate chose my network structure for a few reasons which this protocol doesn't help me with. Importantly, the component count should be zero. I'm still annoyed about the pull up resistor on reset, so I don't want to add the hardware to turn the atmega's serial into open-collectors. The atmega does have a clever multi-address mode built into the chip which I looked at using, but without the open collector changes it would be tricky to make that work well (I'd be flipping the serial line on and off to avoid multiple chips driving the TX at the same time). That'd be manageable if I wanted to stick with master/slave, but I've also decided I want a peer based network, and that makes it a lot more complicated (I'd end up with a token-ring system which is another kind of pain) without the extra open-collector bits.
The peer based network has become more important than when I started. I intend to delegate control of groups of these actuators to local "masters" (and let them do local motion planning) while keeping everything on the same network. Master/slave won't do it for me.
Finally - this is really simple to implement on anything - no extra hardware required.
I'll be adding to the RingNet library as I go along (I will make the datagrams reliable at some point to avoid every app having to do it) and there's already a console-like debug channel in there. As for telemetry - that up to the application living on top of. The code for these actuators is pretty simple at the moment, but it already gives some basic telemetry to whomever is controlling them. I'll add more as I need it.
Are you sure? yes | no
I wonder if it wouldn't make more sense to use an existing protocol, such as the bioloid servo protocol.
It's basically just a half-duplex serial protocol, with data frames containing addresses. This way you can have all your servos on a single shared wire, and they simply ignore frames that are not addressed to them. The nice thing is that the servos can also respond with telemetry data on the same serial line. And it's serial, so it's everywhere and easy to debug.
Details of the protocol: http://support.robotis.com/en/techsupport_eng.htm#product/dynamixel/ax_series/dxl_ax_actuator.htm
Are you sure? yes | no