Embedded Robotics (Thomas Braunl, 2 ed, 2006)

1 Robots and Controllers

© InroSoft, Thomas Bräunl 2006

Figure 1.7: EyeCon schematics

program. The on-board motor controllers and feedback encoders utilize the lower TPU channels plus some pins from the CPU port E, while the speaker uses the highest TPU channel. Twelve TPU channels are provided with matching connectors for servos, i.e. model car/plane motors with pulse width modulation (PWM) control, so they can simply be plugged in and immediately operated. The input keys are linked to CPU port F, while infrared distance sensors (PSDs, position sensitive devices) can be linked to either port E or some of the digital inputs.

An eight-line analog to digital (A/D) converter is directly linked to the CPU. One of its channels is used for the microphone, and one is used for the battery status. The remaining six channels are free and can be used for connecting analog sensors.

1.3 Interfaces

A number of interfaces are available on most embedded systems. These are digital inputs, digital outputs, and analog inputs. Analog outputs are not always required and would also need additional amplifiers to drive any actuators. Instead, DC motors are usually driven by using a digital output line and a pulsing technique called “pulse width modulation” (PWM). See Chapter 3 for

10

Interfaces

graphics LCD

reset button power switch

parallel port

motors and encoders (2)

background debugger analog inputs

digital I/O

servos (14)

Figure 1.8: EyeCon controller M5, front and back

details. The Motorola M68332 microcontroller already provides a number of digital I/O lines, grouped together in ports. We are utilizing these CPU ports as

11

1 Robots and Controllers

can be seen in the schematics diagram Figure 1.7, but also provide additional digital I/O pins through latches.

Most important is the M68332’s TPU. This is basically a second CPU integrated on the same chip, but specialized to timing tasks. It simplifies tremendously many time-related functions, like periodic signal generation or pulse counting, which are frequently required for robotics applications.

Figure 1.8 shows the EyeCon board with all its components and interface connections from the front and back. Our design objective was to make the construction of a robot around the EyeCon as simple as possible. Most interface connectors allow direct plug-in of hardware components. No adapters or special cables are required to plug servos, DC motors, or PSD sensors into the EyeCon. Only the HDT software needs to be updated by simply downloading the new configuration from a PC; then each user program can access the new hardware.

The parallel port and the three serial ports are standard ports and can be used to link to a host system, other controllers, or complex sensors/actuators. Serial port 1 operates at V24 level, while the other two serial ports operate at TTL level.

The Motorola background debugger (BDM) is a special feature of the M68332 controller. Additional circuitry is included in the EyeCon, so only a cable is required to activate the BDM from a host PC. The BDM can be used to debug an assembly program using breakpoints, single step, and memory or register display. It can also be used to initialize the flash-ROM if a new chip is inserted or the operating system has been wiped by accident.

Figure 1.9: EyeBox units

12

Operating System

At The University of Western Australia, we are using a stand-alone, boxed version of the EyeCon controller (“EyeBox” Figure 1.9) for lab experiments in the Embedded Systems course. They are used for the first block of lab experiments until we switch to the EyeBot Labcars (Figure 7.5). See Appendix E for a collection of lab experiments.

1.4 Operating System

Embedded systems can have anything between a complex real-time operating system, such as Linux, or just the application program with no operating system, whatsoever. It all depends on the intended application area. For the EyeCon controller, we developed our own operating system RoBIOS (Robot Basic Input Output System), which is a very lean real-time operating system that provides a monitor program as user interface, system functions (including multithreading, semaphores, timers), plus a comprehensive device driver library for all kinds of robotics and embedded systems applications. This includes serial/parallel communication, DC motors, servos, various sensors, graphics/text output, and input buttons. Details are listed in Appendix B.5.

User input/output

RoBIOS Operating system + Library functions

HDT

Hardware

Robot mechanics, actuators, and sensors

Figure 1.10: RoBIOS structure

The RoBIOS monitor program starts at power-up and provides a comprehensive control interface to download and run programs, load and store programs in flash-ROM, test system components, and to set a number of system parameters. An additional system component, independent of RoBIOS, is the

13

1 Robots and Controllers

Hardware Description Table (HDT, see Appendix C), which serves as a userconfigurable hardware abstraction layer [Kasper et al. 2000], [Bräunl 2001].

RoBIOS is a software package that resides in the flash-ROM of the controller and acts on the one hand as a basic multithreaded operating system and on the other hand as a large library of user functions and drivers to interface all on-board and off-board devices available for the EyeCon controller. RoBIOS offers a comprehensive user interface which will be displayed on the integrated LCD after start-up. Here the user can download, store, and execute programs, change system settings, and test any connected hardware that has been registered in the HDT (see Table 1.1).

The RoBIOS structure and its relation to system hardware and the user program are shown in Figure 1.10. Hardware access from both the monitor program and the user program is through RoBIOS library functions. Also, the monitor program deals with downloading of application program files, storing/ retrieving programs to/from ROM, etc.

The RoBIOS operating system and the associated HDT both reside in the controller’s flash-ROM, but they come from separate binary files and can be

14

References

