Intro to Mechatronics (ME210/EE118) Final Project
OUR PROJECT IS A ROBOT DESIGNED TO SPEEDILY AND ACCURATELY DROP BALLS INTO BINS AND ADVANCE TO THE OPPONENT'S SIDE OF THE FIELD.
aboutus
Jeremy Hyde
1st year Master's student at Stanford University in Mechanical Engineering with a focus in product realization.
​
David Mendoza
Junior at Stanford University studying Electrical Engineering with a focus on circuits and devices.
Fabian Badillo
Junior at Stanford University studying Product Design.
Wade Streit
Sophomore at Stanford University studying Electrical Engineering with an emphasis on Signals and Information Systems.
​
​
The Problem
We must build a robot that acts as our "start up company." The goal of the project is to take over the opponent's start up before they can take yours, i.e. your robot must advance to the opponent's startup garage before they claim yours. However, there are gates blocking the routes as can be seen in the diagram below. These gates open when one start up has control over the Funding Round B and either the Patent Office or Funding Round A by pitching buzzwords to VCs. To gain control over a Funding Round or Patent Office, a team's robot must deposit the buzzwords, or balls, in the bins, using their weight to tip it over and gain control of that bin. The arena includes IR beacons and gray tape to indicate the location of the various funding rounds as well as green tape to denote the start up garage.
There are several caveats. The robot must fit inside a cubic foot, be autonomous and use the surrounding environment such as the tape, infrared light beacons, and the walls, to figure out its location. The robot can also only carry 4 buzzwords (balls) at a time and can only be refilled while in its own incubator after pressing the reload button.
To learn how we tackled this problem please keep scrolling.
Fig 1. Layout of the arena being used
The Solution
VIDEO
​
Mechanical Design
Physical Frame
We decided to use three layers of duron in our robot: a base to support the motors, store the batteries and hold the tape sensors; a mid layer to hold the electronics and sandwich the motors, which reduces vibration; and finally a top layer to handle ball dispensing. These layers were supported by 1/4" threaded metal rods in the corners. There was also a caster ball at the front to balance the robot with the wheels in the back. We decide to go with a pentagonal base in order to reduce the likely hood of getting caught on corners when turning (i.e. the triangular front) while also maximizing usable space (i.e. standard rectangular back).
​
​
Fig 2. Laser cut frame and supports for bottom and middle layers
Motor Support ​
Due to the lightweight nature of our robot and size constraints, we decided to forego the standard coupler and bearing system and instead attached the Polulu wheels directly to the Jameco motor shafts. This required us to carefully widen the 4mm center of the wheel to 6mm so that the motor's shaft could fit. We then used the laser cutter to create 2" high supports with varying concentric holes to hold the motor. Screw were also drilled through an additional laser cut duron into the holes on the front of the motor. This prevented the motor from rotating inside the supports as seen in the figure to the right.
​
Fig 3. Laser cut supports to hold motor, and wheel, in place
Ball Dropping
Our initial concept for the ball dropping mechanism was to have a barrel that used the force of gravity to accelerate the ball and drop it into the bucket. We were concerned that this would not give the balls enough speed to clear the wall; but after trial and error we found that only needed approximately a 20 degree angle and a few inches of height to give the balls enough velocity to make it into the bins.
From there we decided we didn't need the barrel and instead redesigned our concept to use the top layer as a "ramp" for the balls. We used a duron gate attached to a servo motor that would open and close at timed intervals allowing either one ball or multiple to pass through depending on the strategy chosen. At first, we only dropped one ball at a time. For the competition, we went with a strategy that dropped two balls at a time into Funding Round A and B. Due to the simplicity of design, this system ended up being very easy to debug.
Fig 4. Our design incorporated the top layer as part of the ramp. Guiding walls kept the balls in line.
Electrical Design
Fig 5. Motor and driver circuit
Fig 6. Circuit required when implementing tape sensors
Fig 7. Circuit connecting the batteries to the rest of the electronics
Motor Electronics
We used two Jameco Brushed DC Motors (161382) and an L293 motor drive breakout board to drive our robot. Each motor's positive lead was connected to the A terminal on the L293 module and the negative lead was connected to the corresponding B terminal (i.e one motor was connected to terminals MOTOR1-A and MOTOR1-B).
On the L293 module, its Enable pins (EX) must be connected to analog PWM pins on the Teensy. This is to use pulse width modulation (PWM) to control the speed at which the motors are driven. The direction pins (DX) can be connected to any of the digital pins on the Teensy. These pins need a LOW signal to drive the motors forward and a HIGH signal to move them in reverse. The Vs pin on the L293 module is the supply voltage of the motor driver, which is 12V since that is the maximum rated voltage for these motors.
​
While testing, we found that if we gave the motors a PWM of below 50%, they would have enough torque to move the robot.
​
​
Tape Sensing​
We used a total of four OBP704WZ reflective object sensors on the bottom of our robot to sense the tape on the course. The sensor consists of a phototransistor and an infrared LED pointed in parallel and separated by a small bit of plastic. The sensor operates by emitting infrared light through the LED, reflecting off the surface of the course, and being absorbed by the phototransistor. We chose a resistor of 51 Ω to put in series with the LED because this will set the current through the LED to a value under the maximum safe value of 40mA. We included a 16 kΩ resistor in series with the phototransistor to generate a signal of about 3.3V when the phototransistor outputs its maximum current, which should occur when the sensor is placed above a white reflective surface.
​
Power Rails
The robot is powered by two Gens Ace 7.2V 3000mAh NiMH rechargeable batteries in series, giving it at least a 14.4V voltage supply. A 12V voltage regulator was required (LM7805C) as the motors' maximum rated voltage is 12V. To power the Teensy, a 5V voltage regulator was used (LM1084). Keep in mind that this is not VCC, which is 3.3V. These voltage regulators transform the variable voltage of the battery to a consistent output voltage, independent of the charge in the batteries. A circuit breaker was also added between the batteries and the voltage regulators to act as an on/off switch.
One issue with this approach is that the 5V voltage regulator gets quite hot, since it regulates >14.4V to 5V by dissipating all the excess power as current to ground. This is not a major concern, since the regulator can take a maximum input voltage of 25V and operate at a maximum temperature of 150 degrees Celsius. However, caution is advised when handling this voltage regulator after use.
​
Fig 8. Circuit for the ball dropping servo
Ball Dropping Mechanism
The robot’s ball dropping mechanism is controlled by a gate operated by a Servo Motor. The Servo Motor is powered by Vcc (3.3V) coming from the Teensy's internal voltage regulator. Its position is controlled by a PWM pin on the Teensy using the built-in Servo.h Teensy library. There is 180 degrees of control in the Servo motor. When the gate is closed, the Servo Motor is placed at a 0 degree angle; when the gate is opened, the Servo Motor is placed at a 45 degree angle.
​
​
Fig 9. The servo motor would raise and lower a thin strip of duron capable of stopping the balls and releasing them in a controlled manner.
Software DEsign
Fig 10. Layout of the location of each of our 4 tape sensors
Fig 11. Starting position of our robot
Fig 12. The code for proportional derivative (PD) control
Tape Sensors
We used two tape sensors on the front of the robot to follow the line using PD control (explained thoroughly in the next section). We had two additional side tape sensors: one to sense the strips of gray tape and one to sense the strip of black tape. Analog readings for these sensors were sampled every 50 microseconds. If the analog value of the side sensor that detects gray tape was below the gray tape threshold (800), the robot would drop a ball into a bin. If the analog value of the side sensor that detects black tape was lower than the black tape threshold (600) then the robot would turn. The ball-depositing mechanism and turning is described later.
We placed the sensors as close to the ground as possible in order to get the most accurate readings. Because these sensors were mostly secured by masking tape, we would sometimes knock them out of place and spend had to spend some time retuning them to their previous state. We eventually built small duron casings for the sensors handling PD control to stabilize them.
​
PD Control
For our line following tape sensors in the front, we used Proportional-Derivative control to accurately follow the line. This was implemented by taking the difference between the right and left sensors and using that as a proportional error. This error was stored and used in the next iteration to calculate the derivative error. Then we calculated a correction term by multiplying the proportional error by a proportional gain and the derivative error by a derivative gain (these constants in our code were 0.069 and .001, respectively) and adding the two terms together.
Lastly, the motors were both fed a nominal duty cycle (80%), but the correction term decreased one motor's duty cycle while it increased the other motor's duty cycle.
​
Fig 13. Pseudocode for ball depositing
Ball Depositing
Once gray tape was sensed, the servo motor would react by switching to a 45 degree angle. This caused the gate to open and allowed a ball to roll down the top of the robot and into a bin. The sensing of gray tape would also start a timer. At the timer's expiration, the gate closes. This approach required several tests to find the exact time period that would only deposit one ball consistently. After some testing, we found that 150 ms accomplished this task reliably. However, after we found this value getting the time was a simple matter of multiplying the number of balls we wished to release by 150 ms.
​
Fig 14. Diagram showing the two methods for turning attempted a. right motor acting as break (PWM = 0) b. right motor reversing (PWM = 80)
Turning
In order to move through the gate, our robot must be able to make a 90 degree turn when it senses black tape. Once turning, it will continue to do so until the right PD tape sensor has past over a new black line AND the left PD tape sensor has just begun sensing it (indicating that we are now on the right path). At this point, PD control will take over once again and direct our robot to the start up garage. This turned (pardon the pun) into one of the rougher parts of our development process.
We initially began by lowering the PWM values to minimize the turning radius, but found that the motors were not strong enough to be able to turn at PWM values under 50% duty cycle. We then tried keeping the right wheel static while varying the left wheel’s PWM value, but the turning radius proved to be too large and we would keep getting stuck on the wall. Eventually, we ended up reversing the right motor while moving forward with the left, this allowed our robot to spin on its center of rotation and stay well away from the walls.
After tuning both wheels’ PWM to a 80% duty cycle with the left turning forward and the right turning backward, we decided to move the side tape sensor closer to the front so the robot could react earlier and it worked perfectly, turning on it’s center of rotation.
Finite State Machine
The robot followed a linear finite state machine. Essentially, it moved forward using PD control until black tape was sensed. Every time gray tape was sensed, it would deposit a ball into a bin. When black tape was sensed, it would turn until it was reoriented on the new black line, and then move forward as before until it encountered black tape once again. It has thus reach the opponents start up garage and so will stop.
Fig 15. Main code loop representing our state machine for the competition
Fig 16. Finite State Machine
Full CODE
THE COMPETITION
First Match (VICTORY)
*Technically, the gate should have opened and allowed our robot to advance to the oponent's startup garage. This is because we deposited two buzzwords (balls) in Funding Round B, while the other team only deposited one buzzword in that Funding Round. However, the weight of two balls is not enough to fully tip the Funding Round against the weight of one ball, so the gate did not open.
Second Match (Defeat)
Cost breakdown
Most of our electronic components came from the ME 210 lab stock room. Laser cut components were done using sheets of 0.2 in Duron sheets purchased from the Stanford Product Realization Lab, Room 36.
​
Other important things that can be seen from this are the fact that we ended up using 4 tape sensors. Also due to the large size of the Jameco motors we used there is a distinct lack of bearings and couplers in our parts list.
Finally the Polulu wheels we used did have to be modified in the PRL to allow for the 6 mm shaft from the Jameco motor.
Reflections
"This project was a lot of fun, but really showed me how different components fit in together to make an overall product. The added bonus of learning from my peers and teammates about topics I was previously unfamiliar with made this a very rewarding experience."
​
- Fabian
​
"I really enjoyed the system integration and debugging of this system. It was interesting having to look for errors in the electronic, mechanical and software parts and how one is able to solve an issue in one system by modifying a part in a different section."
​
- Jeremy
​
"This is definitely the best class I've taken at Stanford. It is one of the few classes in which the material learned in class is used to actually build something physical. My expertise is mostly in electronics and software, but I learned a lot about mechanical design and troubleshooting a large system. My favorite part was combining electronics, software, and mechanical design into one system."
​
-David
​
“Personally I found this experience to be quite eye-opening because we start almost from scratch on something close to a figment of our imaginations and we continually work on it and mature it to the extent that it functions as you originally imagined it to. In most other classes you are either assigned to work on something at a low level of operation or something at a high level of operation and asked to follow a series of small tasks and leave it like it almost never happened. This robot was whole other story. You got to see it out through at all the stages just as you would see in industry, which can be pretty rare in an academic setting.”
-Wade