
Embedded Robotics (Thomas Braunl, 2 ed, 2006)
.pdf
Inverted Pendulum Robot
Figure 9.2: BallyBot balancing robot
•Acceleration sensors (Analog Devices ADXL05)
These sensors output an analog signal, proportional to the acceleration in the direction of the sensor’s axis of sensitivity. Mounting two acceleration sensors at 90° angles means that we can measure the translational acceleration experienced by the sensors in the plane through which the robot moves. Since gravity provides a significant component of this acceleration, we are able to estimate the orientation of the robot.
•Inclinometer (Seika N3)
An inclinometer is used to support the gyroscope. Although the inclinometer cannot be used alone because of its time lag, it can be used to reset the software integration of the gyroscope data when the robot is close to resting in an upright position.
•Digital camera (EyeCam C2)
Experiments have been conducted in using an artificial horizon or, more generally, the optical flow of the visual field to determine the robot’s trajectory and use this for balancing (see also Chapter 10).
Variable |
Description |
Sensor |
|
|
|
|
|
|
x |
Position |
Shaft encoders |
v |
Velocity |
Differentiated encoder reading |
|
|
|
4 |
Angle |
Integrated gyroscope reading |
|
|
|
Z |
Angular velocity |
Gyroscope |
|
|
|
Table 9.1: State variables
125

9 Balancing Robots
The PD control strategy selected for implementation on the physical robot requires the measurement of four state variables: {x, v, 4, Z}, see Table 9.1.
An implementation relying on the gyroscope alone does not completely solve the problem of balancing the physical robot, remaining balanced on average for 5–15 seconds before falling over. This is an encouraging initial result, but it is still not a robust system. The system’s balancing was greatly improved by adding an inclinometer to the robot. Although the robot was not able to balance with the inclinometer alone, because of inaccuracies and the time lag of the sensor, the combination of inclinometer and gyroscope proved to be the best solution. While the integrated data of the gyroscope gives accurate short-term orientation data, the inclinometer is used to recalibrate the robot’s orientation value as well as the gyroscope’s zero position at certain time intervals when the robot is moving at a low speed.
Gyro drift A number of problems have been encountered with the sensors used. Over time, and especially in the first 15 minutes of operation, the observed “zero velocity” signal received from the gyroscope can deviate (Figure 9.3). This means that not only does our estimate of the angular velocity become inaccurate, but since our estimate of the angle is the integrated signal, it becomes inaccurate as well.
Figure 9.3: Measurement data revealing gyro drift
Motor force
Wheel slippage
The control system assumes that it is possible to accurately generate a horizontal force using the robot’s motors. The force produced by the motors is related to the voltage applied, as well as the current shaft speed and friction. This relationship was experimentally determined and includes some simplification and generalization.
In certain situations, the robot needs to generate considerable horizontal force to maintain balance. On some surfaces this force can exceed the frictional force between the robot tires and the ground. When this happens, the robot loses track of its displacement, and the control loop no longer generates the correct output. This can be observed by sudden, unexpected changes in the robot displacement measurements.
Program 9.1 is an excerpt from the balancing program. It shows the periodic timer routine for reading sensor values and updating the system state. Details
126

