Introduction
Attempting to create and code a robot that can play zombie tag is an incredibly difficult task to implement. Understanding the rules is quite simple, however incorporating those rules into a robot to behave with its own intelligence can create a multitude of problems. To tackle this problem we first identified the rules of the game. Initially, your robot starts out as healthy, if it is tagged by another zombie it then becomes one itself. To heal robots as healthy you also must pick up a ball then you enter the healing state. A camera is positioned above the board to inform of us not only our position but the position of other robots and any balls on the board. When a zombie state is entered the camera cannot be accessed. Many unique problems must be addressed in order to accurately understand the approach:
- How will the robot microcontroller communicate with each component?
- How will we take radio commands and turn those into artificial intelligence?
- How will we capture a ball?
- How will our state machine behave so we understand which state we are currently in?
- How will we turn around when hitting a wall?
- How will we move the zombie around when having zero access to the camera?
State Machine
Below is our main logic state machine in order to replicate the code within Arduino best. Most of the code snippets are not included for ease of reading but can be sent if requested. Below is the state machine we implemented to tackle this task.
Figure 5: Image of the state diagram that was used to implement the state machine that the robot used to effectively play the game. This diagram outlines how the robot switches between states based on radio information and sensor input. The diagram shows the “Healthy” states in red, the “Zombie” states in blue, and the “Healer” state in green. These colors match the colors displayed by the overhead camera.
Wiring Diagram
The next important aspect to consider is the wiring of the robot. The actual wiring can be quite complex, however, going through the process allows us to create a wiring diagram that is easy to read and understand.
Figure 6: Image of the wiring diagram for all of the components connected to the uc32 ChipKit board. Due to the diagram being made in a computer program, many components in the diagram are merely representative and do not look like their actual alternatives. This diagram shows exactly how each component is connected to the chipKit on the actual robot.
Sensor Calibration
One component of this project that was initially an aspect that was not considered was the idea of calibrating sensors. The sensors that required calibration were the dc motor responsible for moving sweeping the IR sensor and the IR sensor itself. Limit switches and servo motors were also in need of calibration. Below a relatively simple calibration was performed for the IR sensor. In order to understand the inputs we receive from that sensor, it is important to know the first inputs are analog inputs that are of no use to us. Below is a graph replicating how we achieved a calibration from the sensor to a usable distance.
Figure 10: Plot of the true distance, in cm, over the analog output from the IR distance sensor. This plot was generated from a calibration process where the analog output was recorded when a movable wall was set to a known distance in front of the sensor. A calibration equation was created from this by using a power function trendline. This equation has an R2 value of 0.99, meaning that this trendline is a very good fit for the data.
Our Performance and Conclusion
This experiment was conducted as a competition between other groups. Through our process of converting the sensors into real and usable data, we determined how we can create incredibly reliable data and results. We also spent a great deal of time on our logic to ensure that whatever state we are currently in is the one that we want to be in. Ensuring that each aspect of the robot was perfectly matched for its intention led to us performing well in the competition.