Файл: Embedded Robotics (Thomas Braunl, 2 ed, 2006).pdf

Contents

21.1 Concepts and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

21.2 Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

21.3 Genetic Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

21.4 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

21.5 Tracking Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

21.6 Evolution of Tracking Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

21.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

22.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

22.2 Behavior-Based Robotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

22.3 Behavior-Based Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

22.4 Behavior Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

22.5 Adaptive Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

22.6 Tracking Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

22.7 Neural Network Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

22.8 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

22.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

23.1 Splines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

23.2 Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

23.3 Incorporating Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

23.4 Controller Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

23.5 Controller Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

23.6 Evolved Gaits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

23.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

APPENDICES

A Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

B RoBIOS Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

C Hardware Description Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

D Hardware Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

E Laboratories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

F Solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

XIII

PART I:

EMBEDDED SYSTEMS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .

1

Robotics has come a long way. Especially for mobile robots, a similar trend is happening as we have seen for computer systems: the transition from mainframe computing via workstations to PCs, which will

probably continue with handheld devices for many applications. In the past, mobile robots were controlled by heavy, large, and expensive computer systems that could not be carried and had to be linked via cable or wireless devices. Today, however, we can build small mobile robots with numerous actuators and sensors that are controlled by inexpensive, small, and light embedded computer systems that are carried on-board the robot.

There has been a tremendous increase of interest in mobile robots. Not just as interesting toys or inspired by science fiction stories or movies [Asimov 1950], but as a perfect tool for engineering education, mobile robots are used today at almost all universities in undergraduate and graduate courses in Computer Science/Computer Engineering, Information Technology, Cybernetics, Electrical Engineering, Mechanical Engineering, and Mechatronics.

What are the advantages of using mobile robot systems as opposed to traditional ways of education, for example mathematical models or computer simulation?

First of all, a robot is a tangible, self-contained piece of real-world hardware. Students can relate to a robot much better than to a piece of software. Tasks to be solved involving a robot are of a practical nature and directly “make sense” to students, much more so than, for example, the inevitable comparison of sorting algorithms.

Secondly, all problems involving “real-world hardware” such as a robot, are in many ways harder than solving a theoretical problem. The “perfect world” which often is the realm of pure software systems does not exist here. Any actuator can only be positioned to a certain degree of accuracy, and all sensors have intrinsic reading errors and certain limitations. Therefore, a working robot program will be much more than just a logic solution coded in software.

33

1 Robots and Controllers

It will be a robust system that takes into account and overcomes inaccuracies and imperfections. In summary: a valid engineering approach to a typical (industrial) problem.

Third and finally, mobile robot programming is enjoyable and an inspiration to students. The fact that there is a moving system whose behavior can be specified by a piece of software is a challenge. This can even be amplified by introducing robot competitions where two teams of robots compete in solving a particular task [Bräunl 1999] – achieving a goal with autonomously operating robots, not remote controlled destructive “robot wars”.

1.1 Mobile Robots

Since the foundation of the Mobile Robot Lab by the author at The University of Western Australia in 1998, we have developed a number of mobile robots, including wheeled, tracked, legged, flying, and underwater robots. We call these robots the “EyeBot family” of mobile robots (Figure 1.1), because they are all using the same embedded controller “EyeCon” (EyeBot controller, see the following section).

Figure 1.1: Some members of the EyeBot family of mobile robots

The simplest case of mobile robots are wheeled robots, as shown in Figure 1.2. Wheeled robots comprise one or more driven wheels (drawn solid in the figure) and have optional passive or caster wheels (drawn hollow) and possibly steered wheels (drawn inside a circle). Most designs require two motors for driving (and steering) a mobile robot.

The design on the left-hand side of Figure 1.2 has a single driven wheel that is also steered. It requires two motors, one for driving the wheel and one for turning. The advantage of this design is that the driving and turning actions

4

Mobile Robots

Figure 1.2: Wheeled robots

have been completely separated by using two different motors. Therefore, the control software for driving curves will be very simple. A disadvantage of this design is that the robot cannot turn on the spot, since the driven wheel is not located at its center.

The robot design in the middle of Figure 1.2 is called “differential drive” and is one of the most commonly used mobile robot designs. The combination of two driven wheels allows the robot to be driven straight, in a curve, or to turn on the spot. The translation between driving commands, for example a curve of a given radius, and the corresponding wheel speeds has to be done using software. Another advantage of this design is that motors and wheels are in fixed positions and do not need to be turned as in the previous design. This simplifies the robot mechanics design considerably.

Finally, on the right-hand side of Figure 1.2 is the so-called “Ackermann Steering”, which is the standard drive and steering system of a rear-driven passenger car. We have one motor for driving both rear wheels via a differential box and one motor for combined steering of both front wheels.

It is interesting to note that all of these different mobile robot designs require two motors in total for driving and steering.

A special case of a wheeled robot is the omni-directional “Mecanum drive” robot in Figure 1.3, left. It uses four driven wheels with a special wheel design and will be discussed in more detail in a later chapter.

Figure 1.3: Omni-directional, tracked, and walking robots

One disadvantage of all wheeled robots is that they require a street or some sort of flat surface for driving. Tracked robots (see Figure 1.3, middle) are more flexible and can navigate over rough terrain. However, they cannot navigate as accurately as a wheeled robot. Tracked robots also need two motors, one for each track.

5

1 Robots and Controllers

Legged robots (see Figure 1.3, right) are the final category of land-based mobile robots. Like tracked robots, they can navigate over rough terrain or climb up and down stairs, for example. There are many different designs for legged robots, depending on their number of legs. The general rule is: the more legs, the easier to balance. For example, the six-legged robot shown in the figure can be operated in such a way that three legs are always on the ground while three legs are in the air. The robot will be stable at all times, resting on a tripod formed from the three legs currently on the ground – provided its center of mass falls in the triangle described by these three legs. The less legs a robot has, the more complex it gets to balance and walk, for example a robot with only four legs needs to be carefully controlled, in order not to fall over. A biped (two-legged) robot cannot play the same trick with a supporting triangle, since that requires at least three legs. So other techniques for balancing need to be employed, as is discussed in greater detail in Chapter 10. Legged robots usually require two or more motors (“degrees of freedom”) per leg, so a sixlegged robot requires at least 12 motors. Many biped robot designs have five or more motors per leg, which results in a rather large total number of degrees of freedom and also in considerable weight and cost.

Braitenberg A very interesting conceptual abstraction of actuators, sensors, and robot vehicles control is the vehicles described by Braitenberg [Braitenberg 1984]. In one example, we have a simple interaction between motors and light sensors. If a light sensor is activated by a light source, it will proportionally increase the

speed of the motor it is linked to.

Figure 1.4: Braitenberg vehicles avoiding light (phototroph)

In Figure 1.4 our robot has two light sensors, one on the front left, one on the front right. The left light sensor is linked to the left motor, the right sensor to the right motor. If a light source appears in front of the robot, it will start driving toward it, because both sensors will activate both motors. However, what happens if the robot gets closer to the light source and goes slightly off course? In this case, one of the sensors will be closer to the light source (the left sensor in the figure), and therefore one of the motors (the left motor in the figure) will become faster than the other. This will result in a curve trajectory of our robot and it will miss the light source.

6