Sparkmax Failover will never happen

[TrialNTerror]

The getRelativeEncoderPosition method will always return the absolute encoder position as they are not separate in SparkmaxSwerve.java. Additionally absoluteEncoder will never equal null to swap over to the relative encoder.

So it wont fail over. And the Dashboard says they are always identical regardless if both work or not.

[TrialNTerror]

Actually apologies. I think absoluteEncoder could be null, but only if it wasn't connected originally.

[thenetworkgrinch]

If the SparkMax has an absolute encoder attached to it, then it will return the value of the absolute encoder attached to it. However I do not remember if i made any checks to see if this fails. You may be correct.

[thenetworkgrinch]

Currently with REV's API I do not know if there was an error raised because none is returned from the call. The closest I can get to it is SensorError which does not explicitly state any error message I can rely on.

[TrialNTerror]

The absolute encoder value wont change if it comes unplugged. Would that be something that could be used?

[thenetworkgrinch]

I will not fix this until REV has an API in which I can utilize specifically to fix it. If this sits here by end of december and I am reminded of it I will implement a "hacky" fix.

[TrialNTerror]

Ok Darn thank you

[TrialNTerror]

Could you please tell me where in YAGSL does it make the change to the relative encoder, because seemingly no matter what I do it wont swap to the relative encoder?

[thenetworkgrinch]

There should be no reason to get the relative encoder value since it is not used in a SparkMAX with attached absolute encoder. Here is the snippet that ensures that.

https://github.com/BroncBotz3481/YAGSL-Example/blob/main/src/main/java/swervelib/motors/SparkMaxSwerve.java#L189

[Technologyman00]

What if it was used for failover? I feel like that is the main reason.

[thenetworkgrinch]

It shouldnt be, since in theory the encoder is attached to the SparkMAX correctly and the response time is minimal + no magnets to worry about (unless using canandcoder). implementing a fail over would require resetting the feedback encoder to the relative encoder mid-operation which i have never seen in code before and have no idea if that may trigger some undefined behavior from REVLib.

[Technologyman00]

https://github.com/Trial-N-Terror-FRC-7900/YAGSL-Max-Swerve-Example/tree/SparkMaxFailover I have made some code that should work for failing over on the sparkmaxes. We will have to test it, but it is based on that we have noticed that the encoder value freezes after lost connection