Fully autonomous tape following robot

View the Project on GitHub billyfung/gadget-the-tape-follower


As part of the ENPH 253 course, Introduction to Instrument design at UBC, I was part of an team that created an autonomous tape following robot car. The course is taken in the summer of 2nd year to introduce young engineers to the various aspects of instrument design, from mechanical to electrical to software. The content of the class always remains the same, but the end final project changes from year to year. For my year it was chosen that we build an autonomous robot to race around a track. The common theme throughout all the final projects is that the robots must be autonomous. My team included Russell Vanderhout, Adrien Emery, and Daniel Lu


The first aspect of the robot is the chassis. Learning how to design for waterjet cutting in Solidworks was the first step in creating the outershell for the robot. Made from sheet metal, the unibody chassis is designed in Solidworks then folded into place. Many other teams opted to design several different parts and then screw them together, or weld them together. The major skill learned is to design something quickly to see where the problems lie. Our chassis design ran through 6 iterations before we finally figured out what worked and what didn't. There was not enough time to model out every component to see what would fit into the chassis, so it was much quicker to design and then put parts in to see what worked. For the final chassis, we powder coated the metal red.

For our drivetrain, we chose to use two electric motors mated to a 13-tooth sprocket driving a differential gear via timing belt. This drivetrain design was done by Daniel, who is quite the car enthusiast. The gearing for the differential was laser cut out of acrylic. This was our first foray into mechanical gears and design, and it was a success although we did not come back into this topic until upper year mechanical design classes. The steering design was chosen to be done using a servo motor linked to the front wheels via gauge steel. We were taught about the Ackermann steering geometry and it was implemented in our steering. An important note is that the performence of the servo motor greatly affected the performance of the steering; a faster servo meant faster steering.

Another piece of engineering fun were the wheels designed by Daniel. Instead of using standard steels off the shelf, he decided to design both the wheels and tires for the robot. The wheels were laser cut from polycarbonate and the tires were cut from rubber. The wheels were inspired by the Lamborghini Countach five porthole design, and the tires were made to be similar to the Michelin Tweel to improve ground contact.


In order to detect the black tape on the white track surface, the sensors we chose to use were QRD1114 sensors. The analog sensors use diodes to detect emitted infrared reflections. Using these sensors we are able to "scan" the ground to follow the black tape. An array of 8 QRD sensors in order to gain a higher resolution of the black tape, and the signal is then fed into a comparator circuit to set the threshold value. Using 8 QRD sensors allows for easier software programming to smoothly steer along the black tape. All the electrical circuits stem back to the main TINAH board we used, which has an ATMega 128 as the processor.

Since the race track will feature obstacles and another robot, there is the chance that two cars might run into each other in the same lane. To prevent this, we chose to use an IR rangefinder to detect obstacles infront of Gadget. This circuit is very straightforward and consisted of the analog rangefinder and a comparator circuit to set the threshold via a potentiometer. Another option would have been to use software to set the threshold but we did not chose that route. Using a rangefinder, we can then receive a HIGH or LOW signal depending on if there is an obstacle at a certain distance away from the front of the car. In order to filter out extraneous signals, we ran the rangefinder signal through a low pass filter first. And to furthur reduce noise, we built an enclosure around the rangerfinder to block off signals from above, and to focus the IR forward.


The code that makes Gadget run is written in the Wiring programming language for the custom TINAH board. The TINAH board is very similar to the more well known Arduino systems. In order to follow the tape accurately without constantly overshooting, the tape following algorithm consisted of two simple states.

As more tape is sensed by the QRD, the reference sensor is shifted and the task repeated until both sensors detect the tape. The threshold value is set such that two sensors detecting tape results in straight motion. If nothing is detected in the two sensors, it shifts back to using 8 sensors.

For each iteration of the QRD scan, an instruction is sent to the steering servo motor. Using a lookup table, we devised 15 angles at which the sensor readings corresponded to the sensor array. This is essentially using proportional control for the steering based off the QRD sensors.

The lane changing aspect of the software consisted of tracking which lane Gadget is in, and then executing a lane changing algorithm when needed. The steering algorithm consists of setting the servo motor to steer at a certain angle, waiting for all 8 sensors to detect no tape, then steer straight until the sensor farthest away from the lane-to-be-changed-into tape is detecting the tape. This allows for an overshoot before smoothly going back into the tape following algorithm

In order to control the power of the motor, we had the PWM duty cycle be around 70% in order to not go too fast. Sadly we were not able to optimize our robot to go fast and perform reliability until the time constraints we had. Often going at 100% would result in our steering mechanism not being able to respond fast enough to the course, and ended up oscillation around the tape. Another consideration was to slow down the motor around steeper corners in order to prevent skidding out. If the angle of steering exceeds a certain threshold then the robot slows down into the corner before accelerating again.


After reading about everything we did and learned through this project we have to sadly say that we didn't win the racing competition. To our dismay, our controlled testing track was our downfall. At the competition, the environment was such that there were many people taking pictures and filming the race. We did not think about this when choosing to use an IR rangefinder to detect obstacles, so every camera autofocus on the robot caused the rangerfinder to trigger the turning mechanism. This choice in easier and quicker sensor implementation was obviously not the right one. Although after the competition, we placed our robot on the track and let it run continuously without problem. The entire ordeal was a great learning experience