Test the automatic mode of movement of the home robot based on data from the infrared, ultrasonic rangefinder and encoders. This article is a continuation of the previous review of the home robot ver 0.3 . The idea is to make the robot able to move independently around the house without human intervention. About the selected chassis platform described in the previous article. In the process of implementation and testing, a less acceptable obstacle detection system was found about which I will discuss below.
It is based on the locator, as it were - the range finders rotating on a micro server.
Infrared range finder SHARP GP2Y0A41SKOF, stated that it measures the distance from 4x to 30 centimeters. In reality, it can measure further, but with more error. When an obstacle to 4 centimeters gives distorted data, as if the obstacle to be further. Beam sector is small. ')
From the following graph you can roughly understand the dependence of the signal on the distance.
Test code for the SHARP GP2Y0A41SKOF range finder.
Ultrasonic range finder HC-SR04, stated that it measures at a distance of from 2 to 450 centimeters. The sector of measurement is large depending on the side, ranging from 30 to 60 degrees. The distance calculation is linear, the time of the reflected sound is divided by the speed of sound.
Moreover, for the pulseIn function, you can set the maximum signal waiting time; otherwise, in the absence of a reflected sound wave, it can wait a long time, thereby blocking the program execution, I empirically set the following value
time_us=pulseIn(Echo, HIGH,50000);
It is also necessary to say that, depending on the surface of the obstacle and the angle of reflection, the range finders can lie very much. Using two range finders with different types in the same direction helps to improve measurement accuracy. At the moment, I first of all follow the data from the infrared rangefinder, when it fails, I take data from the ultrasound.
Serva rotates range finders from 30 to 150 degrees in increments of 30 degrees, the numbers are taken empirically for measurement speed and simplicity. Measurements are stored in an array and on demand at any time can be carried out to check for obstacles in a rectangular area in front of the robot.
Since often the robot for one reason or another did not detect an obstacle, it decided to determine that the robot had crashed and could not continue moving according to data from encoders installed on the wheel shaft.
Encoders are used like this.
The mechanism of their action is simple, there is installed an optical sensor on the lumen of the holes in the disk. Hung up changes of the sensor on interruptions of arduino, below an approximate code:
voidLwheelSpeed() { coderLeft++; //count the left wheel encoder interrupts } void setup() { attachInterrupt(LEFT, LwheelSpeed, CHANGE); }
About once every 200 milliseconds, the wheel speed is calculated. Accordingly, if while driving the speed of the wheels drops dramatically, it is considered that the robot collided with an obstacle. After that, he pulls back and turns around.
Such a non-clever sensor system achieves almost a hundred percent guarantee of obstacle detection. In the video you can see how the robot handles all these situations.
Now I’m waiting for the microswitches and finishing up the 3d printer, I’ll make a bumper for the robot. Then I think I will work out almost all possible situations.
Several pictures of the robot from different angles.
I’m opening the open source project for this robot, as I’ll finish the robot to a more or less sane state, I’ll post the circuit design and source code, if anyone needs to write in a personal email right now.
More information, news, photos and videos, see the group VKontakte on this project - vk.com/club23358759
Write in the comments on what topic to write the following article, make a video.