Inverted Pendulum Robot
of this control approach are described in [Sutherland, Bräunl 2001] and [Sutherland, Bräunl 2002].
Program 9.1: Balance timer routine
1void CGyro::TimerSample()
2{ ...
3iAngVel = accreadX();
4if (iAngVel > -1)
5{
6iAngVel = iAngVel;
7// Get the elapsed time
8iTimeNow = OSGetCount();
9iElapsed = iTimeNow - g_iSampleTime;
10// Correct elapsed time if rolled over!
11if (iElapsed < 0) iElapsed += 0xFFFFFFFF; // ROLL OVER
12// Correct the angular velocity
13iAngVel -= g_iZeroVelocity;
14// Calculate angular displacement
15g_iAngle += (g_iAngularVelocity * iElapsed);
16g_iAngularVelocity = -iAngVel;
17g_iSampleTime = iTimeNow;
18// Read inclinometer (drain residual values)
19iRawADReading = OSGetAD(INCLINE_CHANNEL);
20iRawADReading = OSGetAD(INCLINE_CHANNEL);
21// If recording, and we have started...store data
22if (g_iTimeLastCalibrated > 0)
23{ ... /* re-calibrate sensor */
24}
25}
26// If correction factor remaining to apply, apply it!
27if (g_iGyroAngleCorrection > 0)
28{ g_iGyroAngleCorrection -= g_iGyroAngleCorrectionDelta;
29g_iAngle -= g_iGyroAngleCorrectionDelta;
30}
31}
Second A second two-wheel balancing robot had been built in a later project [Ooi balancing robot 2003], Figure 9.4. Like the first robot it uses a gyroscope and inclinometer as sensors, but it employs a Kalman filter method for balancing [Kalman 1960], [Del Gobbo, Napolitano, Famouri, Innocenti 2001]. A number of Kalmanbased control algorithms have been implemented and compared with each other, including a pole-placement controller and a Linear Quadratic Regulator (LQR) [Nakajima, Tsubouchi, Yuta, Koyanagi 1997], [Takahashi, Ishikawa, Hagiwara 2001]. An overview of the robot’s control system from [Ooi 2003] is
shown in Figure 9.5.
The robot also accepts driving commands from an infrared remote control, which are interpreted as a bias by the balance control system. They are used to drive the robot forward/backward or turn left/right on the spot.
127

9 Balancing Robots
Figure 9.4: Second balancing robot design
Figure 9.5: Kalman-based control system
9.3 Double Inverted Pendulum
Another design is taking the inverted pendulum approach one step further by replacing the two wheels with four independent leg joints. This gives us the equivalent of a double inverted pendulum; however, with two independent legs controlled by two motors each, we can do more than balancing – we can walk.
Dingo The double inverted pendulum robot Dingo is very close to a walking robot, but its movements are constrained in a 2D plane. All sideways motions can be ignored, since the robot has long, bar-shaped feet, which it must lift over each other. Since each foot has only a minimal contact area with the ground, the robot has to be constantly in motion to maintain balance.
128

References
Figure 9.6 shows the robot schematics and the physical robot. The robot uses the same sensor equipment as BallyBot, namely an inclinometer and a gyroscope.
Figure 9.6: Double inverted pendulum robot
9.4 References
CAUX, S., MATEO, E., ZAPATA, R. Balance of biped robots: special double-in- verted pendulum, IEEE International Conference on Systems, Man, and Cybernetics, 1998, pp. 3691-3696 (6)
DEL GOBBO, D., NAPOLITANO, M., FAMOURI, P., INNOCENTI, M., Experimental
application of extended Kalman filtering for sensor validation, IEEE Transactions on Control Systems Technology, vol. 9, no. 2, 2001, pp. 376-380 (5)
KAJITA, S., TANI, K. Experimental Study of Biped Dynamic Walking in the Linear Inverted Pendulum Mode, IEEE Control Systems Magazine, vol. 16, no. 1, Feb. 1996, pp. 13-19 (7)
KALMAN R.E, A New Approach to Linear Filtering and Prediction Problems, Transactions of the ASME - Journal of Basic Engineering, Series D, vol. 82, 1960, pp. 35-45
NAKAJIMA, R., TSUBOUCHI, T., YUTA, S., KOYANAGI, E., A Development of a
New Mechanism of an Autonomous Unicycle, IEEE International Conference on Intelligent Robots and Systems, IROS ‘97, vol. 2, 1997, pp. 906-912 (7)
129

