CANCoder with SparkMax built-in PID?

We are a falcon only team and thus have very little experience (i.e. all we know is what the docs say) with SparkMax motor controllers. That being said, we are tying to implement SparkMax/NEO support into the swerve portion of our Standard library (long story). However, in the prosses of implementing this I realized that it appears as though the integrated PID of the SparkMax has no way of interfacing with a CANCoder to for azimuth positioning of the module. Does anyone know a way around this?

Thanks in advance!

You can use WPILib’s PID instead of the sparkmax PID or use the CANCoder to “seed” the encoder on the NEO and just set the NEO encoders position to whatever the CANCoder reads (not directly ofc but after you do the appropriate math to adjust it).


This is the way.


This is the best way to go. Even with Falcons this is the way to do it. Only use the CANCoder to get the absolute reading on startup, and then use the built-in encoder.

However, watch out for an issue with the startup process. This issue was discussed quite a bit on this thread.

SDS has a workaround in their library but it’s incomplete.

Only use the CANCoder to get the absolute reading on startup, and then use the built-in encoder.

It’s also probably a good idea to also seed the NEO encoder when stopped or not rotating so that any inaccuracies can be compensated for.

I strongly disagree on this. perhaps it’s different without a canivoir. but with one just use the encoder as a remote sensor for the falcon

@cmwilson13 You can use the CANCoder as a remote sensor with a Falcon for swerve steering, but it would provide no advantage over using the built-in encoder.

There are advantages to only using the CANCoder to seed the Falcon’s built-in sensor:

  1. Using the built-in sensor will reduce CAN utilization. Using the CANCoder remotely will require four sensors to be polled over CAN every iteration.
  2. The built-in sensor will also give a bit lower latency.
  3. You don’t have to worry as much about the built-in sensor getting damaged or knocked off during the match.

I agree. That’s what the SDS workaround does.

1 Like

all good points. but with the mk4is there is what i would consider significant backlash in the system and our autonomous paths benefit from the on axis encoder with no backlash. we had our cancoders updating every 5 ms. 4 cancoders and 12 falcons and we were at about 40% can bus utilization on the canivore. might not be the ideal situation for everyone. but we never had any drive train issues in over 100 matches this season.

1 Like

I really don’t think this is the kind of thing the CAN protocol was designed around. Why not use AMT-103s or some similar quadrature encoder and save yourself the bus overhead?

1 Like

CAN, probably not, but I think that CAN FD has some of this madness in mind.

I’ve seen some CAN based sensors becoming popular in industry, and customers are requesting them. Even simple steering sensors.

At the end of the day, CAN is just a rugged digital protocol. CAN FD let’s you hit a faster data rate.

I don’t think I’d recommend this sort of thing on the rio CAN bus, but on the CANivore bus it probably isn’t completely ridiculous.

I think the best solution is for the Falcon to have a port to integrate an absolute and quad encoder, so all the control can just exist outside of the Rio. But sadly it doesn’t.

I would love to . But i also want the amazing built in controls on the falcon, also with a canivore it just works. perhaps it was not setup for something like that initially but it appears to be the best solution currently available for our use case in frc.