WALL-E

Overview

We will create a robot car that can lead and warn a blind person about incoming obstacles. Once an obstacle has been detected the robot will send some form of message to the leadee such as making a noise through speakers. The robot will use micro processor, motors and sensors to determine the position of an incoming object on its way and then accordingly adjust direction in order to avoid a crash. Our motivation for this project is to learn about some of the applications of autonomous cars and to build off a previous groups project Leap Controlled RC Car which can be found here (Link) Also, here are some of the resources we are drawing from to create this project (link), (link) The main improvements we will be making on these projects is to give them the application of leading a person. This means the robot will need new programmable code in order to execute it's leading task.

Team Members

Daniel Sullivan, Novi Wang, Andrew O'Sullivan (TA)

Leap Controlled RC Car (Link)

This project is a continuation of the project Leap Controlled RC Car. This project will use some of the results and ideas found by Andrew O'Sullivan and David D’Agrosa. Specifically, we will be using the same concepts of controlling a small electric car with an Arduino Uno and a motor shield. Our project won't be remotely controlled, but sketches such as turning the motors will be similar with motor shield's: here is a source to access their code under the RC folder(Link) which we will be using to familiarize ourselves with programming in Arduino.

Objectives

A successful project will at the end be an autonomous vehicle alerting a person when an obstacle is encountered and helping the person avoid the obstacle. This means the distance sensor is clearly sending information back to the Arduino to detect obstacles while also staying in front of the follower. The motor shield is connected and working with the driver codes to be written. The robot is sending sound signals when there is an obstacle ahead. Through an IMU sensor, the robot will maintain a straight path forward. When an obstacle is encountered, it will shift by a constant angle either left or right, go a determined length forward and straighten out. The car will alert via speakers, one beep or two for directions left or right. The follower should only need to take one step to the left or right. The front sensors detect the position of obstacles and decide to turn left or turn right. The back sensors detect the distance from the person. And when the person is far away from the vehicle, the vehicle stops and turn back until the person is in expected distance interval. At the end of the semester we will demonstrate our project by putting the vehicle on the ground, blindfold a project member and have the robot lead the member forward while avoiding obstacles.

Challenges

Some of the beginning design challenges are building, connecting and sorting all the electronics together, learning how to program in Arduino and how to communicate between the robot synchronizing all the distance sensors to work together via I2C between two Arduinos and a MPU-6050 Accelerometer + Gyro . We will spend extra time on exploring how to program in Arduino by looking at tutorials. The main challenges will be getting the robot to move forward in a straight line and adjusting through slight turns when necessary, getting the car to turn an accurate angles forward, and making sure the robot stays ahead of the follower a constant distance: reversing when the person is too far away and stopping when too far ahead. All of these main challenges will be solved through coding in the Arduino, based on conditions and data gathered from the distance sensors and gyroscope.

For privacy considerations we will make sure to constantly monitor the robot to make sure the robot doesn't go into any rooms unattended. For user safety, along with carefully watching the robot to make sure it doesn't crash we will also add bright caution tape to make sure no one steps on it.To keep the operation cost below 150 dollars the robot will be kept small. This robot is electric and leaves a small carbon footprint.

Budget

• Arduino Motor Shield R3, for $24.97 at Amazon (Link)
  • Motor shield will control the two motors on the robot. (Spec sheet)

• 7 sensors: HC-SR04, for $5.00 each at Amazon for a total of $35.00. (Link)
  • The sensor will measure distance between the robot and objects. (Spec sheet)

• Piezo Electronic Buzzer for $5.30 [ https://www.amazon.com/gp/product/B013TEI05A/ref=pd_sbs_328_2?ie=UTF8&psc=1&refRID=W6DJKPDN7XVG8P5T48VZ (Link)]
  • alarm to turn left or right (Guide)

• Batteries, for 9.98 (Link)
  • Battery is used to power the shields and arduino

• Magician Chassis, for $29.95 at Amazon. (Link)
  • The car's chassis, motors and battery pack. (Spec sheet)

• MPU-6050 Accelerometer + Gyro supplied by class
  • gyroscope to determine angles to make sure the car goes forward in a straight line and turns a constant angle (Guide)

Total Budget: $123.4

Gantt Chart

Design and Solutions

Hardware

• Car Design

At the very beginning of this project we decided to go with a vehicle kit which provided a pre-built chassis and motors so as to save time 3D printing and assembling motors. The chassis held up well for the most part and was a wise decision, a few modifications were needed such as adding to the height of the structure and moving around the battery placement. There were some spacing issues, but with some wire management we were able to at least protect the wires for the lower Arduino, overall the chassis worked well for us. However, the motors were a disappointment as they were not in sync with each other at all as one motor was significantly faster than the other. The addition of the IMU and a short control algorithm in Arduino provided a fix for this, spinning the slower wheel faster when the car angled off track. However, if we were to do it again more planning should go into researching and selecting quality motors, as this would have lead to focusing more time on the coding sections of the project instead of design issues.

• IMU

The IMU provided the means to make the car turn accurately and stay on course, both actions being vital to the project to even be considered a success at all. The IMU was the largest time sink of the project though. Large portions of time were spent researching the documentation, the Arduino library, examples Ivensense provided and the datasheet in order to extract meaningful data from the sensor. At first the plan was to use interrupts and the digital motion processor, however this proved to be too problematic. Instead, the solution was to have the Arduino handle calibrating and turning the analog values from the IMU to useful angles in degrees. A very useful resource to learn how to do this was gained from this example of leveling a quad copter(Put LINK here!!!). After obtaining the angles, we realized the yaw angle was drifting while the car wasn't even moving. This was partially solved by adding a simple least squares filter, to solve drift for more extensive periods of time a more permanent solution must be used.

• Distance Sensors

A total of 6 distance sensors were used, an array of three in the back and three in the front. Each distance sensors requires four pins, two can go to a bus of ground and power but at least two pins(trig and echo) must wire directly into the Arduino, for a total of 12 general purpose pins required. The Arduino shield only has a total of 14 pins though, with 6 of them required to be used by the motor shield which must use all the PWM pins. We realized there wasn't enough space on one regular ArduinoUno for this project. Possible fixes included multiplexing(difficult and error prone), using an Arduino mega(expensive) or using two Arduinos communicating via I2C. Our solution was to use two Arduinos where one slave holds all the distance sensors and the other controls the motors. The distance sensors themselves experience noise, the solution was to add a short time delay of .5 microseconds between each individual firing ping from the sensors, however this was not implemented in time for the presentation of the project.

• 3D printing casing for distance sensors

Communication

To have enough inputs for this project, two Arduinos talking over I2C had to be used. Initially, errors were springing up between using interrupts and communicating over I2C at the same time. Conveniently this was solved by calculating the data from the IMU on the main Arduino. To talk over I2C using Arduinos, we used the Wire library(PUT LINK IN). The first error we ran into was sending integers over I2C, as you can only send one byte at a time. A simple solution is to shift the lower bytes out by using bit operators, send the higher and lower bytes over one at a time and then recombine them together on the other Arduino. Another problem that arose was timing the IMU and slave Arduino to talk to the main Arduino at reasonable times, as only one piece of hardware can talk at a time. The solution was much easier when the main Arduino took a larger role on handling data, so the timing of the slave Arduino is set to finish before the IMU is called to talk.