ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 13.06.2025
Просмотров: 4189
Скачиваний: 0
2 Sensors
perfect local 2D map from the viewpoint of the robot, or even a complete 3D distance map. Unfortunately, these sensors are still too large and heavy (and too expensive) for small mobile robot systems. This is why we concentrate on infrared distance sensors.
sensor |
obstacle |
infrared LED
infrared detector array
Figure 2.6: Infrared sensor
Infrared sensors Infrared (IR) distance sensors do not follow the same principle as sonar sensors, since the time-of-flight for a photon would be much too short to measure with a simple and cheap sensor arrangement. Instead, these systems typically use a pulsed infrared LED at about 40kHz together with a detection array (see Figure 2.6). The angle under which the reflected beam is received changes according to the distance to the object and therefore can be used as a measure of the distance. The wavelength used is typically 880nm. Although this is invisible to the human eye, it can be transformed to visible light either by IR detector cards or by recording the light beam with an IR-sensitive camera.
Figure 2.7 shows the Sharp sensor GP2D02 [Sharp 2006] which is built in a similar way as described above. There are two variations of this sensor:
•Sharp GP2D12 with analog output
•Sharp GP2D02 with digital serial output
The analog sensor simply returns a voltage level in relation to the measured distance (unfortunately not proportional, see Figure 2.7, right, and text below). The digital sensor has a digital serial interface. It transmits an 8bit measurement value bit-wise over a single line, triggered by a clock signal from the CPU as shown in Figure 2.2.
In Figure 2.7, right, the relationship between digital sensor read-out (raw data) and actual distance information can be seen. From this diagram it is clear that the sensor does not return a value linear or proportional to the actual distance, so some post-processing of the raw sensor value is necessary. The simplest way of solving this problem is to use a lookup table which can be calibrated for each individual sensor. Since only 8 bits of data are returned, the lookup table will have the reasonable size of 256 entries. Such a lookup table is provided in the hardware description table (HDT) of the RoBIOS operating system (see Section B.3). With this concept, calibration is only required once per sensor and is completely transparent to the application program.
24
Compass
Figure 2.7: Sharp PSD sensor and sensor diagram (source: [Sharp 2006])
Another problem becomes evident when looking at the diagram for actual distances below about 6cm. These distances are below the measurement range of this sensor and will result in an incorrect reading of a higher distance. This is a more serious problem, since it cannot be fixed in a simple way. One could, for example, continually monitor the distance of a sensor until it reaches a value in the vicinity of 6cm. However, from then on it is impossible to know whether the obstacle is coming closer or going further away. The safest solution is to mechanically mount the sensor in such a way that an obstacle can never get closer than 6cm, or use an additional (IR) proximity sensor to cover for any obstacles closer than this minimum distance.
IR proximity switches are of a much simpler nature than IR PSDs. IR proximity switches are an electronic equivalent of the tactile binary sensors shown in Section 2.2. These sensors also return only 0 or 1, depending on whether there is free space (for example 1-2cm) in front of the sensor or not. IR proximity switches can be used in lieu of tactile sensors for most applications that involve obstacles with reflective surfaces. They also have the advantage that no moving parts are involved compared to mechanical microswitches.
2.7 Compass
A compass is a very useful sensor in many mobile robot applications, especially self-localization. An autonomous robot has to rely on its on-board sensors in order to keep track of its current position and orientation. The standard method for achieving this in a driving robot is to use shaft encoders on each wheel, then apply a method called “dead reckoning”. This method starts with a known initial position and orientation, then adds all driving and turning actions to find the robot’s current position and orientation. Unfortunately, due to wheel slippage and other factors, the “dead reckoning” error will grow larger
25
2 Sensors
Analog compass
Digital compass
and larger over time. Therefore, it is a good idea to have a compass sensor onboard, to be able to determine the robot’s absolute orientation.
A further step in the direction of global sensors would be the interfacing to a receiver module for the satellite-based global positioning system (GPS). GPS modules are quite complex and contain a microcontroller themselves. Interfacing usually works through a serial port (see the use of a GPS module in the autonomous plane, Chapter 11). On the other hand, GPS modules only work outdoors in unobstructed areas.
Several compass modules are available for integration with a controller. The simplest modules are analog compasses that can only distinguish eight directions, which are represented by different voltage levels. These are rather cheap sensors, which are, for example, used as directional compass indicators in some four-wheel-drive car models. Such a compass can simply be connected to an analog input of the EyeBot and thresholds can be set to distinguish the eight directions. A suitable analog compass model is:
•Dinsmore Digital Sensor No. 1525 or 1655 [Dinsmore 1999]
Digital compasses are considerably more complex, but also provide a much higher directional resolution. The sensor we selected for most of our projects has a resolution of 1° and accuracy of 2°, and it can be used indoors:
•Vector 2X
[Precision Navigation 1998]
This sensor provides control lines for reset, calibration, and mode selection, not all of which have to be used for all applications. The sensor sends data by using the same digital serial interface already described in Section 2.3. The sensor is available in a standard (see Figure 2.8) or gimbaled version that allows accurate measurements up to a banking angle of 15°.
Figure 2.8: Vector 2X compass
26
Gyroscope, Accelerometer, Inclinometer
2.8 Gyroscope, Accelerometer, Inclinometer
Orientation sensors to determine a robot’s orientation in 3D space are required for projects like tracked robots (Figure 7.7), balancing robots (Chapter 9), walking robots (Chapter 10), or autonomous planes (Chapter 11). A variety of sensors are available for this purpose (Figure 2.9), up to complex modules that can determine an object’s orientation in all three axes. However, we will concentrate here on simpler sensors, most of them only capable of measuring a single dimension. Two or three sensors of the same model can be combined for measuring two or all three axes of orientation. Sensor categories are:
•Accelerometer
Measuring the acceleration along one axis
• Analog Devices ADXL05 |
(single axis, analog output) |
• Analog Devices ADXL202 |
(dual axis, PWM output) |
•Gyroscope
Measuring the rotational change of orientation about one axis
• HiTec GY 130 Piezo Gyro (PWM input and output)
•Inclinometer
Measuring the absolute orientation angle about one axis
• Seika N3 |
(analog output) |
• Seika N3d |
(PWM output) |
Figure 2.9: HiTec piezo gyroscope, Seika inclinometer
2.8.1 Accelerometer
All these simple sensors have a number of drawbacks and restrictions. Most of them cannot handle jitter very well, which frequently occurs in driving or especially walking robots. As a consequence, some software means have to be taken for signal filtering. A promising approach is to combine two different sensor types like a gyroscope and an inclinometer and perform sensor fusion in software (see Figure 7.7).
A number of different accelerometer models are available from Analog Devices, measuring a single or two axes at once. Sensor output is either analog
27
2 Sensors
or a PWM signal that needs to be measured and translated back into a binary value by the CPU’s timing processing unit.
The acceleration sensors we tested were quite sensitive to positional noise (for example servo jitter in walking robots). For this reason we used additional low-pass filters for the analog sensor output or digital filtering for the digital sensor output.
2.8.2 Gyroscope
The gyroscope we selected from HiTec is just one representative of a product range from several manufacturers of gyroscopes available for model airplanes and helicopters. These modules are meant to be connected between the receiver and a servo actuator, so they have a PWM input and a PWM output. In normal operation, for example in a model helicopter, the PWM input signal from the receiver is modified according to the measured rotation about the gyroscope’s axis, and a PWM signal is produced at the sensor’s output, in order to compensate for the angular rotation.
Figure 2.10: Gyroscope drift at rest and correction
Obviously, we want to use the gyroscope only as a sensor. In order to do so, we generate a fixed middle-position PWM signal using the RoBIOS library routine SERVOSet for the input of the gyroscope and read the output PWM signal of the gyroscope with a TPU input of the EyeBot controller. The periodical PWM input signal is translated to a binary value and can then be used as sensor data.
A particular problem observed with the piezo gyroscope used (HiTec GY 130) is drift: even when the sensor is not being moved and its input PWM signal is left unchanged, the sensor output drifts over time as seen in Figure 2.10 [Smith 2002], [Stamatiou 2002]. This may be due to temperature changes in the sensor and requires compensation.
28
Gyroscope, Accelerometer, Inclinometer
An additional general problem with these types of gyroscopes is that they can only sense the change in orientation (rotation about a single axis), but not the absolute position. In order to keep track of the current orientation, one has to integrate the sensor signal over time, for example using the Runge-Kutta integration method. This is in some sense the equivalent approach to “dead reckoning” for determining the x/y-position of a driving robot. The integration has to be done in regular time intervals, for example 1/100s; however, it suffers from the same drawback as “dead reckoning”: the calculated orientation will become more and more imprecise over time.
Figure 2.11: Measured gyro in motion (integrated), raw and corrected
Figure 2.11 [Smith 2002], [Stamatiou 2002] shows the integrated sensor signal for a gyro that is continuously moved between two orientations with the help of a servo. As can be seen in Figure 2.11, left, the angle value remains within the correct bounds for a few iterations, and then rapidly drifts outside the range, making the sensor signal useless. The error is due to both sensor drift (see Figure 2.10) and iteration error. The following sensor data processing techniques have been applied:
1.Noise reduction by removal of outlier data values
2.Noise reduction by applying the moving-average method
3.Application of scaling factors to increment/decrement absolute angles
4.Re-calibration of gyroscope rest-average via sampling
5.Re-calibration of minimal and maximal rest-bound via sampling
Two sets of bounds are used for the determination and re-calibration of the gyroscope rest characteristics. The sensor drift has now been eliminated (upper curve in Figure 2.10). The integrated output value for the tilt angle (Figure 2.11, right) shows the corrected noise-free signal. The measured angular value now stays within the correct bounds and is very close to the true angle.
29
2 Sensors
2.8.3 Inclinometer
Inclinometers measure the absolute orientation angle within a specified range, depending on the sensor model. The sensor output is also model-dependent, with either analog signal output or PWM being available. Therefore, interfacing to an embedded system is identical to accelerometers (see Section 2.8.1).
Since inclinometers measure the absolute orientation angle about an axis and not the derivative, they seem to be much better suited for orientation measurement than a gyroscope. However, our measurements with the Seika inclinometer showed that they suffer a time lag when measuring and also are prone to oscillation when subjected to positional noise, for example as caused by servo jitter.
Especially in systems that require immediate response, for example balancing robots in Chapter 9, gyroscopes have an advantage over inclinometers. With the components tested, the ideal solution was a combination of inclinometer and gyroscope.
2.9 Digital Camera
Digital cameras are the most complex sensors used in robotics. They have not been used in embedded systems until recently, because of the processor speed and memory capacity required. The central idea behind the EyeBot development in 1995 was to create a small, compact embedded vision system, and it became the first of its kind. Today, PDAs and electronic toys with cameras are commonplace, and digital cameras with on-board image processing are available on the consumer market.
For mobile robot applications, we are interested in a high frame rate, because our robot is moving and we want updated sensor data as fast as possible. Since there is always a trade-off between high frame rate and high resolution, we are not so much concerned with camera resolution. For most applications for small mobile robots, a resolution of 60u80 pixels is sufficient. Even from such a small resolution we can detect, for example, colored objects or obstacles in the way of a robot (see 60u80 sample images from robot soccer in Figure 2.12). At this resolution, frame rates (reading only) of up to 30 fps (frames per second) are achievable on an EyeBot controller. The frame rate will drop, however, depending on the image processing algorithms applied.
The image resolution must be high enough to detect a desired object from a specified distance. When the object in the distance is reduced to a mere few pixels, then this is not sufficient for a detection algorithm. Many higher-level image processing routines are non-linear in time requirements, but even simple linear filters, for example Sobel edge detectors, have to loop through all pixels, which takes some time [Bräunl 2001]. At 60u80 pixels with 3 bytes of color per pixel this amounts to 14,400 bytes.
30
Digital Camera
Figure 2.12: Sample images with 60u80 resolution
Digital + analog camera output
Unfortunately for embedded vision applications, newer camera chips have much higher resolution, for example QVGA (quarter VGA) up to 1,024u1,024, while low-resolution sensor chips are no longer produced. This means that much more image data is being sent, usually at higher transfer rates. This requires additional, faster hardware components for our embedded vision system just to keep up with the camera transfer rate. The achievable frame rate will drop to a few frames per second with no other benefits, since we would not have the memory space to store these high-resolution images, let alone the processor speed to apply typical image processing algorithms to them. Figure 2.13 shows the EyeCam camera module that is used with the EyeBot embedded controller. EyeCam C2 has in addition to the digital output port also an analog grayscale video output port, which can be used for fast camera lens focusing or for analog video recording, for example for demonstration purposes.
In the following, we will discuss camera hardware interfaces and system software. Image processing routines for user applications are presented in Chapter 17.
2.9.1 Camera Sensor Hardware
In recent years we have experienced a shift in camera sensor technology. The previously dominant CCD (charge coupled device) sensor chips are now being overtaken by the cheaper to produce CMOS (complementary metal oxide semiconductor) sensor chips. The brightness sensitivity range for CMOS sensors is typically larger than that of CCD sensors by several orders of magnitude. For interfacing to an embedded system, however, this does not make a difference. Most sensors provide several different interfacing protocols that can be selected via software. On the one hand, this allows a more versatile hardware design, but on the other hand sensors become as complex as another microcontroller system and therefore software design becomes quite involved.
Typical hardware interfaces for camera sensors are 16bit parallel, 8bit parallel, 4bit parallel, or serial. In addition, a number of control signals have to be provided from the controller. Only a few sensors buffer the image data and allow arbitrarily slow reading from the controller via handshaking. This is an
31