General:
- All messages end in a two-byte CRC-16/CCIT-FALSE

Connection Sequence:
- For some reason, the first 4 packets are 16 bytes long.
<- Controller starts by sending a "discover" message(0x0A) every 20ms
  - Unsure what any of the fields in this packet mean, likely that a multi-byte identifier for the controller is included somewhere, and flags
-> When FC is powered on, it responds to the 0x0A with a 0x03
  - For 0x03 the first two bytes seem to be flags, and bytes 8-11 are the brains 4-byte ID, byte 7 also has bits set, but unsure what they mean
<- Controller responds to 0x03 with 0x13
  - No idea what any of these fields mean, but sending the same seems to work
-> FC responds with 0x02 ACK

- From now on, all packets are 32 bytes long
<- Controller sends "start something idk" packet 0x11
  - All bits are set to zero in the packets I've seen
-> FC responds with 0x04 with byte 2 set to 0x14
<- Controller ACKs 0x02
-> FC ACKs the ACK 0x02

Control Sequence:
- After this startup sequence is completed(actually just after the first 16 byte sequence is completed, not sure what the 0x11 sequence is for), the controller starts a sequence of sending 0xA7 packets every 20ms
<- Controller sends 0xA7 with the robot name, control status flags, system status flags, and timer.
- At this point the FC can respond in two ways:
 1) -> FC sends 0x02 to ACK the 0xA7, controller continues operation and sends 0xA7 again in 20ms with the same info
 2) -> FC sends 0x53 to update the info with control flags and timer. Controller sends 0xA7 again in 20ms and it should contain the updated info.
- The way I handle this in the code is to have an "expected state" for the timer and control flags(control flags can be updated over serial).
  - When receiving a 0xA7, if the info matches the "expected" send a 0x02
  - When receiving a 0xA7, if the info does not match the "expected" send a 0x53 with the expected info