System Architecture
The Detective consists of two main components; the server, and the client.
The FRC Detective Server is written purely in Python 3, and can run on either Linux, Mac, or Windows without any issues. The server is designed so that it can be used without a GUI and in a headless state for use at competitions on small embedded systems, such as a battery-powered Raspberry Pi.
Unlike the server, the client application is written in C# and Xamarin, and can be compiled for both Android and iOS. It is designed specifically to be run without an internet connection 99% of the time it is open, to allow for match data to be collected while untethered.
Data Storage and File Structure
| Type | Code | Description |
|---|---|---|
| Server Status Responses | 'RECV_OK' |
Recieved data, hash is correct. Server is ready to continue processing. |
'RECV_DC' |
Server is asking the client to disconnect from the socket. | |
'RECV_ER' |
Server encountered an error (mainly for hashing). The server will now wait for the client to send the data again. | |
| Server Instructions | 'N' |
|
'D' |
Server Streaming Round Data to Client. | |
'Z' |
No data available to stream to client. | |
| Client Status Responses | RECV_OK |
Recieved data and ready to continue processing. |
| Client Instructions | 'L' |
|
'R' |
||
'S' |
On both the server and the client, each round is stored in local storage, and can be referenced with a key, which follows the format: [division(1)]-[roundtype(1)]-[roundnumber(3)]-[teamnumber(5)] (where the number enclosed is string size)
A TLDR flowchart is available at the bottom of this section for quick reference.
The FRC Detective Server is always listening for new connections (every 0.2 seconds by default), and as soon as it creates a connection with the client application it will automatically initiate a new data transfer. One "data transfer" is a relatively complex combination of messages, both being sent and recieved in series, which includes error checking by hashing the data and comparing it with the has from the client side (though this is not yet implemented)
To begin the data transfer, the client will detect when it is connected, and initiate the process by sending the list of data it has available in local storage, along with an edit timestamp (in Unix Epoch Time), and a UTF-8 encoded byte at the beginning: 'L' - to designate that we're sending the client's List. Some example data is included below, which assumes there are two rounds inside
'L0-0-001-05584'1614432877'0-0-002-05584'1614432879
*for any examples of data in this document, you can assume data encased in quotes is text encoded in UTF-8, and anything outside of it is raw bytes.
Once the client recieves the List Data in full, it will reply with the data 'RECV_OK'. This response is one of three response options - itself, along with 'RECV_DC' (tells the client to disconnect) and 'RECV_ER' (which indicates an error in data transfer). In the current version of the server however, these other two error codes are not used, so all the client does is makes sure it has recieved the OK signal, and then continues with the transfer.