Embedded Robotics (Thomas Braunl, 2 ed, 2006)

Controller Assessment

3.Allow final refinement of the solution by evolving the control point tangent values.

To evolve the controller in this form, a staged encoding method is required. Table 23.1 indicates the number of control points required to represent the controller in each phase. In the case of an encoding where each value is represented as an 8 bit fixed-point number, the encoding complexity directly corresponds to the number of bytes required to describe the controller.

with

a number of actuators

s number of initialization control points, and c number of cyclic control points

Table 23.1: Encoding complexity

23.5 Controller Assessment

In order to assign a fitness value to each controller, a method for evaluating the generated gait is required. Since many of the generated gaits result in the robot eventually falling over, it is desirable to first simulate the robot’s movement in order to avoid damaging the actual robot hardware. There are many different dynamic simulators available that can be employed for this purpose.

One such simulator is DynaMechs, developed by McMillan [DynaMechs 2006]. The simulator implements an optimized version of the Articulated Body algorithm, and provides a range of integration methods with configurable step sizes. The package is free, open source, and can be compiled for a variety of operating systems (Windows, Linux, Solaris). The simulator provides information about an actuator’s location, orientation, and forces at any time, and this information can be utilized to determine the fitness of a gait.

A number of fitness functions have been proposed to evaluate generated gaits. Reeve proposed the following sets of fitness measures [Reeve 1999]:

•FND (forward not down): The average speed the walker achieves minus the average distance of the center of gravity below the starting height.

•DFND (decay FND): Similar to the FND function, except it uses an exponential decay of the fitness over the simulation period.

351

23 Evolution of Walking Gaits

•DFNDF (DFND or fall): As above, except a penalty is added for any walker whose body touches the ground.

Fitness function These fitness functions do not consider the direction or path that is desired for the robot to walk along. Thus, more appropriate fitness functions can be employed by extending the simple FND function to include path information, and including terminating conditions [Boeing, Bräunl 2002]. The terminating conditions assign a very low fitness value to any control system which generates a gait that results in:

•A robot’s central body coming too close to the ground. This termination condition ensures that robots do not fall down.

•A robot that moves too far from the ground. This removes the possibility of robots achieving high fitness values early in the simulation by propelling themselves forward through the air (jumping).

•A robot’s head tilting too far forward. This ensures the robots are reasonably stable and robust.

Thus, the overall fitness function is calculated, taking into account the distance the robot moves along the desired path, plus the distance the robot deviates from the path, minus the distance the robot’s center of mass has lowered over the period of the walk, as well as the three terminating conditions.

23.6 Evolved Gaits

This system is capable of generating a wide range of gaits for a variety of robots. Figure 23.4 illustrates a gait for a simple bipedal robot. The robot moves forward by slowly lifting one leg by rotating the hip forward and knee backward, then places its foot further in front, straightens its leg, and repeats this process. The gait was evolved within 12 hours on a 500MHz AMD Athlon PC. The genetic algorithm typically requires the evaluation of only 1,000 individuals to evolve an adequate forward walking pattern for a bipedal robot.

Figure 23.4: Biped gait

Figure 23.5 illustrates a gait generated by the system for a tripod robot. The robot achieves forward motion by thrusting its rear leg toward the ground, and

352

Evolved Gaits

lifting its forelimbs. The robot then gallops with its forelimbs to produce a dynamic gait. This illustrates that the system is capable of generating walking patterns for legged robots, regardless of the morphology and number of legs.

Figure 23.5: Tripod gait

The spline controller also evolves complex dynamic movements. Removing the termination conditions allows for less stable and robust gaits to be evolved. Figure 23.6 shows a jumping gait evolved for an android robot. The resultant control system depicted was evolved within 60 generations and began convergence toward a unified solution within 30 generations. However, the gait was very unstable, and the android could only repeat the jump three times before it would fall over.

Figure 23.6: Biped jumping

