How exactly does FusedCANCoder compensate for backlash in the mechanism?
What exactly is it doing under the hood?
Any speculation?
Interested in seeing if I can implement a version of this for Spark Flex/Max motor controllers.
If I am understanding your question correctly the answer is you put the CANcoder on the shaft with the final reduction so you aren’t reading the motor encoder that is before the gear box (where the backlash can happen). When fused the motor PID will use the fused CANCoder value for the position instead of the internal motor encoder.
No I mean algorithmically, what is it doing under the hood?
No direct knowledge, but I think that when the internal encoder doesn’t match the fused encoder it updates the internal encoder. (taking into account configured gear ratio and magnet offset)
My speculation is that it uses a linear Kalman Filter over both sensors on the position and velocity state, assigning a lower covariance to the CANCoder when the mechanism is near 0 speed perhaps, or increasing process covariance when the motor changes directions.
I reckon it’d also have to do latency compensation on the CANCoder signal.
1 Like
Could it be as simple as a complementary filter?
Had to look that one up, but seems like something like that could be used here yeah.
It would still need to do some latency compensation on the CANCoder signal, but seems you could reduce a Complementary filter to a Kalman filter.
Honestly the simplest implementation would be what @Bmongar said and it would get the job done as long as the CANCoder value was latency compensated. It’s not like the CANCoder is a noisy sensor, there’s really no reason to not trust it’s readings 100% except in erroneous cases which is what SyncCANCoder is for I believe.
Guessing trade secrets is risky business and this may be the only hint we get.
1 Like
Well in a Spark implementation, I would be using values from a directly connected absolute encoder, such as the REV through bore encoder.
If you have direct feedback from a TB encoders, why would you want to fuse in the motor encoder? It’s less precise anyway. Just closed loop off of the connected sensor.
Fused sensor stuff isn’t that useful for dynamic situations. Losing track of the motor encoder is the same as losing control of the motor due to the way brushless works. I can’t imagine why a Kraken or NEO would lose encoder counts without a serious control issue, though I wonder if it’s possible another way that I’m missing. I’d focus on using the external encoder to seed the initial position, which is easy to accomplish with FusedCANcoder or just by zeroing on boot.
I’m trying to emulate CTRE’s backlash compensation which is available when using a CANCoder in fused mode.
I guess I wouldn’t necessarily have to fuse the two together, constantly syncing the motor encoder to the absolute encoder value as @Bmongar suggested is probably good enough.
Just trying to understand how exactly this “backlash compensation” works, and what fusing an absolute encoder does to help accomplish this.
1 Like
Just thought I’d follow up on this for those interested. I recently tested the approach of just constantly syncing the absolute encoder to the motor encoder for MAXSwerve modules and it appears to work well. I don’t have another suitable mechanism at the moment to test behavior on at the moment.