Originally my robot kit was advertised as "avoidance" kit and it
does sport a rotating ultrasonic ranger sensor. Previously the DC
motors gave me so much trouble that I did not deal with this sensor
although the twowdrobot
library does provide two low-level functions
(TwoWDRobot::set_distance_direction and TwoWDRobot::get_distance)
to access the ultrasonic ranger and its servo. So I set out to
implement a "patrol" application that discovers an area, similarly
to cleaning robots.
My first observation is that the ranger sensor works reliably only if the degree between its main axis and the obstacle is close to 90 degrees. The following diagrams and pictures show 3 situations and the associated readings from the sensor, represented on a 2D diagram. The measurements were made with the twowdrobot_scan sketch that emits the measurement results to the serial port where they can be captured with a terminal emulator software.
The first situation is simple: the sensor points straight to a solid wall. Note however, that the sensor does not detect that the wall is long, even though at 50,60,70,120,130 degrees of sensor direction the wall areas are well within the sensor's range.
The second situation shows when the angle between the robot and the obstacle is small, about 20 degrees. You can see that when the sensor turns sideways (therefore its angle to the obstacle is nearly 90 degrees), the obstacle is detected. However there is no reading at the most important direction, 90 degrees so based on this measurement, the robot will hit the obstacle.
The third situation shows an obstacle that is not completely solid. Here the readings are completely mixed, there is a (quite far) reading at 90 degrees (even though the distance to hit the obstacle is much smaller) and there are much better readings of the obstacle to the right. Based on these measurements, however, the robot would hit the obstacle before the ranger sensor would detect it.
The "patrol" sketch cannot provide a perfect solution to these problems but at least employs some heuristics so that it can go around in a living room without getting frequently stuck.
You can observe that the quite conservative algorithm does avoid the majority of obstacles even in relatively complex environment. I have to say, however, that there are places in our living room that tricks this algorithm; hole-like places with no solid "walls" around it. Also, obstacles that are lower than the sensor's mounting (doorsteps, for example) cannot be handled by this robot.
How to go forward? The most evident missing sensor is a real distance measurement sensor that measures the actual distance traversed by the robot. The distance measurement sensor that we do have measures the rotation of the wheel and this works great as long as the wheel does not slip. Unfortunately if the robot gets stuck, the wheels normally keep on turning so this sensor is not suitable to detect if the robot is blocked.
I don't know yet where to mount this sensor but the most evident place is the rear wheel which is not driven by a motor.
My first observation is that the ranger sensor works reliably only if the degree between its main axis and the obstacle is close to 90 degrees. The following diagrams and pictures show 3 situations and the associated readings from the sensor, represented on a 2D diagram. The measurements were made with the twowdrobot_scan sketch that emits the measurement results to the serial port where they can be captured with a terminal emulator software.
The first situation is simple: the sensor points straight to a solid wall. Note however, that the sensor does not detect that the wall is long, even though at 50,60,70,120,130 degrees of sensor direction the wall areas are well within the sensor's range.
The second situation shows when the angle between the robot and the obstacle is small, about 20 degrees. You can see that when the sensor turns sideways (therefore its angle to the obstacle is nearly 90 degrees), the obstacle is detected. However there is no reading at the most important direction, 90 degrees so based on this measurement, the robot will hit the obstacle.
The third situation shows an obstacle that is not completely solid. Here the readings are completely mixed, there is a (quite far) reading at 90 degrees (even though the distance to hit the obstacle is much smaller) and there are much better readings of the obstacle to the right. Based on these measurements, however, the robot would hit the obstacle before the ranger sensor would detect it.
The "patrol" sketch cannot provide a perfect solution to these problems but at least employs some heuristics so that it can go around in a living room without getting frequently stuck.
- The ultrasonic scanning is done in 19 directions (0-180 degrees, 10 degrees steps) and if an obstacle is found, +/- 30 degrees of direction is blocked from the obstacle's direction. This tries to ensure that if an obstacle is detected in some direction, other parts of the obstacle not detected because of less optimal ultrasonic hit degree are still avoided.
- Even though the robot constantly scans the forward direction with
the ranger as it drives forward, we cannot trust this measurement
because the robot can easily hit something without the sensor noticing
it. Therefore the robot advances only as much as the sensor's range
(about 0.5 meters) and then does a 180 degree re-scan.
- If the TwoWDRobot::timed_straight_drive invocation returns a TIMEOUT condition (this means that it could not reach its destination in 5 seconds) we switch to reverse and back off. This is not perfect, however, because usually the wheels are turning even though the robot is stuck. This means that the distance sensor detects forward movement even if there is none.
You can observe that the quite conservative algorithm does avoid the majority of obstacles even in relatively complex environment. I have to say, however, that there are places in our living room that tricks this algorithm; hole-like places with no solid "walls" around it. Also, obstacles that are lower than the sensor's mounting (doorsteps, for example) cannot be handled by this robot.
How to go forward? The most evident missing sensor is a real distance measurement sensor that measures the actual distance traversed by the robot. The distance measurement sensor that we do have measures the rotation of the wheel and this works great as long as the wheel does not slip. Unfortunately if the robot gets stuck, the wheels normally keep on turning so this sensor is not suitable to detect if the robot is blocked.
I don't know yet where to mount this sensor but the most evident place is the rear wheel which is not driven by a motor.
No comments:
Post a Comment