Difference between revisions of "Duckling"
|Line 139:||Line 139:|
Revision as of 15:24, 11 December 2018
- 1 Link to Log
- 2 Project Proposal
- 3 Design and Solutions
- 4 Results
Link to Log
There once was a time when children's toy cars would be bland and boring. A child might push the car and chase it, or use her own remote controller to move the car around, but no real fun was to had when the car couldn't move freely! We wish to fix this lack of fun by designing an entirely new kind of car-the kind of car that chases you! By integrating remote-controlled car, raspberry pi, and arduino, we plan to design a pi car so that its sensors (through the Pi camera) may evaluate a person's movement and follow them. The arduino will direct the car by communicating with the motor, servo and ESC . All components will be mounted on top of the car to create one autonomous system that needs no outside influence, besides a person's movements, to direct its path.
Tony Sancho (TA)
The duckling project will be deemed a success if
1. The duckling's pi car is constructed successfully according to the reference guide
2. The pi car is able to sense a red dot (or other comparable reference point) and move towards it
3. The raspberry pi successfully connects to a pi camera
4. The sensors can differentiate between the movements of a target person or object and other movements.
5. The duckling pi car will move according to information from the camera
6. The duckling pi car will use the camera to follow a person
We expect our challenges to include:
1. Completing our project under budget
2. Learning how to use the raspberry pi and arduino
3. Interfacing the pi and arduino with one another
4. 3-D printing. No members have experience.
5. Getting the camera to communicate with the raspberry pi
6. Working with the PI camera image processing to sense a person
7. Difficulties with hardware assembly
We also expect that we may have difficulty working on the project independently if we do not all have access to the pi car with the arduino and raspberry pi mounted on top. We plan to leave it in the lab in order to protect our project and promote inclusivity in access. We have no concerns regarding privacy, user safety, or security from malicious attacks.
Dromida 1/18 Buggy($99)
ISC25 Rotary Encoder($40)
32GB MicroSD Card($13)
IMU 9DoF Sensor Stick($15)
Raspberry Pi Camera Module V2($30)
Brushed ESC Motor Speed Controller($6)
TowerPro SG90 Micro Servo($4)
TFMini - Micro LiDAR Module($40)
Arduino (free from lab)
Raspberry Pi (free)
Supplies purchased according to Pi Car documentation 
Design and Solutions
Building the car
We bought a Dromida buggy and dismantled it to create our chassis for the car. We took out its batteries and motor, and replaced them with our own battery and motor. We connected the motor to an electronic speed controller, and also mounted a rotary encoder onto the chassis by drilling and dremeling through it. This forms Layer 0 of the car. We created a GND and 5V channel using breadboard and used spacers to mount the raspberry Pi and Arduino onto the first printed layer and then mounted that layer onto the car. We would have mounted the Lidar module onto the second layer, but we decided against its functionality to meet our objectives. A more detailed overview of the mechanical assembly can be found at the Pi car documentation We faced several difficulties with gear meshing for both the rotary encoder and the motor gear. We Macgyvered 'quick fix' solutions to both issues but the problem actually turned out to be with the cheap plastic spur gear that came with the buggy. A future build of the car could potentially use a metal spur gear. Furthermore, we had issues with the steering wherein we couldn't fix pins onto our chassis to hold parts that connected to the wheels. We improvised a solution to that by using Alan wrenches as pins instead. Our turnigy 1A battery also dipped below 30% and it turns out they cannot be recharged if they cross that threshold. This was on the day before demo so we were panicking because we couldn't find another 1A battery at a store nearby, but we tried using a 1.5 A battery instead and it worked. There were also several instances where we tried testing and the entire car just fell apart, so we had to rebuild it a few times.
ESC, motor, encoder and servo connection
This is how the components were connected. (Credit to Zimon from the other Pi car group for the picture)
Pi and Arduino connection
We initially planned to implement a serial port between the Pi and Arduino, but decided to use I2C communication instead, using the code on this website , wiring them as follows
How the code works (pseudo code):
1. Initialize video stream and PiCamera 2. Read if the Arduino sends something 3. Initialize openCV tracker with the desired properties 4. Draw the tracking circle While there is something to track Update tracker position Save tracker position Convert position to angle Send angle and speed to Arduino
3D printed parts (Credit to Adith Boloor):
Encoder Mount: https://a360.co/2DUNNK6
First Layer: https://a360.co/2RquoDs
Second Layer: https://a360.co/2OBMGmP
Here is what our final build of the car looks like
A demonstration of the car following a red object
As is evident, the car can successfully track the colours we teach it to recognise. The camera works well under different lighting conditions as the range of HSV values we taught it to recognise is wide. The speed of the car is constant and is controlled from a rpm variable in the source code itself. The motor gear doesn't mesh with the spur gear at lower speeds so we had to set the rpms constant at a relatively high value.
Our car had a successful demo, as outlined by our initial objectives. It moves smoothly and follows objects as intended. The only difference is that we chose not to use the kinect but that didn't change the functionality of the car. The reason for that is that a kinect is expensive and its hard to obtain a second hand one. Furthermore it's hard to interface the kinect with the Raspberry Pi, so we chose to use to use a Pi camera instead. We also could not add depth mapping functionality (we intended to use a lidar module in place of the kinect) because getting the motor and encoder to work was a lot harder than we foresaw. Next steps: Implementing depth mapping in order to calibrate the speed of the car. It currently moves at a constant speed but if it had the lidar module on it to feed the RPi distances then we could control the speed of the car. We could make that functionality open to the user as well instead of having the car "smart drive" and decide for itself how fast it should go.