Wireless "Battle Bot"
Introduction
This project was completed as part of a graduate level course entitled Design of Mechatronic Systems. The goal was to create a small, wirelessly controlled robot capable of completing a number of different tasks to compete in a “League of Legends Style” competition. The class was broken up into twenty-four teams of three or four people and each team created a robot. Then, six “meta-teams” were formed, each composed of four robots. Meta-teams competed against each other in the final tournament.
As a team, we did all programming, circuit design and fabrication, and mechanical design and fabrication as well as game strategy analysis. This page will explain all aspects of this. Click here to skip this and read the results.
The Game
Each team was composed of four robots and one home base, called a “nexus”. Each of these components had a health level, which was kept track of by the overall game system and broadcast to each robot via wifi UDP. The goal of the game was to deplete the enemy nexus health to zero. When a robot’s health dropped to zero, it was temporarily removed from the game for a certain amount of time, which increased as the game progressed.
In order to cause damage, each robot was able to have actuated “sword" arms. When a robot hit an opponent with its sword arm, it must then turn on a hit indicator light, to signal a judge to apply damage to the opponent robot. Damage done and “cool down” between attacks was determined by the weight of the robot, where lighter robots caused more damage. Projectiles were also allowed, but they were severely limited by the rules, thus few teams attempted to utilize them. When a robot received the signal that it was dead (the health level it received via broadcast dropped to zero), it must indicate this by turning off, and it was removed from the game.
Robots were also capable of healing by sensing healing lights in the floor of the arena that flashed at different frequencies. If the robot could detect a light at the proper frequency (tested directly before each match) and turn on an indication LED, a judge would restore some of its health. The locations of which lights have the proper frequency were changed from match to match.
The nexus could be damaged by directly attacking it, but it would “attack back” by damaging the attacking robot with 50% of the damage that the nexus received. Thus, the nexus was generally attacked by taking control of the two towers on the game field. When a tower was controlled, it would cause the enemy nexus four damage points every second. The towers were controlled by pressing the large buttons near them for eight consecutive seconds. This was generally the best way to attack the enemy nexus and ultimately win the game.
Complete rules of the game can be found here.
Mechanical Design
There were many considerations when designing our robot. Robots were able to cause more damage the lighter that they were, but had the disadvantage of being easier to push around. However, we determined that a very small robot could kill an enemy in around 10 seconds, so we decided this would outweigh any disadvantages. We opted to a create a robot that minimized weight and attackable surface area, while maximizing controllability and maneuverability. After several design iterations, we developed a relatively small, light, and quick “anti-enemy” robot, which had the ability to quickly clear out opposition.
We opted to use direct drive and differential steering. This approach allowed the robot to pivot in place, which the team determined would be useful during the competition in tight areas of the arena. The outer shielding seen in the CAD was added to prevent the circuitry from being harmed during matches. However, this shielding added significant weight so we later opted to simply use duct tape to protect the circuitry. The base of the robot was laser cut from eighth inch acrylic and the rear drive wheels and front bearing were purchased.
Electronics
The team opted to use a 7.4V LiPo battery, since it had high current draw and appropriate voltage for this application. We decided to use two separate MCUs, the NodeMCU with ESP8266, required for wireless wifi communications, and the Teensy 2.0. This was done mainly because the ESP did not have enough available pins to run all of the circuitry required - particularly the motor driver.
The ESP was responsible for running the LED bar graph used to indicate health. The LM3914 led driver allowed this to be accomplished with one pin by outputting a pulse width modulation (PWM) signal. The ESP was also responsible for managing the arm. The arm was, essentially, a force sensitive resistor (FSR) mounted on a servo-actuated arm. The ESP would command the servo and read in the output of the FSR with its one analog-digital conversion (ADC) pin. If the FSR response crossed a certain threshold, then it would turn on the hit indication LED (GPIO16). The ESP was the only board capable of communicating over wifi, so it would parse command signals (received from the laptop), set the servo and health outputs accordingly, and then pass on the motor control commands to the Teensy via SPI.
The Teensy was responsible for controlling the motors based on commands received via SPI from the ESP, handling healing light detection, and driving the MAX7219 LED matrix that displayed the robot number and team color. The healing circuit (bottom of the diagram) detected the healing light frequencies scattered about the field. Five TEPT4400 phototransistors were mounted on the bottom of the robot and their output was passed through a high-pass filter followed by a high gain op amp. This resulted in a square wave switching between 0V and 5V, which could be easily detected by the hardware input capture feature of the Teensy. An indicator LED could then be set when the appropriate frequency was detected. The motor driver was a variant on a simple H-bridge and could be easily controlled. Since the hardware SPI pins were used to communicate with the ESP, a software SPI interface was implemented using GPIO pins in order to control the LED matrix and command the team number as well as different images to indicate healing or death. A 5V limiter was used to step down the 7.4V power supply in order to power some of the systems, including the Teensy and the servo.
Software
The network was composed of a laptop that would read in control values from an Xbox One controller and health status values, and then relay them over wifi UDP to the ESP, which would then communicate them via SPI to the Teensy. The ESP was programmed in C++ using the Arduino IDE, while the Teensy was programmed in C, and the laptop control program and GUI were written in C#. To increase the complexity, an additional network element had to be added when the laptop lost the ability to communicate reliably over UDP. An additional ESP was connected to the laptop via USB, and the laptop would then relay controller and health commands via serial connection to the new ESP, which itself would relay serial commands over wifi UDP to the ESP on the robot.
For the code run on the laptop, we used SlimDX, a wrapper for the DirectX libraries, to read in Xbox One controller commands and then relay them over serial (note that the code that actually reads in controller values was drawn from online resources). We also realized that using a laptop and Xbox controller (most teams used a homemade controller) gave a distinct advantage beyond the fine control that the Xbox controller offered. Since the laptop was connected to the same wifi network as the robots, we could read in the health status signals (sent to the robots) to the laptop and display them on a GUI. This allowed the distinct advantage of being able to know the exact health of each robot on the field as well as of the two nexuses. This GUI provided strategic advantages during the competition. Once the health and command data were parsed, we could relay only the relevant information to the robot, removing the need to parse large amount of data on board.
Results
Our robot exceeded expectations. Our meta-team won the overall tournament, with our robot playing a key roll.
The robot was able to quickly and easily remove other robots from play, which allowed the team to easily maintain control of the towers necessary to destroy the enemy nexus.
Our robot had the best “kill to death” ratio of all the robots that competed. In one of the more pivotal matches, our robot “rushed” the enemy nexus, and was able to narrowly win the match by directly attacking the nexus and then quickly healing afterward. This was only possible because of the GUI that told our team when healing was necessary and exactly how much health the nexus had remaining.
The video shows a highlights reel of our robot's best moments.