downloaded independently. This allows updating of the RoBIOS operating system without having to reconfigure the HDT and vice versa. Together the two binaries occupy the first 128KB of the flash-ROM; the remaining 384KB are used to store up to three user programs with a maximum size of 128KB each (Figure 1.11).

Figure 1.11: Flash-ROM layout

Since RoBIOS is continuously being enhanced and new features and drivers are being added, the growing RoBIOS image is stored in compressed form in ROM. User programs may also be compressed with utility srec2bin before downloading. At start-up, a bootstrap loader transfers the compressed RoBIOS from ROM to an uncompressed version in RAM. In a similar way, RoBIOS unpacks each user program when copying from ROM to RAM before execution. User programs and the operating system itself can run faster in RAM than in ROM, because of faster memory access times.

Each operating system comprises machine-independent parts (for example higher-level functions) and machine-dependent parts (for example device drivers for particular hardware components). Care has been taken to keep the machine-dependent part as small as possible, to be able to perform porting to a different hardware in the future at minimal cost.

1.5 References

ASIMOV I. Robot, Doubleday, New York NY, 1950

BRAITENBERG, V. Vehicles – Experiments in Synthetic Psychology, MIT Press, Cambridge MA, 1984

15

1 Robots and Controllers

BRÄUNL, T. Research Relevance of Mobile Robot Competitions, IEEE Robotics and Automation Magazine, Dec. 1999, pp. 32-37 (6)

BRÄUNL, T. Scaling Down Mobile Robots - A Joint Project in Intelligent MiniRobot Research, Invited paper, 5th International Heinz Nixdorf Symposium on Autonomous Minirobots for Research and Edutainment, Univ. of Paderborn, Oct. 2001, pp. 3-10 (8)

INROSOFT, http://inrosoft.com, 2006

JONES, J., FLYNN, A., SEIGER, B. Mobile Robots - From Inspiration to Implementation, 2nd Ed., AK Peters, Wellesley MA, 1999

KASPER, M., SCHMITT, K., JÖRG, K., BRÄUNL, T. The EyeBot Microcontroller with On-Board Vision for Small Autonomous Mobile Robots, Workshop on Edutainment Robots, GMD Sankt Augustin, Sept. 2000,

http://www.gmd.de/publications/report/0129/Text.pdf, pp. 15-16 (2)

16

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

. . . . . . . . .

There are a vast number of different sensors being used in robotics, applying different measurement techniques, and using different interfaces to a controller. This, unfortunately, makes sensors a difficult sub-

ject to cover. We will, however, select a number of typical sensor systems and discuss their details in hardware and software. The scope of this chapter is more on interfacing sensors to controllers than on understanding the internal construction of sensors themselves.

What is important is to find the right sensor for a particular application. This involves the right measurement technique, the right size and weight, the right operating temperature range and power consumption, and of course the right price range.

Data transfer from the sensor to the CPU can be either CPU-initiated (polling) or sensor-initiated (via interrupt). In case it is CPU-initiated, the CPU has to keep checking whether the sensor is ready by reading a status line in a loop. This is much more time consuming than the alternative of a sensor-initiated data transfer, which requires the availability of an interrupt line. The sensor signals via an interrupt that data is ready, and the CPU can react immediately to this request.

Table 2.1: Sensor output

1717

2 Sensors

2.1 Sensor Categories

From an engineer’s point of view, it makes sense to classify sensors according to their output signals. This will be important for interfacing them to an embedded system. Table 2.1 shows a summary of typical sensor outputs together with sample applications. However, a different classification is required when looking at the application side (see Table 2.2).

From a robot’s point of view, it is more important to distinguish:

•Local or on-board sensors

(sensors mounted on the robot)

•Global sensors

(sensors mounted outside the robot in its environment and transmitting sensor data back to the robot)

For mobile robot systems it is also important to distinguish:

•Internal or proprioceptive sensors

(sensors monitoring the robot’s internal state)

•External sensors

(sensors monitoring the robot’s environment)

18

Binary Sensor

A further distinction is between:

•Passive sensors

(sensors that monitor the environment without disturbing it, for example digital camera, gyroscope)

•Active sensors

(sensors that stimulate the environment for their measurement, for example sonar sensor, laser scanner, infrared sensor)

Table 2.2 classifies a number of typical sensors for mobile robots according to these categories. A good source for information on sensors is [Everett 1995].

2.2 Binary Sensor

Binary sensors are the simplest type of sensors. They only return a single bit of information, either 0 or 1. A typical example is a tactile sensor on a robot, for example using a microswitch. Interfacing to a microcontroller can be achieved very easily by using a digital input either of the controller or a latch. Figure 2.1 shows how to use a resistor to link to a digital input. In this case, a pull-up resistor will generate a high signal unless the switch is activated. This is called an “active low” setting.

GND

Figure 2.1: Interfacing a tactile sensor

2.3 Analog versus Digital Sensors

A number of sensors produce analog output signals rather than digital signals. This means an A/D converter (analog to digital converter, see Section 2.5) is required to connect such a sensor to a microcontroller. Typical examples of such sensors are:

•Microphone

•Analog infrared distance sensor

19