Diego – the humanoid biped

I gave Diego a color rehaul. It is now totally clad in matte black. It looks really sleek.

Let me know what you think about it.

Recently I got a couple of miniature on-chip digital cameras: Toshiba TCM8230MD. They can be bought for example on the SparkFun website. These are really small 0.3 megapixel VGA cameras intended for use in mobile phones. This is how the cameras look like installed on Diego:

As I said, they are REALLY small (6mm x 6mm). They are not yet operational. I have two of them installed in order to form a stereoscopic system. I will post more about them when I connect them to a processing unit.

After an epic night of mechanical work, I finally added Diego’s head and arms, thus making him a fully assembled humanoid biped:

Each arm has 2 degrees of freedom so far. I intend to add at least one more DOF in the shoulder and some kind of a gripper as the hand (note exactly sure yet which kind).  The shoulder DOF is a full sized Hitec servo (HS475), while the elbow joint is a micro servo (HS85).  The design of the head might be changed too in the future. It has pan & tilt capabilities (2 DOFs). This will enable the cameras (to be installed) to get an all around image. I already ordered two nano on-chip cameras (Toshiba TCM8230MD), which I will soon add to Diego.

The next step in development should be to cover the frame structure of the robot with some kind of lightweight material. Read more on this in my next post.

In recent days I have had some issues with  Diego’s power system. Ever since I installed four HS645 high-torque servos, the whole robot started shaking and jittering when I flipped the switch. It was obvious that there are problems with power. I searched online for solutions. I have found some very useful message threads on Lynxmotion’s Forums.

In the initial desing I wanted to control all power using 3.3V and 5V stabilizers, LM7805. The TI microcontroller needed 3.3V while the inverter (7404) worked on 5V. The servos give  higher torque on higher voltage. Their nominal upper limit is 6V. This means that I was losing precious torque running the the servos at 5V. Reading up on other’s experience, I realized that there is no need for stabilizers when powering the motors. They can be directly connected to the batteries, provided that they are of appropriate voltage. I use rechargeable Energizer 1.2V AA NiMH batteries at 2450mAh. When I connect 5 of them in series, they provide a nominal voltage of 6V, but when fully charged, they can go up as high as 7V. I connected this power source directly to the servos, without any stabilizers. It seems that the motors can handle well even 7 volts.  Now Diego stands still without shaking. Also the torque is noticably higher, and finally the robot can stand on one foot.

It is hard to plan Diego’s motion by the trial and error method, which includes trying to program different angles for each motor which would result in a desired robot motion, e.g. a step. When one set of angles does not work, it is changed until the motion seems satisfactory. That is how I got Diego to perform his first step.

In order to facilitate motion planning I decided to make a graphical user interface (GUI ergo DiegUI) which would allow to plan the robot’s motion in a visual manner. It has the following layout.

The right part of the window contains different views of the robot. For now, only the robot’s legs are shown, which are most important for planning a step. Each segment is represented by a black rectangle, while the joints are marked with red circles.

The robot’s segments and joints are described using kinematic chains. This is the standard way of describing robotic systems. The left side of the GUI contains the joint control sliders and edit boxes. This is the so called forward kinematics section of the application.

Here, by changing the slider position, the robot’s joints can be rotated one-by-one. This is called direct or forward kinematics, because the robot’s spatial configuration is uniquely defined by giving all the angular positions of the joints and knowing the lengths of the segments. If you are interested how DK is implemented, read up on homogeneous transformations before I write an appropriate article on the topic.

In the lower left part of the window there is the inverse kinematics (IK) button. IK is the process when the end point of a kinematic chain is placed at a desired location while the angular positions of the robot are calculated in order to reach this final goal position. The solution to IK is in most cases not unique. There are many configurations of the robot that result in a certain position of the end point of the last segment. This is why constraints have to be added. In the general case it is not possible to come up with an analytic solution for the IK problem, therefore numeric solutions need to be applied.

Finally, the top part of the window contains the timeline of the robot’s motion. In a similar way as in for example Flash, it is possible to define so called keyframes in the motion sequence. The positions between keyframes are ‘tweened’, i.e. interpolated.