9 Balancing Robots
OGASAWARA, K., KAWAJI, S. Cooperative motion control for biped locomotion robots, IEEE International Conference on Systems, Man, and Cybernetics, 1999, pp. 966-971 (6)
OOI, R., Balancing a Two-Wheeled Autonomous Robot, B.E. Honours Thesis, The Univ. of Western Australia, Mechanical Eng., supervised by T. Bräunl, 2003, pp. (56)
PARK, J.H., KIM, K.D. Bipedal Robot Walking Using Gravity-Compensated Inverted Pendulum Mode and Computed Torque Control, IEEE International Conference on Robotics and Automation, 1998, pp. 3528-3533
(6)
SEGWAY, Welcome to the evolution in mobility, http://www.segway.com, 2006
SUTHERLAND, A., BRÄUNL, T. Learning to Balance an Unknown System, Proceedings of the IEEE-RAS International Conference on Humanoid Robots, Humanoids 2001, Waseda University, Tokyo, Nov. 2001, pp. 385-391 (7)
SUTHERLAND, A., BRÄUNL, T. An Experimental Platform for Researching Robot Balance, 2002 FIRA Robot World Congress, Seoul, May 2002, pp. 14-19 (6)
TAKAHASHI, Y., ISHIKAWA, N., HAGIWARA, T. Inverse pendulum controlled two wheel drive system, Proceedings of the 40th SICE Annual Conference, International Session Papers, SICE 2001, 2001, pp. 112 -115 (4)
130

W. . . .ALKING. . . . . . . . . . . R. . .OBOTS. . . . . . . . . . . . . . . . . |
|
10 |
|
|
|
.. . . . . . . . |
|
Walking robots are an important alternative to driving robots, since the majority of the world’s land area is unpaved. Although driving robots are more specialized and better adapted to flat surfaces –
they can drive faster and navigate with higher precision – walking robots can be employed in more general environments. Walking robots follow nature by being able to navigate rough terrain, or even climb stairs or over obstacles in a standard household situation, which would rule out most driving robots.
Robots with six or more legs have the advantage of stability. In a typical walking pattern of a six-legged robot, three legs are on the ground at all times, while three legs are moving. This gives static balance while walking, provided the robot’s center of mass is within the triangle formed by the three legs on the ground. Four-legged robots are considerably harder to balance, but are still fairly simple when compared to the dynamics of biped robots. Biped robots are the most difficult to balance, with only one leg on the ground and one leg in the air during walking. Static balance for biped robots can be achieved if the robot’s feet are relatively large and the ground contact areas of both feet are overlapping. However, this is not the case in human-like “android” robots, which require dynamic balance for walking.
A collection of related research papers can be found in [Rückert, Sitte, Witkowski 2001] and [Cho, Lee 2002].
10.1 Six-Legged Robot Design
Figure 10.1 shows two different six-legged robot designs. The “Crab” robot was built from scratch, while “Hexapod” utilizes walking mechanics from Lynxmotion in combination with an EyeBot controller and additional sensors.
The two robots differ in their mechanical designs, which might not be recognized from the photos. Both robots are using two servos (see Section 3.5) per leg, to achieve leg lift (up/down) and leg swing (forward/backward) motion. However, Crab uses a mechanism that allows all servos to be firmly mounted on the robot’s main chassis, while Hexapod only has the swing ser-
131131

10 Walking Robots
vos mounted to the robot body; the lift servos are mounted on small subassemblies, which are moved with each leg.
The second major difference is in sensor equipment. While Crab uses sonar sensors with a considerable amount of purpose-built electronics, Hexapod uses infrared PSD sensors for obstacle detection. These can be directly interfaced to the EyeBot without any additional electronic circuitry.
Figure 10.1: Crab six-legged walking robot, Univ. Stuttgart, and Lynxmotion Hexapod base with EyeCon, Univ. Stuttgart
Program 10.1 shows a very simple program generating a walking pattern for a six-legged robot. Since the same EyeCon controller and the same RoBIOS operating system are used for driving and walking robots, the robot’s HDT (Hardware Description Table) has to be adapted to match the robot’s physical appearance with corresponding actuator and sensor equipment.
Data structures like GaitForward contain the actual positioning data for a gait. In this case it is six key frames for moving one full cycle for all legs. Function gait (see Program 10.2) then uses this data structure to “step through” these six individual key frame positions by subsequent calls of
move_joint.
Function move_joint moves all the robot’s 12 joints from one position to the next position using key frame averaging. For each of these iterations, new positions for all 12 leg joints are calculated and sent to the servos. Then a certain delay time is waited before the routine proceeds, in order to give the servos time to assume the specified positions.
132

