Projects

- Spotter and Artillery Robots
- Smart Bike
- KNIGHTmare
- Switchback
- Nimbus 3481
- El Toro
- Sky Shot
Spotter and Artillery Robots
My 6.01 (Intro to EECS via Robotics) final project was two robots that worked together to hit a human target with a laser pointer. The objectives were to use a probability model with a heat sensor to find a human target, design a wireless infrared light communication circuit, and program a proportional controller to aim a laser pointer at the target.
Spotter - Target Acquisition
The spotter robot was in charge of detecting the human target and relaying the targets position to the artillery robot wirelessly. The robot used an Adafruit thermal sensor which output a matrix of scalar thermal values representing the thermal readings for its frame of view. The robot collected thermal data until it built a high enough confidence in its probability model to relay the target's position to the artillery robot.
Spotter - Transmitter
The spotter mapped the thermal matrix values to an angle offset from zero which described the target's location. The robot then translated that angle into a binary message sequency including a starting and ending sequence to notify the artillery robot of an incomming message and end of message, respectively. The binary sequence was transmitted a series of flashes from an IR LED toward the artillery robot.
Artillery - Receiver
The artillery robot was in charge of receiving a firing command from the spotter robot and firing a laser pointer at the target accurately. The robot did so by listening for a IR flash sequence from the spotter robot using an IR remote sensor.
Artillery - Firing Sequence
As soon as the artillery robot detected the a message starting sequence, it reorded a binary value until it detected the end sequence. It then converted the binary number into an angle offset from zero and used a proportional controller to turn to the desired target angle and fire the laser.
Smart Bike
For my 6.A01 seminar, each student had to build their own project that involved at least two of the following: micro controllers, 3D printing, and lasercutting. My project was to build a smart bike, a device that you can strap onto a bycycle that will be able to give you sensor feedback on your speed, acceleration, compass heading, and GPS location. The bike also featured rear brake lights that turn on when you squeeze the rear brake and headlights in the front.
BOM and Budget
We were each given $250 for our projects. Here is how I broke down my costs.
Testing Harness
The first step was to build a testing harness for all of the electronics and sensors that I wanted to incorporate into the module. I accomplished this by wiring all of my sensors up to a breadboard and programming the arduino controller.
Custom PCB Board
The next step was to figure out how to get all of these sensos and electronics wired together in as compact a space as possible. My solution was to cut out a custom PCB board on an Othermill machine. This PCB board would act as an arduino shield and interface between the sensors and the controller.
Fritzing Sketch
I used a software called Fritzing to design the PCB board. Fritzing allows you to import different electronics componenets such as an arduino controller, sensor module, or resistor. You start out by laying out the parts on a breadboard, then you can creat a 2D electrical diagram, and finally, it helps you create traces for your PCB board.
Electronics
I ended up pulling two allnighters assembling this module. I the Othermill PCB proved to be very hard to work with, because the copper tended to lift off of the chip in certain places, and I ended up having to take the whole thing apart due to an unknown problem. It turned out that the problem was a hairline crake that has formed in one of the traces that I ended up needing to solder over. The process was incredibly frustrating but the result was rather elegant.
KNIGHTmare
KNIGHTmare is the robot that my FIRST Robotics Competition team built for the 2016 season, FIRST Stronghold. I am especially proud of this robot because it brouhg us our best season ever, and I was one of the leaders for the design and mechanical team as well as the robot driver. The subsystems that I was in charge of included the drivetrain, shooter, and control system panels. All of these subsystems are listed below along with some that I was not in charge of but are still worth mentioning.
Strategy
In order to figure out what we wanted our robot to do, we needed to come up with a strategy that would make us competitive in competition. THe game challenge presented various methods of scoring which would increase in difficulty at different levels of competition. THerefore, we had to not only plan out a competative strategy for regional level competition, but for the World Championships as well. We knew that we wanted to be a strong shooter, and we wanted to be able to cross as many defenses as possible. The major remaining question was whether or not to pursue a design that could fit under the low bar defense.
Design
We put together a list of needs, wants, and dreams for capailities of our robot. The needs included a robust tank drive and an accurate shooter, the wants included camera-based goal targeting for autonomous and a climber, and the dream was to be able to fit under the low bar. We spent a good portion of our time tryting to figure out how to package our shooter and drivetrain under fifteen inches in height, and we began to refer to this design as the The Dream. But after much debate, we decided that it would be too difficult and a poor use of our time to build a small robot. Instead we decided to build a tall high-goal shooter that could shoot over defensive robots. The Dream was dead, and the KNIGHTmare was born.
Drivetrain
We soon realized that this was going to be the roughest game on the robots. Each robot had to ram themselves over ridiculous obsticals in order score points and maneuver the field. This meant that I had to design a drivetrain to withstand a lot of impact, be light enough and versatile enough to zip around the field, and be strong enough to push past defenders. I began by building a prototype testing chassis with which we tested a variety of wheel sizes and spacing. I then ran several tests by driving this chassis over the defense obstacles to ensure that the robot could successfully cross all of the terrains and never get high-centered or stuck. I then settled on an 8 wheel tankdrive with 8" diameter pneumatic rubber wheels. The design later changed to 6 wheels when we added a climber and had to stay under the weight limit.
Intake and Indexer
The first step to scoring a ball is getting control over it. We were able to achieve this with our intake and indexer mechanisms. The intake was designed to grab the ball from any position on the front bumpers by using vectored intake wheels (aka mechanum wheels) to pull the ball toward the center of the robot. As soon as the ball is in the robot, it is pulled up the indexer until it rolls over a pressure sensor. The ball sists in this position until ready to shoot. By using this indexing system, we ensure a consistent feed into the shooter at all times, reducing the number of variables in the shooting system.
Shooter
One of the defining features of KNIGHTmare was its shooter. Our main game strategy was to maximize high-goal shots but have the flexability to shoot from farther ranges. To do this, I needed to design our shooter to be powerful, accurate, and versatile. With the help from a few other team members, I put together a shooter prototype which we mounted to one of the existing tower modules. I tested a variety of shooting angles and wheel diameters. The result was a flywheel shooter with two 5" diameter colson wheels powered by two 775 Pro motors, each with a 4:1 VersaPlanetary gearbox. Our main shooting strategy was to shoot straight up from the tower wall in order to increase our consistency and decrease the effect of defense. We also wanted the shooter to be able to shoot from midfield for autonomous, so I built an articulating hood which can varry our shot angle between two shooting positions.
Climber
Our climber is the result of much iteration over the course of the competition season. After testing out the climber on our practice robot at the shop between competition, we installed it onto our competition robot at the World Championship. Our climber accomplished the impressive feat of hoisting our 140 lb robot up the castle wall in three seconds using only one 775 Pro motor.
Control System Panels
One of the defining features of our team's designs is the modularity of subsystems. This is a design strategy that I implemented the previous year in order to streamline the integration subsystem designs between multiple designers and make it esier to aply changes and modifications by isolating the subsystem from the rest of the robot. I designed our control system to be modular so that we could remove it from the robot to do electrical work while the mechanical team made repairs and modifications on the robot. These panels featured all of our electronics components and pneumatic gauges and regulators in a presentable and user-friendly fashion.
Awards
This season was the most successful one yet. We ended the season with two Motorola Quality Awards, a Delphi Excellence in Engineering Awards, two silver medals, semifinalists in our division at World Championships, and an invitation to the prestigious Indiana Robotics Invitational competition in July. In one year we took home more awards than during all of our previous years combined. It was not only a very successfl season, but a very fun and memorable one, too.
Nimbus 3481
This robot was designed as an entry for the 2015 Summer Design Competition organized by a group of FIRST enthusiasts and promoted through the Chief Delphi portal. The objective of this competition was to design a robot in CAD software to play an FRC-style game. My team saw this competition as an opportunity to practice brainstorming, designing, and using CAD. This project started off as a team effort, so our strategy and general design decisions were team decisions. However, most of the group members couldn't do their part of the CAD due to other commitments, so I ended up designing everything.
Drivetrain
The drivetrain was the first subsystem that I designed for Nimbus 3481. This drivetrain is an 8-wheel drive with two 3-CIM 4-speed gearboxes. The wheels are all 4 inch Colcon wheels, and the drivetrain has a 1/8" drop center on the inner wheels. This drivetrain also features springloaded chain tensioners to ensure that no chains are ever thrown an all wheels are responsive without lag.
Three-CIM Four-Speed Gearbox
The gearboxes for the drivetrain were probably the funnest and hardest things to design for this robot. The most unique feature of this gearbox is that it has four different speeds. Now, this would be rediculously unecessary in an actual FRC robot, but beacuse this robot is not actually being build, I decided to do it for fun. THe four adjusted speeds are 17.00fps, 12.71fps, 7.36fps, and 5.51fps. We wanted our robot to be able to book it across the field so that we could catch the goldn snitch but also have enough pushing torque to win pushing matches, and we also wanted middle ground speed to play the majority of the game in. The gear box uses two pneumatic pancake cylinders to engage the ball shifter. The gearbox also features a Grayhill encoder for programming autonomous and driving straight.
Tower/Indexer
The tower is the main superstructure of the robot, and it contains the part of the robot that feeds the shooter: the indexer. The indexer is far from perfect. In fact, this was the part of the robot that I spent the least amount of time on, and it shows. If you were to look closely at how the pulleys are belted to the motor, you would notice that if you were to try to spin this up, th sides would be moving opposite each other, and the ball would have a really hard time getting to the top. I admittedly rushed this part, so I didn't notice the error until it was too late. I am also very disatisfied with the pulley system. I think it is kind of janky, not at all robust, and had lots of room for improvment. The indexer was inspired by indexers from 118's 2012 robot, Endeavor, and Robowrangler's 2012 robot, Armadillo. That being said, I think the orange polycarbonate panels add cool aesthetics to the design.
Shooter
This shooter is another one of my favorite parts of the robot. I really liked putting the horse head design on the sides. This shooter was full 360 degree rotation via a lazy susan, adustable hood for a variable shooting angle, PID loop controlled shooter speed with a Grayhill encoder, and camera vision capable of targeting the goal and determining the optimal shooter speed and hood angle. All of this would hopefully be made possible by a great programming team, which exsist in the world of FRC but are about as rare as unicorns. The following are statistics on the shooter:
max shooter speed: 2511rpm
max ball speed: 43.83fps / 29.88mph
shooter angle range: 0deg - 45deg
full court shot runs at max speed and a 29.5deg angle
turret has a full 360deg of rotation
El Toro
El Toro is the robot that my FIRST Robotics Competition team built for the 2015 season, Recycle Rush. The main objective for this robot was to build stack of plastic totes, move them onto a scoring platform, and place a large, plastic trash can on top of the stack. This was the first robot for which I was a mechanical and design lead. The systems that I designed for this robot include the drivetrain and the control system panels.
Drivetrain
Because this year's game did not involve any contact with opposing robots, we didn't have to consider pushing opposing robots when designing our drivetrain. Instead, our team decided to maximize our mobility on the field. Because we would be carrying a stake of totes on the end of an arm on mounted on the rear of the robot, I designed the drivetrain to be long in order to balance the conter of gravity which would move to the front everytime we picked up a stack of totes. I also designed the drivetrain to use omniwheels so that we could strafe around the field and maximize our mobility.
Control System Panel
In previous years, my team would mount our control panel directly to the robot frame, and the components would often be hard to reach if we ever had to change out any components. Additionally, if the electrical or software team ever needed to work with the control system, they would have to take over the whole robot to do their work which would set back the mechanical team. I solved this problem when I designed our control system to mount to a polycarbonate panel in the rear of the robot. I designed the panel to be easily removable so that our electrical and software teams could work with it while the mechanical team worked on the rest of the robot. I also deisnged in expandability by adding extra pneumatic regulator and motor controllers which could easily be utilized if we ever wanted to add a new subsystem later on in the season.