1 microcontroller per leg?

[CPL. Dotson]

Hello, I am fairly new at robotics. I have built small/simple robots with leaf switches to just rove, but am looking for something a bit more challenging. So, for my next project I am building a Hexapod that will have more than the normal two piece leg construction. In order to keep the micro-controller from bogging down, I was thinking I could run each leg off its own controller, and link them all to a mother board to facilitate faster movement. My reasoning behind this is that if I have 4-5 servo's per leg (3-4 piece legs) I could use something like an Arduino UNO per leg and link them via USB to a main/motherboard for instruction. I could program each UNO with its own set of commands for standard movements, and program the main board to synchronize the movements of all six legs. I was also thinking I could run a separate UNO for the sensors that would be used for automation.

Any idea if my theory will work? Thanks in advance.

CPL. Dotson

[Gertlex]

There's no reason it wouldn't work.  Edit: one thing that would be tricky is interfacing with 6 boards at once. I'm sure there are boards with 6 hardware UARTs, but I'm not aware of them. Software UARTs are an option, but they're less reliable; albeit, I have no experience using them.

I reckon you could do it fine with one 16MHz atmega chip for the whole thing.  Even if you're planning on doing autonomous with sensors, it's probably fine (unless you aim for really high speed stuff, I suspect).

My point of reference however, is others' hexapods with 3 servos per leg.  This one moves smooth, fast, 18 servos and an Atmega 644p or something (Arbotix board). 
www.youtube.com/watch?v=rAeQn5QnyXo

I'm not sure what the kinematics plan is for 5 servos in a leg.  The implementations of 4 DoF legs I've seen and done just have the foot section maintain a constant orientation, e.g. vertical.

That said, you could also do 3 legs per daughter MCU, with a more powerful parent processor.  Digital servos would certainly make this easier than using hobby servos, since you can daisy-chain the digital servos.

[CPL. Dotson]

@Gertlex

The kinematics plan for 4 servos per leg was hopefully to be able to jump (one of the reasons for the fifth servo in the "foot", however, I think I may be able to build a gas piston to act as a shock absorber which should work better). The four servos per leg will allow me to get enough lift to get off the ground, but I will need enough sensors ie. IR and maybe a gyro, to be able to sense when the ground is getting close. Which is another reason for multiple daughter MCU's, because the ground will be coming up quick, and the legs will have to "cushion" the fall. I know I will probably break a lot of parts before I get the programming down.

I also decided not to leave the foot "dangling" there, because if the bot is moving fast, it would start swinging.

You think I should use digital servos though? What would be the benefit of daisy chaining them, just less wiring? Do you think that it would be do-able to use the Arduino UNO's for the daughter MCU's and build a parent processor?

Thank you for your input.

[Soeren]

Hi,

In order to keep the micro-controller from bogging down, I was thinking I could run each leg off its own controller, and link them all to a mother board to facilitate faster movement.

I'm very much in favor of distributed processing(/"controlling") - Divide and conquer

However... the speed of movement alone is a poor excuse for doing so and I think that you suffer from the typical "underestimating speed of microcontroller syndrome" USOMS for short
6 legs, each 10-DoF (just to exaggerate) and a lowly 1MIPS controller gives a refresh rate of:
 1*10^6/(6*10)=60µs
Or 16.667 round trips each second, assuming one instruction per DoF, which is probably too little. With 10 instructions for each DoF, you can still service them all 1'667 times each second and that's just with a 1MIPS controller. How fast do you need to go?

One for each leg vs. one for all legs (still having a master controller, either reading the sensors directly or through a "sensor controller"...
One for each:
Programming gets easier, as they all need the same software, so program one and clone the rest.
Wiring might get more complicated and there will be more to trouble shoot when it acts up (although swapping out controllers will help determining if it's a bad controller, bad software/wiring/whatever.

By all means, do it, but do it for the right reasons
I wouldn't use Arduinos for the "leg controllers" however - a through hole controller, a cap and not much else, on a bit of Vero board, is all it takes.

[...] link them via USB to a main/motherboard for instruction.

SPI or IIC will be cheaper and easier.

I could program each UNO with its own set of commands for standard movements,

They all need to be the same, unless you make each leg different from the next.
Programming just a single "step" into each - the timing of the steps should be determined by the master.

Any idea if my theory will work?

Of course it will work (distributed processing has worked for decades )
Depending on your previous with controllers, it may be a huge project to take on. If the "leaf switch 'bots" you have built, didn't contain a controller, I'd advice taking a trial step up by doing something like the $50 robot from this site - just to get a feel for it...
But ultimately... You be the judge.

[Soeren]

Hi,

[...] I'm sure there are boards with 6 hardware UARTs, but I'm not aware of them. Software UARTs are an option, but they're less reliable; albeit, I have no experience using them.

Easy now... Bit banging a synchronous serial signal (clock/data) is dead easy and super reliable.
UART (Universal Asynchronous Receiver/Transmitter) is for saving copper on "long distance" communication and is slightly less reliable (due to the need for periodic resync and/or retransmission of packets).
IIC (Inter Integrated Circuit) and the likes (SPI, CANbus etc.) are meant for close COMMbat.

If there's enough spare pins, 8 bit (+handshake) parallel comms is very reliable too.