16299 Final Project: Object-Following TWIP
by ebehzadi in Circuits > Arduino
87 Views, 1 Favorites, 0 Comments
16299 Final Project: Object-Following TWIP
We implemented a way for our Elegoo Tumbller robot to balance and then move towards/away from an object in order to achieve an optimal distance. It currently does so using its ultrasonic sensor, but ideally it would also work with a camera.
Supplies
We used:
- Elegoo Tumbller
- Arduino software
- A ruler to measure distance
- A tictac box (any flat material should work)
We also initially used a JeVois-A33 camera with printed ArUco markers, but ran into issues.
Make Robot Balance
Following Assignment 6, we implemented a PID controller to help the robot balance by using the MPU6050 which includes an accelerometer and a gyroscope, which we used to determine body angle and angular velocity. With this information we managed to have a PID controller keep it upright by measuring the error between the desired and current body angles and driving the motors respectively.
At first, we faced an issue with the fact that the encoders seemed to be backwards, but we fixed this by switching the signs of the angles.
Add and Calibrate Camera
After making the robot balance, we mounted a camera onto it, using heat shrink connections to fix the wiring. We then via standard checkerboard pattern to remove distortion and determine precise distances from pixel locations. We used a portable phone charger as a power source and ran the algorithm on the onboard processor, using the ArUco marker detector provided.
Make a Distance PID With Camera
We at first tried implementing a proportional control to keep a distance away from the ArUco marker that uses a new gain term that affects motor commands proportional to difference between measured and desired distance from tracked object. We attempted to integrate this with our balance control. This gain term tried to keep an optimal distance of 10 cm.
However, this failed due to issues in the baud rate -- data was being too sent slowly and it would read the data in a desynchronized way, such as by mixing up the width of the target as the depth. To fix this, we attempted to increase the baud rate but that caused the entire system to crash multiple times. We tried averaging values but that did not seem to work either, and decided to use the ultrasonic sensor as we believed it wouldn't have this error.
Try With Ultrasonic Sensor
We then tried using a similar proportional control with the ultrasonic sensor, this time keeping a distance of 15 cm. We adjusted the setup by using a mentos box and a ruler to make sure it stayed the proper distance away. We realized that the plastic tray was messing with the readings, so we decided to remove it in order to get the most accurate results. We found that it worked much better than the camera, and was less susceptible to noise as predicted.
Optimize
We then optimized the code for our PID controller for distance, and obtained 5 good trial runs in a row with the following stats:
Trial Length of Time(seconds) Maximum Tilt (radians) Avg Error (cm)
1 18.528 0.0876 2.6046
2 21.688 0.1032 2.4727
3 26.784 0.2438 2.3584
4 16.892 0.3185 3.4057
5 25.012 0.3506 3.7353
We used the program attached to obtain these results, and were satisfied with their consistency.
Downloads
Possible Future Steps
In the future it would be good for the robot to turn to track an object that moves in multiple axes, as well as match the orientation of an object/ArUco marker. Additionally, it would be nice to increase the baud rate to sample more frequently by using a different camera module, we well as get it to recognize different commands. We would want to reduce average distance error by using derivative control on the distance variable.