N.E.R.D - Obstacle Avoidance

Approaching Obstacle Avoidance:

When we first started brainstorming ideas for how to tackle the obstacle, we had to keep some restrictions in mind.
These restrictions were that the algorithm for obstacle would have to incorporate the Pi cam and would involve communication between the Raspberry Pi and the MegaPi.
The simple algorithm we started with goes as follows: 1. See the obstacle using the ultrasonic sensor, 2. Start to go around the obstacle, 3. Stop going around the obstacle when the line is detected.
From these simple steps, we laid the foundation for what would become a more complicated series of communications between the two boards in order to maintain good timing and precision.

Communication between Raspberry Pi and MegaPi:

The Algorithm and Flowchart (MegaPi Side):

The algorithm for the MegaPi was mainly motor control, but it also had the key function of being able to use the ultrasonic sensor, which allowed the robot to tell if there was an obstacle in front of it. The flowchart below shows the steps that the MegaPi runs through in order to complete obstacle.

Flowchart of Obstacle Avoidance on the MegaPi

First, the MegaPi checks if there is an obstacle in front of the robot using the values the ultrasonic sensor returns. If it detects an obstacle, it will send over the first message, the letter “o” to the Pi. This tells the Pi that an obstacle has been detected.
After the first message is sent, the robot will turn to the right and check if there is a wall there. If there is a wall there, that means the robot cannot drive around the obstacle that way, so it must turn left and drive around the other way. A wall can be seen if the ultrasonic returns a distance that is less than 10 cm.
Next, the second message (the letter “d”) is sent to tell the Pi to start looking for the line. After the message is sent, the robot will start to drive around the obstacle.
While it is driving around the obstacle, the robot will also be checking through Serial if there is a message sent and if it is the letter “b”. If it is, that means the line has been seen and the robot should go back to normal line following.

The Algorithm and Flowchart (Raspberry Pi Side):

The algorithm we developed for obstacle goes through a series of back and forth via Serial Communication. The flowchart below represents the Raspberry Pi and it shows what steps are taken during obstacle.

First, the Pi checks if any messages are being received at the beginning of the program. If there is a message, it goes on to read it and see what it is and if there is no message, it will continue line following.
In the case that there is a message, the Pi will have to read it and determine whether it is correct or not. This is done by comparing the message received to the correct message (a letter “o” in this case). This step is so in case there is a wrong message sent or a message sent at the wrong time, the Pi will not think it has to do obstacle.
After the first message is determined to be the letter “o”, the next step is to wait until it receives another message (a letter “d” in this case) from the MegaPi. This message signifies that the Pi can start using the camera to try to see the line.
While this is happening, the MegaPi is controlling the motors to drive around the obstacle. Once the camera (controlled by the Pi) sees the line, it will send a message (the letter “b”) over Serial to the MegaPi telling it to stop driving around the obstacle.
After this, the Pi returns to line following and goes back to the top of the flowchart.

Flowchart of Obstacle Avoidance on the Raspberry Pi

ImplEmentation of Solution:

Although the algorithm itself was quite simple, there were still some issues that kept it from working at first.
The main issue we found was that the Raspberry Pi would look for the line before it was told to (it updated camera values before receiving the message that told it to do so).
This issue was very detrimental to our algorithm because the robot relied heavily on the camera to tell it when the line was spotted so it could stop at the right time.
We were able to overcome this issue by “waiting” until the wrong values were replaced by the new ones and then starting the part where the Pi would use the camera to look for the line. This worked very well and the obstacle algorithm was able to work smoothly after.
A second issue we found was the robot stopped line following after obstacle had finished. This was due to the timing not being correct and the Pi starting too early.
We fixed this issue by adding a delay before going back to line following.

Page updated

Google Sites

Report abuse