How it works?
Detailed Pin Diagram
Group Members Information
Figure 1: Robot Car Top View
In this Project we have designed a robot which will follow a certain path avoiding all the obstacle in its way maintaining a definite direction.
If it gets multiple obstacle its path it will recursively avoid them and get back to its original path with an algorithm we developed.
But sometimes when there is a large obstacle(like a wall) in its way it might get stuck. In that case we can to go manual mode to take the robot to its original path and put it in auto mode again. This is why we are calling it semi-autonomous.
Figure 2: Robot Car Front View
Raspberry Pi 3 Model B
Powerbank (5V 2.1A) to power Raspberry Pi
LM298N Motor Driver
HC-SR-04 Ultrasonic Sensor
4WD Robot Chassis
4AA Battery Holders
In this project Raspberry Pi 3 Model B is used for interfacing with various hardware peripherals. The current design is a robot, which will stay on its course while avoiding obstacles. Obstacle is detected using an ultrasonic sensor. The ultrasonic sensor sends out an ultrasonic signal and waits for the echo. From the time required to get back the echo, distance of the obstacle can be calculated. Whenever the distance falls below a certain threshold (set to 50cm in the code), a special "pulse like" movement is started to avoid the obstacle.
Figure 3: Obstacle Avoiding Movement
To successfully complete this movement we need to perform two types of movement.
Moving straight is also a requirement for staying on course when there is no obstacle. The robot moves straight if both the right and left motors have the same speed. Now we will briefly discuss how we controlled the speed of the motors.
Central to speed control in our project is the LM298N motor driver. It can be used to independently control two DC motors. For each of the motors it has two power pins, two control pins and one enable pin. The control pins and the enable pin are connected to Raspberry Pi. In our case we controlled four motors with a single motor driver by connecting left motors together and also the right motors together. The LM298N motor cannot directly control speed. However by sending PWM signal to the enable pins and controlling the duty cycle of the signal speed control can be achieved. The higher the duty cycle the faster the motor turns and the lower the duty cycle the slower the motor turns.
By calibrating the duty cycle for the left motors and right motors we can make the wheels go at the same speed. These duty cycle values were obtained by experiment and they generally change with battery charge.
Turning the robot is easy. To turn right we just stopped the right motors while the left motors kept turning. Turning left can be done similarly. However it is hard to turn the robot by certain degrees. It was done by experimentally determining how long it takes the robot to move by ninety degrees using the above mentioned process. After this time passes we stop the robot and continue with next movement. We found out that this time is dependent on floor characteristics and battery charge. So it is very hard to find a time that will work consistently in different floors and at different state of battery charge.
With the ability to move in a straight line and turning by ninety degrees it is easy to avoid obstacles by following the pulse like
movement shown above. The length of BC, CD and DE are hard-coded. So our robot can only
avoid obstacles of certain size. If obstacle was detected while performing this movement another pulse like movement to avoid the
obstacle is done. In code it is done by making the obstacle avoid function recursive.
Figure 4: Block Diagram
Here we describe our algorithm that we implemented for our project. The complete code can be found here Semi-Autonomous-Obstacle-Avoider.
Figure 5: Pin Diagram
Figure 6: Pin Diagram for Raspberry Pi
Defective Car (Chassis):
We had initially used a 2WD robotic car chassis with two castors for balancing. The castors were problematic. They would guide the robot to and fro sometimes based on their initial orientation. So before every run we had to set their orientation straight manually to obtain desired result. Moreover, another strange problem we were having was self disassembling of the wheels. If we tried to run our robot multiple times, often the wheels would become loose and ultimate would be thrown by motor rotation from their shafts.
To solve these problems we had changed our robotic car chassis and used a 4WD car to avoid these weird circumstances.
We had tried long enough to keep our robot absolutely straight by controlling duty cycle, using feedback mechanism, partial mild oscillatory driving technique and so forth before we realized it was a universal problem. In this regard we had found a research paper Real Robots Don't Go Straight where it is mentioned that driving robots absolutely straight is next to impossible and the only way to do so is to devise a feedback mechanism based on orientation data. However it did not work in our case either.
Later with our new car chassis, this problem was mitigated to some extend when we approximated curves with very low curvature to be straight lines.
Unreliable Orientation Data: We were trying to use the orientation data calculated from our accelerometer, gyroscope and compass combining sensor. We were using the rate of change of them to find out orientation/ deviation from current direction. However, we managed to find out later that these data were unreliable for mathematical calculation purposes. This is because of the range of noise and stationary standard deviation of them. Once any of these values changed, they would require quite some time to be stable. In the mean time our robot would have changed its position further and ultimately we could not find a suitable model for this dynamic behavior.
Variable bouncing time of wheel encoder:
The wheel encoder is a sensorthatdetects the movement of small teeth connected to a motor through the reflection of infrared light. By measuring the amount of reflected infrared light it tells how fast the wheels are turning. For this purpose, it has to sense reflected infrared light exactly one time per each teeth. If it senses reflected infrared light multiple times in one teeth interval then it will give a defect result about wheel turning. The way to avoid this problem is to give a sleep time after sensing one reflected infrared light. This sleep time is known as debouncing time. Now, it should not be so large that it skips the next teeth when the wheel is rotating very fast and should not be so small that it senses more than once in one teeth interval when the wheel is rotating so slowly. It is absolutely speed dependent.
We had to face a lot of troubles to determine it properly and ultimately could not come up with a proper model that suits our purpose.
Motor speed change with battery discharging: The speed of motors reduces with discharging of battery. The change of speed of motors creates some problems that we had to face. Since no hardware is normally perfect we had to tune the motor duty cycle parameters to drive the robot somewhat straight. But they kept changing with battery discharging and would be valid for only a short period of time.
If we had used a high voltage battery ( about 12v ) and a voltage regulator ( e.g. of 10v ) then this problem would be solved partially. But we used 8 pencil batteries ( each of 1.5v ) with no voltage regulator and so had to tackle the problem manually
Noise from sonar sensor: Sometimes, sonar sensor gives some garbage low valuesthat may be introduced to the robot as an obstacle. This unwanted noise from sensor sometimes displaces the robot from its main track. As a result, the robot may fail to go straight trying to avoid a virtual obstacle that actually has no existence.
We used a threshold to differentiate between actual obstacle and noise.
Surface Dependency: The movement of our robot was dependent on the surface because the friction of different surfaces differ resulting in variable slippage of the wheels. As we result we had to tune the parameters for each individual surface independently.
We could use a fixed surface for running our robot smoothly. But we did not opt for it considering the dissimilarity with the real world
Section A1: Group 2
Shadman Saqib Eusuf (1205003)
Ibraheem Muhammad Moosa (1205005)
Kazi Ashik Islam (1205007)
Bishwajit Saha (1205043)
SK. Adnan Hassan (1205059)
Back to top