As the next goal, this GUI needs to be able to connect to Diego wirelessly and download the current motion sequence to the robot. This would enormously improve the motion design process, which would allow me to create more sophisticated steps.

After a night of testing different angle sequences I finally convinced Diego take his first step. It was really amazing, that weeks of planning, building, soldering, programming, etc. seemed finally to pay off:

As it can be noticed, this is actually a half-step, because the robot starts from its standing position.It is also not the nicest motion, but for the first try, it’s ok. Hopefully its next steps will be much more sophisticated.

While experimenting with sequences, I figured out that this is a very lengthy process when using the trial/error approach. Therefore I decided to come up with a kinematics simulation, where I could easily change the angles and see how the robot would behave. You can read more about this in my next post.

After extensive mechanical, electrical and programming work, I finally got Diego to stand on his own feet with motors powered. This was a very proud moment for me.

One of the reasons why servo motors are very popular is the ease of control. The motors are so called positional servos, which means that their angular position can be set with high accuracy.

What does ’servo’ mean at all? It means that the motors have a feedback loop that allows them to correct their performance error compared to a desired performance. In the case of positional servos, it means that when the user sets a desired angular position for the motor, it measures the difference between the actual and desired position and drives the motor until the error is minimized. The feedback of the actual motor position is provided by a potentiometer. The desired position is set using the motor’s control signal. The control method is called PWM (pulse width modulation). This means that the angular position of the motor is determined by the width of the step pulse in the signal.

The impulse train needs to have a constant frequency of 50Hz, i.e. a period of 20ms. What changes is the width of each of the pulses. For the particular servos that I use (Hitec HS422, HS475), the width should be between 600us and 2400us (microseconds). This value span corresponds to moving the motor from its minimum of 0 degrees to its maximum of 180 degrees, as the image below shows.

It should be fairly easy to use most microcontrollers to generate such signals. Some of them already have built-in PWM generating capabilities. Most of the servos have three access wires. Besides the control line (yellow wire), that expects the above described signal, there are two others. You can probably guess: Vcc (red) and Ground (black).

As mentioned before, the electronics board is attached to Diego’s back. Since the servos themselves contain the driving electronics (whew), the circuit board is fairly simple.

The LM7805s are 5V voltage stabilizers. I needed to install a number of them, because each can handle only 1A of current, while each of the servos can draw a lot of current when in stall. I divided the servos between the available 5 regulators. I need to add heat sinks, because they tend to overheat during operation. The LM1084 is a 3.3V voltage regulator which feeds the microcontroller board. The 74HC04 are simple inverters added to decouple the controller from the servos and drive the controlling signals. Prior to this project, I already had a lot of experience with using Texas Instrument’s eZ430-RF2500 microcontroller boards for various purposes. This is why I decided to use this for controlling the robot.

These small wireless boards are powerful and easy to program. Still, they are limited in the number of accessible ports they have. Also the maximum clock rate could prove to be an issue in the future, if I add more servos (arms, head). The wireless capabilities are awesome. Two of these boards can connect to each other wirelessly and exchange information.  I plan to use this ability to control the robot remotely. The controlling program is fairly simple so far. It generates and sends PWM signals to the motors at appropriate times.

In order to drive the legs autonomously, the controlling electronics and batteries have to be attached to the robot. The torso of the robot can be used to hold these parts. I decided to build the torso out of regular aluminum L profiles, which are available in any home improvement store.

The dimensions of the torso were chosen so that it would have similar ratios as the human body. I wanted to build a robot that would be as much antropomorphic as possible. The front side of the torso holds the batteries. It will also hold additional servos for the arms and head. To power the biped I used 4 AA sized and 2 AAA sized batteries connected in series. Only 4 AAs did not provide enough voltage for the LM7805 stabilizers to work properly, that is why I added 2 AAAs more. The back of the torso holds the electronics board:

This way the electronics is pretty woulnerable. I will have to change the design to protect the servo motor connections (seen at the bottom) and the whole board from possible falls. The following article will discuss the electronics design for Diego.