Diego – the humanoid biped

I created this test application for demonstrating the capabilities of the new robot class model. The video gives a quick overview of the system (the volume might be a bit low):

You can download this application at the following links:

• source code only – 17kB zip
• visual studio 2005 project, dependencies and executable – 66MB zip

The second option is a VS2005 project with all the needed dependencies. It also contains the complied and linked executable robot_class.exe in the release folder. This zip file should be unpacked to C:\ for the Festival library to work properly (it creates its own sub-folders). It was tested under Windows Vista.

After a long time developing my robot’s software in C, I decided to make a transition to C++. I realized that a class system would allow me to keep a better structure of the code. This is why I developed a new object system, which looks like this in UML (click on it for a larger view):

generalized robot model

In the demo/test application, the robot class is controlled directly by the user interface class.  The robot class aggregates member objects for controlling different functionalities: the speech system, vision system, kinematics model. The vision class consists of two or more camera classes, which in turn contain classes for blob manipulation. The vision class is also responsible for triangulation to calculate distances of objects in the robot’s field of view. The kinematics class describes the kinematic model of the robot using arrays of joint structures and segments. It also contains a member function for calculating direct kinematics.

I am a strong believer in open-source software. To live up to this belief, I replaced Microsoft SpeechAPI with PocketSphinx speech recognition and Festival speech synthesis libraries. This brings me up to 4 different libraries for this project:

• GTK – the GIMP Toolkit for creating the graphical user interface,
• OpenCV – by WillowGarage for computer vision,
• PocketSphinx – by CMU for speech recognition,
• Festival – by the University of Edinburgh for speech synthesis.

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.