Scouting App

Technologies used

Project worked on Winter and Spring 2015

At age 17

Project worked on for about 2-6 hours a day from January to April


Why I Built It

When FRC teams are competing, there is a need to "scout" out the strengths and weaknesses of the other teams' robots and use that information to help our robot drivers determine their game play strategy for each match. In addition, during the later part of a tournament, the leading teams form alliances with teams that have complementary capabilities. Analysis of the other teams also helps in this process. Our team had no automated way to do this data collection and analysis, so I decided to take on solving this problem.

Technical Details

I had to work within these constraints on how I built the Scouting App:

  • No Wi-Fi communication is allowed at FRC matches, since this could interfere with the remote control to robot communication.

  • Internet access is highly unreliable in many of the schools, without Wi-Fi or reliable cell service, therefore we did not use cloud storage as a way to share the scouting data between the spectator stands and the pit.

  • We could not rely on having access to A/C power in the stands, where the data entry terminals would be used.

  • We did not have budget to buy a lot of new laptops. The old IBM Netbooks were donated.

Version 1 Details

Physical Architecture

There is one Netbook that acts as the Scout Master which hosts the application. We have six other Netbooks that act as data entry terminals. They are connected together via Ethernet cables and a switch. The Netbooks are all powered by a robot battery. There is the Pit Master computer in the Pit which displays relevant information to the drive crew before each match. The Scout Master would output its scouting data onto a USB drive which would then be brought to the Pit and then loaded on the Pit Master.

Operating System

When we got the Netbooks, they were running Windows XP. They were pretty slow, so we decided to run Linux Mint on them.

Software Architecture

Tomcat is a web application server which hosts the scouting application code I wrote. Spring is a middleware layer that contains many capabilities, two of which I used in this application. It allows me to write and read Java objects to and from the SQL database. It also provides a Model View Controller, allowing me to easily present the user with data and process alterations they made.

Application Design

In an FRC match, six robots play at one time. Each of the six Netbook client users is responsible for reporting on the game performance of one of the six robots. The way for each user to select the robot to report on is through using the Tournament Schedule screen. The screen presented to the user lists all the matches in the rows, and all the robots per match in six columns. The user clicks on their assigned column in order to begin data collection for their robot. This action opens the Match Data Entry screen. The user is presented with a form where they input data about the robot's performance in the match. After submitting the information, the Tournament Schedule screen is presented again.

What I Learned

  • I learned how to use Spring

  • I learned how to design and create database tables in MySQL

The Project's Story

I led this initiative on my own, resulting in our team having its first automated scouting application for collecting and analyzing team performance.

  • I worked with teammates on initial software design decisions

  • I worked with teammates to decide what data to collect and analyze, based on the game rules and scoring

  • I helped three teammates prototype the web GUI who were learning HTML

  • I designed and coded the entire application

  • Twenty of my teammates were trained on how to use the application

  • Some of my teammates made the power supply for the Netbooks that used a robot battery

  • One of my teammates configured all the Netbooks with the Linux Mint operating system and Tomcat

  • I designed the operation used during the tournaments. The scouts manager organized work shifts for when the team members were assigned to watch the matches. Six team members at a time would watch the six robots in each game match and record robot performance into the application. The information would be stored in a centralized database server they were networked into. After several matches were complete, the database contents was copied onto a flashdrive and delivered to the "pit" where the robot and drive team were. The data was then loaded into the Pit computer where pre-match analysis reports could be viewed