Hmm, begs the question at what stage can you be accused of being cruel to a robot? Could become as controversial as how to charge a battery<img src="wink.gif" width=15 height=15 align=middle>
anyway...
Thanks for the decsription and links, explains what you're doing nicely. Great project.
As for the comms, either fan/hub or daisy-chain will work. They are indeed similar to series/parallel. With fan, one central device 'talks' to all the slaves at the same time. Think pictorially of a spoked wheel. In a daisy-chain, the first device talks to the second which then 'passes' the message on to the third etc. etc. I don't think one is any better than the other but there are pros and cons with each.
With a hub, sending to the slaves is easy but for the slave to send back to the master can be tricky to avoid all 'talking' at once.
(might be simple in your case if they only need to say "job done"
.
In a daisy-chain, the code in each 'link' will be a little more complex but has the advantage that it also acts an amplifier/buffer for signals going over a long distance. A disadvantage is that if a link 'breaks', everything from that link onwards also goes down. You can also mix and match with several hubs daisy-chained together.
Hopefully somebody will give a better insight than mine.
Some of your choices may well be dictated by budget, skill and timeline. You have not indicated any of these.
How would I do it?
That would depend on who was paying and it's intended future.
If it was a project for a paying client with no budget contraints and reliability was important, I would use ready-made modules off the shelf using industry-standard protocols. That would also allow A.N Other person to 'service' it after I had gone without the need to learn what I had done.
The sort of modules I would use would be "CANBUS" and/or "MODBUS". These are units used in industry and automotive applications. They use a very reliable comms protocol (safe for fly-by-wire) and PC interface cards are available. (VERY expensive option)
If I was doing it for my own amusement on a low budget, I would buy a bunch of cheap 'hobby servos' and hack them for the motor drive units. Replace the feedback pot with whatever position sensing device you have on your robot parts and connect the motor drive outputs to your motors. It should be possible to locate the 'error' signal on the servo control board. Test the signal with a comparitor (or simple op-amp) and use it to drive a logic level "job-done" signal.
The modified servos could then be driven by a servo controller board. As already mentioned, Rev-Ed do a board that can control 21 servos. Would be worth searching to see what others are available.
Then, the only signal that needs to go to each of the robot parts is a servo pulse to tell it where to go and a logic level that comes back once it gets there. You then have the choice of hub or daisy-chain if you use several servo control boards.
Another option, but probably cost prohibative, would be to use PC rackmount motor controllers. These are complete motor controllers that plug into a 'standard' rack system such as VME and are sent 'commands' via a data bus. Only motor cables and feedback signals go between the moving parts and the 'rack'. This is how powerfull precision robots such as those used in car manufacturing are typically controlled. By having all the controllers on a high speed bus allows very complex spline movements to be made where all the motors work together in real time at high speed.
Pros and cons which ever way you turn!
The choice is yours.
Somewhere on this forum someone posted a link to the "wooden mirror" project. I can't find the thread but I'm sure google will get you to the project. I understand that was done using 'hobby servos' with no feedback to the main controller.