# control circuit of a humanoid robot (something like iCub or Asimo)

My friend and I are building the upper body of a humanoid robot for our M.Sc thesis project. There are 24 DC motors in this robot. The thing I want to know is what is the best way to command these motors simultaneously?

The design I had in mind is for each motor to have its own micro for position and velocity control and then one master micro to command and control the slave micros. If this is the best way to go how does the master micro command slave ones simultaneously?

Another question I have is what is the best micro for the robot to go with between ARM and PIC? I want the master micro to receive its command from a PC. Any help would be appreciated.

what is the best way to command these motors simultaneously?

Like all engineering questions, the answer is it depends.

First, for some general things to keep in mind read this answer even though it's about ROS, but some of the same principles apply.

In short, one particular factor deciding between one-micro-handles-all and dividing motors among slave micros is how powerful each micro is. If one micro could handle all, it's kind of overkill to use many micros. On the other hand, distributing the control means you could use cheaper micros and probably be more energy efficient. You may also save on wiring, depending on where the motors are located. Note that the slave micros don't necessarily have to control one motor, but they could control a couple of related motors.

If you go with master-slave architecture, first you need to understand what motors are meaningless without the other. I.e. what motors need to be perfectly coordinated. The motors driving the fingers come to mind.

That said, it would make sense to have one micro driving the finger motors, and one micro for each other joint. That means a failure in one micro disables a joint or the whole hand. In the former case, redundancy in the arm compensates for the lost degree of freedom and in the later case, well if you have two fingers and one of them is not working or both are not working, then there's really no difference. If you have more fingers, then of course you need to assess the possibilities and decide between more micros or better coordination.

The master micro is of course connected to the slaves through bus(es); SPI, I2C or otherwise. The master would have to query the slaves periodically for information (such as the current state of the motors), do the control calculations and send instructions to the slaves to drive the motors. What needs to be transferred and the frequency really really depends on the type of the motor, the maximum speed of your robot, the internal safety features of the robot and various other things.

That is probably what you would want with a lower level control. On the PC, what you would probably want is a more higher level control. So you tell the robot arm to go to some (Position, Orientation) and the master micro would take care of the details of how much and how fast each motor exactly has to move at every period.

If this is the best way to go how does the master micro command slave ones simultaneously

Of course, you cannot achieve perfect simultaneous-ness. However, with a fast-enough bus, the master micro may be able to tell all the slaves what to do with a delay that is acceptable. If you have multiple buses, by driving the buses inside interrupt service routines, you could send commands on different buses in parallel which further reduces the delay.

However, don't fret it so much. You would likely have to make your robot slow because you cannot guarantee you can stop in time in a dangerous situation. There are actually two main reasons for this.

1. You most likely don't have enough information from the robot to decide safe vs unsafe situation. If you cover your robot with robot skin and be able to process all the data on the slave or master micros, you may be able to gather enough information, but chances are that you probably don't do this.
2. Your PC connection and processes are probably not real-time and depend on other non-real-time sensors and processes (such as cameras and image processing). That means that you don't have any guarantee that you can in fact respond in a timely manner.

Since you have to make your robot slow (to minimize the damage in case of collision, both to the robot and to nearby humans), then your control loop likely has a much larger period than your bus communications have. Therefore, in comparison, the delay between controlling different motors (through different slaves) is likely to be negligible.

Another question I have is what is the best micro for the robot to go with between arm and pic?

I have to say that this is a bad question. Each of ARM and PIC have a wide variety of microcontrollers with a varying features and powers. That question is like asking "should I buy a Mazda or a Honda?" You really need to look for what features you want and how much you want to pay for it. You need to take into account what compilers you would have access to and what libraries are available. You need to look for what speed the micro can have, whether it has an FPU, whether it has interrupts on events you are interested in, whether it has enough pins to drive all you need to drive, whether it can support as many buses as you would like etc.

So the answer is to look at as many datasheets as you can and see for yourself what matches your ideals best.

• مرسی از جواب کاملتون – Ehsan Nov 20 '14 at 21:44
• @ehsan, No problem, but this is an English site, so I don't think others would appreciate Persian. – Shahbaz Nov 21 '14 at 10:28