The spline controller utilized to create the gait depicted in Figure 23.4 was extended to include sensory information from an inclinometer located in the robot’s torso. The inclinometer reading was successfully interpreted by the control system to provide an added level of feedback capable of sustaining the generated gait over non-uniform terrain. An example of the resultant gait is

Figure 23.7: Biped walking over uneven terrain

353

23 Evolution of Walking Gaits

illustrated in Figure 23.7. The controller required over 4 days of computation time on a 800MHz Pentium 3 system, and was the result of 512 generations of evaluation.

Figure 23.8: Fitness versus generation for extended spline controller

The graph in Figure 23.8 demonstrates the increase in fitness value during the evolution of the extended controller depicted in Figure 23.7. A rapid increase in fitness values can clearly be observed at around 490 generations. This corresponds to the convergence point where the optimal solution is located. The sharp increase is a result of the system managing to evolve a controller that was capable of traversing across flat, rising, and lowering terrains.

This chapter presented a flexible architecture for controller evolution, and illustrated a practical robotics application for genetic algorithms. The control system was shown to describe complex dynamic walking gaits for robots with differing morphologies. A similar system can be employed to control any robot consisting of multiple actuators, and the present system could be extended to evolve the robot’s morphology in unison with the controller. This would enable the robot’s design to be improved, such that the robot’s structure was optimally designed to suit its desired purpose. Further extensions of this could be to automatically construct the designed robots using 3D printing technology, removing the human designer completely from the robot design process [Lipson, Pollack 2006].

354

References

23.7 References

BARTELS, R,. BEATTY, J., BARSKY, B. An Introduction to Splines for Use in Computer Graphics and Geometric Models, Morgan Kaufmann, San Francisco CA, 1987

BOEING, A., BRÄUNL, T. Evolving Splines: An alternative locomotion controller for a bipedal robot, Proceedings of the Seventh International Conference on Control, Automation, Robotics and Vision (ICARV 2002), CD-ROM, Nanyang Technological University, Singapore, Dec. 2002, pp. 1-5 (5)

BOEING, A., BRÄUNL, T. Evolving a Controller for Bipedal Locomotion, Proceedings of the Second International Symposium on Autonomous Minirobots for Research and Edutainment, AMiRE 2003, Brisbane, Feb. 2003, pp. 43-52 (10)

DYNAMECHS, Dynamics of Mechanisms: A Multibody Dynamic Simulation Library, http://dynamechs.sourceforge.net, 2006

LEDGER, C. Automated Synthesis and Optimization of Robot Configurations, Ph.D. Thesis, Carnegie Mellon University, 1999

LEWIS, M., FAGG, A., BEKEY, G. Genetic Algorithms for Gait Synthesis in a Hexapod Robot, in Recent Trends in Mobile Robots, World Scientific, New Jersey, 1994, pp. 317-331 (15)

LIPSON, H., POLLACK, J. Evolving Physical Creatures, http://citeseer. nj.nec.com/523984.html, 2006

REEVE, R. Generating walking behaviours in legged robots, Ph.D. Thesis, University of Edinburgh, 1999

355

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. . In this book we have presented the application of embedded systems for

small autonomous mobile robots. We looked at embedded systems in general, their interfacing to sensors and actuators, basic operation system functions, device drivers, multitasking, and system tools. A number of detailed programming examples were used to aid understanding of this practical sub-

ject area.

Of course, time does not stand still. In the decade of development of the EyeBot robots and the EyeCon controller we have already seen quite a remarkable development in components.

A whole new generation of image sensors has emerged. CMOS sensors are slowly overtaking CCD sensors, because of their lower production cost and larger brightness range. Image sensor resolution has increased in a similar fashion to the processing power of microprocessors. However, a higher resolution is not always desirable in small robot systems, because there is a trade-off between image resolution versus frame rate, and for most of our applications a higher frame rate is more important than a higher resolution. The required processing time usually grows much faster than linearly with the number of image pixels.

