Autonomous Game-Playing Robot

For my mechatronics class, our final project was to create a robot that played against another robot in a game that resembled the U.S. presidential election. The game playing field was a 8ft x 8ft square with map of the U.S. in the center. The country was divided into 9 separate sections, each containing a city designated as a "polling station" for citizens to vote. Each robot was assigned either red or blue team at the start of the game, and whoever "captured" more polling stations won the game. A polling station was captured by reading the frequency of a oscillating magnetic field underneath each polling station emitted by a 2" coil, and then reporting that frequency wirelessly to the game board. This requires the robot to autonomously navigate to a precise location on a map to capture a polling station. 

Navigation

This was a team project with 3 other team members. My main role was building the software and hardware for the robot's navigation. There were 3 different methods that we considered for our navigation.

The first 2 involved using the "campaign trail" which is given on the board. The campaign trail was a loop that goes through all 9 polling stations, and it was marked by black tape and a wire inducing a magnetic field. A robot could either follow the black tape using an optical sensor, or follow the wire using a hall-effect sensor. A hall-effect sensor would be better-suited for navigation, since it is easy to retrieve an analog signal that could be fed into a controller algorithm. The benefits of following the campaign trail is that, once the robot is on the trail, it is easy to reliably locate the polling stations. The downside is that it would be lost without sight of the trail, and getting onto the trail may be difficult.

The other navigation method uses IR beacons that are located at the 4 corners of the board, each pulsing at unique, known frequencies. By detecting the relative angles in which the robot "sees" the beacons, the robot can triangulate to find its absolute position on the board. The benefits of this method is that as long as it can see the beacons, it will not get lost. However, the downside is that it would need to be precise enough to navigate itself onto a polling station, which is only 2" diameter.

In order to gauge the precision of the triangulation method, I created a simulation that showed the range of possible robot positions, given a maximum angle error and a predicted location. The problem is that the assignment documentation was not clear, so we had thought that the polling stations were 6" in diameter instead of 2" in diameter. The simulation showed that the robot had to measure the angles between the beacons with a plus-minus 1 degree accuracy in order to obtain a 3" resolution. Although this was not easy, it seemed possible if we averaged the data from several readings.

We decided to go with using triangulation to navigate around the board. Although precision was required, it seemed like it would lead to more interesting strategy later down the line, since we would not have to follow the campaign trail. Had we known that the polling stations were much smaller than we thought, we may have gone with the line-following options.

Hardware

The hardware for the navigation has 2 parts: the mechanical hardware and the electrical hardware.

I decided to make the mechanical design like a periscope of a submarine. I wanted to continuously rotate a IR sensor using a DC motor at about 200 RPM, and have some sort of encoder to track the angular position of the signal. The wires to the sensor went through a slip-ring so that the cables did not get tangled.

We used two sensors to find the angular position of the periscope. The main sensor was an encoder mounted on the DC motor, before the gearbox. This did a good job of keeping track of small angular increments, but there needed to be another way to calibrate the angle of the periscope relative to the robot. In addition, the encoder drifted about 1%, and that would be a large angular error if we let it accumulate for many rotations. Therefore, there is also a IR interrupt sensor that was triggered once every rotation to home the angular position.

The most difficult part about the electronics was creating a large range of distances in which the IR pulses could be detected. The IR pulses were first detected by a phototransistor, and then the signal was amplified. The signal was then passed through a high-pass filter to remove the DC offset caused by ambient light, and then passed through a second stage amplifier. Finally, the analog signal was converted into a digital signal using a Schmitt trigger and inputted into the microcontroller.

Software

The software can be divided up into 2 functions: finding the angles between the IR beacons, and calculating the current position of the robot based on those angles.

When the phototransistor detected IR pulses form the beacon, the microcontroller calculated the frequency of the pulses to figure out which beacon the pulses are coming from. At the same time, the microcontroller kept track of the angles at which the IR sensor started and stopped detecting the pulses. It determined that the midpoint of these two angles is the actual angle of the beacon. As the periscope rotated, it kept track of its angular position using the encoder mounted onto the motor, and also the IR interrupt sensor. Because the timing of these operations was critical, we used interrupts to respond to the signal from the phototransistor and encoder.

We initially thought that once we have the angular position of the beacons, calculating the position of the robot should be pretty straight-forward with some geometry. However, we soon realized that using only geometry left us with 2 non-linear equations and 2 unknowns (x, y coordinates), which is certainly solvable but probably not something that could be easily done on a microcontroller in real-time. Therefore I searched the literature, and it turned out that there were many algorithms to triangulate positions between beacons to find a robot's position. We used to ToTal algorithm by Pierrot and Droogenbroeck because there was great documentation, and benchmarks showed good performance.

Aside from the navigation, I was also involved in writing PID controllers to make the robot use its wheels to rotate and drive straight and stop at desired points. I created a queue so that a sequence of actions (rotate, go straight, wait, etc) could be assigned, and the robot would fetch more actions once it has completed all of the actions in the queue. That simplified our programming a lot, since we did not have to hard-code every possible transition in a sequence of actions.

Setbacks

Our team decided to re-build the robot chassis to accommodate a foam-ball shooter, only 3 days before the project due date. However, the design time, rebuilding time, and testing time was severely underestimated by one of our teammates who was lagging behind, which set us back by a large amount. We trusted his abilities so we let him work independently, but we should have been checking his progress more frequently to support him as a team. The fact that the design was rushed and not well-thought-out lead to more troubleshooting, such as wire connections becoming undone. The fatigue and the lack of sleep leading up to this event also made things worse. Because of this, we were not able to complete the assignment on time, though we did eventually finish it. For me, this was a great lesson that one person could ruin it for the team, and we need to constantly check in with each other to make sure that one person's oversight does not compromise the progress of the project.

Results

In the end, we were able to accomplish the requirements for the assignment, which was to capture the polling station of 5 cities and make a foam ball into the bucket without an opponent robot.