The RFM69HCW radio modules that we plan to use for CoLo PE are only capable of half-duplex communication, meaning that it can either transmit or receive packets but not both at the same time. In a typical setup, this issue would be addressed by either setting the modules to automatically retransmit or to wait for an “ACK” or acknowledgement response packet that indicates if the message was received.
However, in CoLo-PE, our goal is not to establish reliable communication between the robots (that is already handled by WiFi). Instead, these radio modules will be used to measure the relative signal strength and link quality between each of the robots during a physical test. To do this, we want to send packets between the modules and measure the rate at which packets are dropped. Last quarter I tested these modules independently running unsynchronized. Each module would alternate between transmitting and receiving messages. I figured that if the time it took to transmit was short enough compared to the time it spent listening for packets, synchronization would not be necessary. However, I found that packets were either almost entirely dropped or consistently received depending on whether or not the cycles aligned.
The solution I built was to depend on the system clock of the robot computer instead (compute stick/laptop). Using UNIX Epoch time (time since 1 Jan 1970) as a common reference, the RF modules could be coordinated so that only one module would attempt to broadcast a message at any given moment. This pushes the problem of synchronization from the RF modules to the computers controlling them.
Luckily, there already exists a widely used solution for time synchronization between computers in a network: NTP or Network Time Protocol. I configured each computer using the reference implementation NTP client to synchronize their clocks with the central computer that would control/coordinate CoLo-PE. On the central computer, I run an NTP server to respond to the time synchronization requests of the robots in the network. Using this method, I was able to synchronize the robot clocks to within 1 ms of each other. This should be well within the margin of error for our target of 10 updates per second.