The new drive controller in src/subsystem/ has an update_motor_acceleration() function called every main loop. At the end of this method, the left_speed and right_speed should be applied to the motors (Currently, there is no acceleration rate limiter. The rate limiter will replace where it currently sets actual equal to target).
Some things to consider:
The main loop has no delay added, but messages cannot be sent that fast. Strategy to prevent exceeding limits but maintain responsiveness:
Use std::chrono::high_resolution_clock for tracking time. Save a timepoint whenever drive writes the motor speeds. If some minimum amount of time hasn't elapsed since last call, do not send the motor speed update. (We still have to figure out the minimum, but it could be less than one millisecond)
Save a variable for the last speed written. If the new speed equals the last speed, do not send. Note that we should send a value anyway a few times/second.
Overall, the goal is minimizing CAN bus utilization while still sending speed updates as fast as possible. We're not 100% sure how Linux CAN works internally, but it seems there's some kind of queue when we write values. If we send values too quickly, it eventually overflows and the program crashes. Even a tiny rate limiter (1ms or less) should be fine.
The new drive controller in
src/subsystem/
has anupdate_motor_acceleration()
function called every main loop. At the end of this method, theleft_speed
andright_speed
should be applied to the motors (Currently, there is no acceleration rate limiter. The rate limiter will replace where it currently sets actual equal to target).Some things to consider:
std::chrono::high_resolution_clock
for tracking time. Save a timepoint whenever drive writes the motor speeds. If some minimum amount of time hasn't elapsed since last call, do not send the motor speed update. (We still have to figure out the minimum, but it could be less than one millisecond)