A small car-like robot which is self-driving and can avoid obstacles by mapping its surroundings. We envision that a worker can place an object on our robot, which can then be transported from point A to B without the worker having to do it him/herself.
Our final project, Deep's Dynamo, involved an autonomous vehicle that has the ability to avoid obstacles placed in its path. Additionally, the vehicle can be manually overriden/controlled wirelessly through the Blynk app if needed. An ultrasonic sensor mounted on a servo motor was used for obstacle detection, with periodic scans occurring to keep the system updated. An LCD screen with a "radar" displaying the angle of the servo was also included.
SRS 01 - Timer 0, an 8-bit timer, shall be used to control the motor in phase correct PWM mode.
This is exactly what we implemented! We set up the registers/pins properly to enable Timer 0, and connected the servo motor's PWM pin to PD5 (the pin associated with Timer 0). Note that for the PWM mode, we chose phase-correct PWM since we should be able to easily vary the duty cycle to control the servo position.
SRS 02 - Timer 1, a 16-bit timer, shall be used to control the echo pin of the ultrasonic sensor in PWM mode.
This is exactly what we implemented! We set up the registers/pins properly to enable Timer 1, and connected the ultrasonic sensor's PWM pin to PB0 (the pin associated with Timer 1). Note that for the PWM mode, we chose phase-correct PWM since the signals are symmetric.
SRS 03 - Timer 2, an 8-bit timer, shall be used to control the trigger pin of the ultrasonic sensor in PWM mode.
This is exactly what we implemented! We set up the registers/pins properly to enable Timer 2, and connected the ultrasonic sensor's PWM pin to PD3 (the pin associated with Timer 2). Note that for the PWM mode, we chose phase-correct PWM since the signals are symmetric.
SRS 04 - The UART serial communication protocol shall be used to send commands between the two ATMEGA328PBs as well as between the one ATMEGA328PB and the ESP32.
This is exactly what was done. We utilized the fact that there are two UART ports for each ATMEGA328PB (UART0 and UART1) to make this possible. Thus, the main ATMEGA328PB communicates with the two other boards using the two UART ports.
SRS 05 - Utilize Timer 1's interrupt to detect the reflected signal via the echo pin and translate the echo signal's time into a distance.
This was successfully accomplished. We often checked pin PD3 using the oscilloscope to ensure that the interrupt was being triggered as expected (and saw that it was).
SRS 06 - There shall be a wireless IoT based control mechanism allowing for manual control of the vehicle through the Blynk app.
We were able to successfully integrate this. We utilized an ESP32 and UART protocol for wireless communication via the Blynk app, thus allowing for control of the vehicle via the app.
HRS 01 - Our system shall use two ATMEGA328PBs - One to control the LCD screen and the other to manage all the timers that control the ultrasonic sensor's trigger and echo, as well as the servo that turns the ultrasonic sensor.
This is exactly what we implemented. By dividing the two tasks between two ATMEGA328PBs, we achieved modularity and allowed for much easier testing and debugging. In previous labs, we were informed that performing UART for printing in addition to controlling the LCD screen is hard to achieve using one ATMEGA328PB, which is why we used a second ATMEGA328PB to control the LCD screen which displays the radar. We ended up using the first Atmega328PB to send ultrasonic sensor servo angle information to the second Atmega328PB via UART.
HRS 02 - An ultrasonic sensor shall be used for obstacle detection. It shall detect obstacles at a distance of 12 cm or closer from the front of the vehicle.
This worked. Based on our repeated testing and measurements, we noticed that whenever an obstacle was indeed 12 cm or closer, the vehicle would properly stop its advance, turn, and avoid the obstacle. This was successfully implemented due to proper mounting of the ultrasonic sensor on top of the servo motor, in addition to setting up the appropriate formula for calculating distance as dictated by the datasheet of the ultrasonic sensor.
HRS 03 - The ultrasonic sensor shall be mounted on top of a servo motor. The servo motor should rotate 360 degrees to help enable scanning for obstacles around the vehicle by the ultrasonic sensor.
We were able to partially implement this, in that our servo motor only rotates 180 degrees, but this change was intentional due to the requirements of our project. Firstly, the servo motor that we used can only rotate 270 degrees, not the full 360 degrees. We also realized that based on how we mounted the servo, if we performed a full 360 degree rotation, the servo would face the chassis, registering mistakenly a distance less than 12 cm (thereby "detecting" an obstacle and trying its best to rotate). For this reason, we limited ourselves to a 180 degree rotation.
HRS 04 - We shall use an ESP32 for interfacing with the Blynk app, thereby enabling wireless control of the vehicle via phone.
We were able to get this done successfully. We utilized an ESP32 and UART protocol for wireless communication via the Blynk app, thus allowing for control of the vehicle via the app. The Blynk app has 4 buttons to control forward, backward, left, and right movements of the robot.
HRS 05 - We shall utilize a 128x160 LCD screen to display a radar indicating the ultrasonic sensor's sweep. The display will interface with the corresponding ATMEGA328PB through the SPI protocol.
We were able to successfully complete this. A second ATMEGA328PB was necessary to utilize printing to the data visualizer in addition to using the LCD screen. The second ATMEGA328PB received servo angle information via UART from the first ATMEGA328PB.
HRS 06 - There shall be a power management system in place to avoid powering using a laptop.
We were able to accomplish this to some extent. We had a power bank that was sufficient for powering the two Atmegas and the ESP32 all at the same time. The halbot had a separate built-in power management system that powered the wheels etc. We did face some issues during the development process in terms of managing the current - evidenced by burning through 2 ATMEGA328PBs and having smoke emit from the first halbot system used. The servo motor was also found to draw significant power, which is why we included an inverter made of power transistors to take in the PWM signal from the ATMEGA328PB and output the signal to the servo motor.
Overall, we feel that our project was a success since we were able to meet the general goal of making an autonomous vehicle that avoids obstacles by monitoring its surroundings. We are proud of what we were able to accomplish in the short time frame and felt that we approached the project design and execution processes in a rational manner. The project was able to be completed using only parts in Detkin, and we made a conscious decision to do so to avoid any potential challenges with delays in part orders. We also were able to adapt and be resourceful to achieve the desired functionality. For example, we decided to use an ultrasonic sensor mounted on a servo motor for obstacle detection since these were widely available in Detkin, and would be easier to implement in the short time frame associated with the project.
However, we cannot simply mount this setup on top of the halbot since this means the ultrasonic sensor would be quite high off the ground, meaning many obstacles smaller in height would not be detected properly. As a result, we used a piece of cardboard with a strategically placed hole that extends out from the rest of the chassis as a means to hold the servo/ultrasonic sensor, and this cardboard doubled as a "bumper" to protect the rest of the car in the event of an accidental collision. However, this does not mean that we did not face any challenges during the development process.
We first burned through two ATMEGA328PBs during our development process, partly due to an insufficient power management system. For one, we realized that the servo draws too much power which fried the Atmega, causing us to shift towards using an inverter made out of power transistors to take the PWM signal from the Atmega as an input and output the signal to the servo (instead of directly connecting the Atmega and servo). Additionally, on the morning of the demo day, before our assigned time slot, the Halbot platform we used to complete the project began to emit smoke, which forced us to quickly adapt and migrate to a new halbot platform. Luckily, upon rewiring, the project still worked as intended. However, due to the time spent debugging and making the transition onto the new platform, we were forced to refrain from adding certain features we initially wanted to. For example, in our radar, we do not show the position of the detected obstacle on the screen - a feature that we wanted to implement initially. Given the 5-week timeframe to complete the final project, we are happy with the progress made, but there definitely can be some improvements in future iterations.
One thing is that there can be an ultrasonic sensor in the rear to sense the presence of obstacles behind the halbot (in the case where the vehicle is moving in reverse). Currently, the setup would fail to detect such obstacles due to the placement of the ultrasonic sensor in the front of the chassis. Another potential extension is to include cameras in addition to/instead of ultrasonic sensors and use computer vision for object detection. This perhaps would lead to greater accuracy but would increase the complexity of the project significantly.