How does this work?

Let’s start with the goals of this project:

And what was not a goal:

Here is how FIRST made this easier for me:

In the home version of the radio configuration utility, there is what is called “FMS Offseason” mode. This has the robot radios connected automatically to a given network. This means I don’t have to deal with how to connect radios to the network. This took a major hurdle away since I only had to deal with the driver station to/from FMS communication. Also, all robot driving is directly from driver station to robot, so I don’t need to interfere with their communication, I just need to make sure that they can connect to each other.

Here is how Team 254, the Cheesy Poofs, made this easier for me:

In case you didn’t know, the Cheesy Poofs host an annual event called the Cheesy Champs, and they use their own custom FMS called Cheesy Arena. They post their source code publicly on GitHub, which means there is open source information on what is required to connect to a driver station and tell it that it is connected to an FMS.

How does it work?

When you open the program, you are prompted to enter a team number for each alliance station. For each team number, it is converted into two different IP addresses (10.TE.AM.1 for the robot radio and 10.TE.AM.2 for the RoboRio), and a Driver Station object is created. This object has several threads that ping the driver station, robot radio, and RoboRio, and other tasks like sending the control packet. This packet is very important since it’s what tells the driver station when to enable the robot and other information (See here for the exact information)

But at the point team numbers are being entered, driver stations aren’t usually connected or if so, they aren’t at a nice IP address like 10.TE.AM.5, but that’s where the assignment packet and the configuration of the PracticeFMS computer come in. There is a hardcoded IP address for the FMS, 10.0.100.5, and the driver station sends a packet to that IP address to check if the driver station is in that match and that it is in the right station. In the case of this program, the packet tells the program at what IP that team’s driver station can be reached at, and opens up a TCP and UDP connection to it. The FMS then sends an assignment packet back to the driver station, telling it if everything is good to go. At this point, the Driver Station object has been informed of the driver station’s IP address, so it starts sending control packets to the driver station, which causes the driver station’s software to enter FMS mode (Indicated by a blue bar under the robot status and “FMS Connected” appearing where the enable/disable buttons would normally be). At this point, the PracticeFMS program is now checking for 3 things from each team: The driver station having been assigned, the robot radio being pingable, and the RoboRio being pingable. After all of the requirements have been satisfied for all teams competing, the PracticeFMS can be told to start the match countdown. At this point, the Game Specific String packet is sent to the driver stations, which in 2018 is alliance dependent. Over the whole program, there is a variable that tracks the current game phase and the time left in the current game phase which is used by the control packet generator to help constantly build and send updated control packets to each driver station as fast as possible. That’s all that is required for match play.

Another thing that starts at the start of the match is the estop thread. This thread runs the entire time there are robots enabled and allows the PracticeFMS computer to E-stop any robot or the entire match. Estopping a robot is as simple as adding a byte to the control packet, and the way I E-stop the match is by E-stopping every robot and forcing the timer to 0 for the rest of the phases.

Return Home