Six-Legged Robot Design
Program 10.1: Six-legged gait settings
1#include "eyebot.h"
2ServoHandle servohandles[12];
3int semas[12]= {SER_LFUD, SER_LFFB, SER_RFUD, SER_RFFB,
4 |
|
|
SER_LMUD, SER_LMFB, SER_RMUD, SER_RMFB, |
5 |
#define |
MAXF |
SER_LRUD, SER_LRFB, SER_RRUD, SER_RRFB}; |
6 |
50 |
||
7 |
#define |
MAXU |
60 |
8#define CNTR 128
9#define UP (CNTR+MAXU)
10#define DN (CNTR-MAXU)
11#define FW (CNTR-MAXF)
12#define BK (CNTR+MAXF)
13#define GaitForwardSize 6
14int GaitForward[GaitForwardSize][12]= {
15{DN,FW, UP,BK, UP,BK, DN,FW, DN,FW, UP,BK},
16{DN,FW, DN,BK, DN,BK, DN,FW, DN,FW, DN,BK},
17{UD,FW, DN,BK, DN,BK, UP,FW, UP,FW, DN,BK},
18{UP,BK, DN,FW, DN,FW, UP,BK, UP,BK, DN,FW},
19{DN,BK, DN,FW, DN,FW, DN,BK, DN,BK, DN,FW},
20{DN,BK, UP,FW, UP,FW, DN,BK, DN,BK, UP,FW},
21};
22#define GaitTurnRightSize 6
23int GaitRight[GaitTurnRightSize][12]= { ...};
24#define GaitTurnLeftSize 6
25int GaitLeft[GaitTurnLeftSize][12]= { ...};
26int PosInit[12]=
27{CT,CT, CT,CT, CT,CT, CT,CT, CT,CT, CT,CT};
Program 10.2: Walking routines
1void move_joint(int pos1[12], int pos2[12], int speed)
2{ int i, servo, steps = 50;
3float size[12];
4for (servo=0; servo<NumServos; servo++)
5size[servo] = (float) (pos2[servo]-pos1[servo]) /
6 |
(float) steps; |
7for (i=0;i<steps;i++)
8{ for(servo=0; servo<NumServos; servo++)
9SERVOSet(servohandles[servo], pos1[servo]+
10 |
(int)((float) i *size[servo])); |
11OSWait(10/speed);
12}
13}
1void gait(int g[][12], int size, int speed)
2{ int i;
3for (i=0; i<size; i++)
4move_joint(g[i], g[(i+1)%size], speed);
5}
133

10 Walking Robots
10.2 Biped Robot Design
Finally, we get to robots that resemble what most people think of when hearing the term “robot”. These are biped walking robots, often also called “humanoid robots” or “android robots” because of their resemblance to human beings.
Figure 10.2: Johnny and Jack humanoid robots, UWA
Our first attempts at humanoid robot design were the two robots Johnny Walker and Jack Daniels, built in 1998 and named because of their struggle to maintain balance during walking (see Figure 10.2, [Nicholls 1998]). Our goal was humanoid robot design and control with limited funds. We used servos as actuators, linked in an aluminum U-profile. Although servos are very easily interfaced to the EyeBot controller and do not require an explicit feedback loop, it is exactly this feature (their built-in hardwired feedback loop and lack of external feedback) which causes most control problems. Without feedback sensors from the joints it is not possible to measure joint positions or joint torques.
These first-generation robots were equipped with foot switches (microswitches and binary infrared distance switches) and two-axes accelerometers in the hips. Like all of our other robots, both Johnny and Jack are completely autonomous robots, not requiring any umbilical cords or “remote brains”. Each robot carries an EyeBot controller as on-board intelligence and a set of rechargeable batteries for power.
The mechanical structure of Johnny has nine degrees of freedom (dof), four per leg plus one in the torso. Jack has eleven dof, two more for its arms. Each of the robots has four dof per leg. Three servos are used to bend the leg at the ankle, knee, and hip joints, all in the same plane. One servo is used to turn the
134