Also, the development of microcontrollers has not kept up with the increased processing speeds of microprocessors, most likely because of insufficient industrial demand for fast microcontrollers. In general, the latest-gener- ation embedded systems are about an order of magnitude slower than high-end PCs or workstations. On the other hand, commercial embedded systems meet additional requirements such as an extended temperature range and electromagnetic compatibility (EMC). That means these systems must be able to function in a harsh environment, at cold or hot temperatures, and in the presence of electromagnetic noise, while their own level of electromagnetic emission is strictly limited.

With this rapid development in processor and image sensor chips, advances in motors, gearboxes, and battery technology seem slower. However, one should not forget that improvements in the resolution of image sensors and in

357357

24 Outlook

the speed of processor chips are mainly a consequence of miniaturization – a technique that cannot easily be applied to other components.

The biggest challenge and the largest effort, however, remains software development. One can easily overlook how many person-years of software development are required for a project like EyeBot/RoBIOS. This includes operating system routines, compiler adaptations, system tools, simulation systems, and application programs. Especially time-consuming are all low-level device drivers, most of them written in assembly language or incompatible C/ C++ code. Every migration to a different CPU or sensor chip requires the redevelopment of this code.

We are still far away from intelligent reasoning robots, integrated into our human environment. However, extrapolating the achievements of the past, and projecting exponential increase, maybe the RoboCup/FIRA vision for the year 2050 will become a reality.

358

APPENDICES

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

359

PROGRAMMING TOOLS A

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

A.1 System Installation

We are using the “GNU” cross-compiler tools [GNU 2006] for operating system development as well as for compiling user programs. GNU stands for “Gnu’s not Unix”, representing an independent consortium of worldwide distributed software developers that have created a huge open-source software collection for Unix systems. The name, however, seems to be a relic from the days when proprietary Unix implementations had a larger market share.

Supported operating systems for EyeCon are Windows (from DOS to XP) and Unix (Linux, Sun Solaris, SGI Unix, etc.).

Windows System installation in Windows has been made extremely simple, by providing an installer script, which can be executed by clicking on:

rob65win.exe

This executable will run an installer script and install the following components on a Windows system:

•GNU cross-compiler for C/C++ and assembly

•RoBIOS libraries, include-files, hex-files and shell-scripts

•Tools for downloading, sound conversion, remote control, etc.

•Example programs for real robot and simulator

Unix For installation under Unix, several pre-compiled packages are available for the GNU cross-compiler. For Linux Red-Hat users, “rpm” packages are available as well. Because a number of different Unix systems are supported, the cross-compiler and the RoBIOS distribution have to be installed separately, for example:

361361

A Programming Tools

The cross-compiler has to be installed in a directory that is contained in the command path, to ensure the Unix operating system can execute it (when using “rpm” packages, a standard path is being chosen). The RoBIOS distribution can be installed at an arbitrary location. The following lists the required steps:

•>setenv ROBIOS /usr/local/robios/

Set the environment variable ROBIOS to the chosen installation path.

•>setenv PATH "${PATH}:/usr/local/gnu/bin:${ROBIOS}/cmd"

make

(In Windows first open a console window by double-clicking on “startrob.bat“.) This will compile all C and assembly files and generate corresponding hex-files that can subsequently be downloaded to the controller and run.

RoBIOS upgrade Upgrading to a newer RoBIOS version or updating a hardware description file (HDT) with new sensors/actuators is very simple. Simple downloading of the new binary file is required. RoBIOS will automatically detect the system file and prompt the user to authorize overwriting of the flash-ROM. Only in the case of a corrupted flash-ROM is the background debugger required to reinstall RoBIOS (see Section A.4). Of course, the RoBIOS version installed on the local host system has to match the version installed on the EyeCon controller.

A.2 Compiler for C and C++

The GNU cross-compiler [GNU 2006] supports C, C++, and assembly language for the Motorola 68000 family. All source files have specific endings that determine their type:

362