✨ Microdisconnect Detection

[SizzinSeal]

Overview

It was recently discovered that you can detect motor micro-disconnect (a disconnect and reconnect happening within 300ms) by using motor timestamps.

Motivation

Micro-disconnects are silent errors. No orange warning on the brain screen or message on the brain log. API like motor.is_connected() also do not connect them. However, the encoder position still resets, and the motor won't spin again until a different pwm command was sent to the motor. This should be handled.

Implementation

Here is a proof of concept: https://pastebin.com/737y1TP8
This is similar to the existing system, so integration shouldn't be too hard.

How it works

When calling pros::c::motor_get_raw_position, a timestamp is returned along with the position. The timestamp is the time of the onboard motor clock when the measurement was taken. If a disconnect occurs, this timestamp resets. By keeping track of this timestamp, we can detect all disconnects, micro or otherwise.

However, the clocks on the motors drift significantly from each other and the clock on the V5 brain. So, we need to calculate the range of possible timestamp values after some time has passed.

There is another problem as well. Consider these 2 measurements:

measurement #1:
system time: 500ms
motor time: 700ms

// a disconnect has occurred between the 2 measurements 

measurement #2:
system time: 1500ms
motor time: 800ms

It's not enough to just keep track of whether the motor timestamp decreased, we need to keep track of the difference between the motor timestamp and v5 brain timestamp.

[ABUCKY0]

could you put a thing in while the imu calibrates to also measure motor drift over time and have teams put it in initialize so it will take like a second to measure the motor time drift

[SizzinSeal]

Its possible yes

[ion098]

There is another problem as well. Consider these 2 measurements:

measurement #1:
system time: 500ms
motor time: 700ms

// a disconnect has occurred between the 2 measurements 

measurement #2:
system time: 1500ms
motor time: 800ms

It's not enough to just keep track of whether the motor timestamp decreased, we need to keep track of the difference between the motor timestamp and v5 brain timestamp.

Could this not be mitigated by having a thread that checks all motors every 10ms, making the chances of this happening negligible?