v5_field_control/notes.txt

30 lines
1.9 KiB
Plaintext

2023-12-14 17:30:57 -07:00
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