CANCoder vs limit switch for Falcon swerve drive homing

Our team is working on a swerve drive for the off-season, using all Falcons. I wanted to know which is the most preferred method of homing the turning motors.

1 Like

We definitely favored the CANCoders for our 2022 swerve (also all Falcons.) The thing to be careful of is CAN bus overruns. Be sure that you limit how other elements on the CAN bus send data (especially data that you don’t need, like from the steering Falcons own encoders), or you’ll have difficulty controlling the swerve drive.

Yeah, we’re considering using the CANivore (at least on our competition robot, should we choose to do swerve next season), to take advantage of the higher bandwidth CAN bus.


CANcoders are the preferred method. I think there is some merit in the limit switch approach, but most teams use CANCoders for the flexibility.

Our team uses the internal PID controller on the Spark Max (same concept exists for the Falcon) and just uses the CANcoder for the initial sensing. This works well, and keeps some stuff off the CAN bus.

Makes sense. I was wondering that as well, whether to use the CANcoder for just initial homing, or for all the PID. We also plan on doing PID on the motor controller itself.

CANCoders clog up your bus with a lot of unnecessary traffic for a very small bit of added functionality/convenience. Use an ordinary CTRE mag encoder or a limit switch. You might not be able to pinpoint it, but the increase in reliability of your CAN bus due to the decreased number of devices will likely be nontrivial.


@Oblarg CANcoders take up 1.8% of your total bus utilization by default, not what I would call “a lot of unnecessary traffic”. It is the single lowest bus-utilizing device that I’m aware of, CTR or otherwise.

Additionally, once you’ve seeded your absolute position you can slow down the status frame.


That’s not a negligible amount of overhead when the bus is already crowded, and it makes absolutely no sense to pay that cost in perpetuity for what amounts to a limit switch.

Overloaded CAN bus traffic is one of the number one causes of unreliable robot operation this year, from what I’ve seen. Teams should be eliminating unnecessary load on the bus whenever possible.


Are you concerned even with the use of a CANivore?

Less-so, though I still wouldn’t use a CANCoder in most cases because the nondeterministic delays in measurement make it not ideal for feedback control. I’d rather have a bit of extra wiring and a reliable sensor.

Let me be clearer - the total CAN bandwidth of your robot is a technical limitation that needs to be managed, not a boogeyman to be avoided at all costs. CANcoders are just a small piece of this and contrary to your characterization are one of the smallest contributors.

You should be starting from a place of ‘this is what we need for our robot’ and then determining what makes the most sense based on your setup.

To the OP: using an absolute sensor to set your reference is highly preferred.

This can be using a CANcoder with everything on the RIO’s bus but adjusting status and control frames to keep bus utilization manageable, or using a CANivore, or using an absolute sensor back to the RIO. I prefer the CANcoder as it’s (in my opinion) the most straightforward.

The OP has already said they’re using this as an initial value to seed the Falcon’s starting position, so the periodic nature of CAN data is not a factor.


I think the argument against the limit switch is that the CANcoder can eliminate the need for a homing sequence. Other than that…it is a fancy limit switch/potentially get a more consistent response.

Be kind of interesting is teams decided to put their CANcoders on the switchable port on the PDH, to declutter their Canbus.

There may be a cleaner way to do that in software too :slight_smile: I haven’t dug into the code.

I was also considering using the CANcoder directly for feedback to the Falcon as well, due to the ease of the CANcoder reporting an angle directly, as opposed to encoder ticks. Has CTRE evaluated the pros/cons of doing this versus just using the CANcoder for initial seeding of the Falcon’s built-in encoder?

I’m sure either way is viable.

1 Like

A good way to avoid running into overhead problems in the first place is to adopt design philosophies that avoid them before they happen.

One reliable such philosophy is, “don’t put a device on your bus that is going to potentially shout data over your timing-critical sensors for the entirety of the match because you need to home your azimuthal actuation precisely once at the very start.”

I am well aware that technically-competent users can work around the limitations with diligent use of the CTRE API features. I’m also well aware that this often doesn’t happen in practice and that your “low utilization device” does in fact cause a lot of teams reliability issues that they struggle to diagnose.


That’s an interesting idea actually… you could initialize your code then close the references to the cancoders when you’re done with them (to prevent errors) and power them off…

When we do swerve this summer we’ll probably spring for ctre mag encoders to the roborio since it’s easy enough to do and doesn’t require unnecessary CAN usage.


The cancoder has an update rate of 100hz by default. The integrated encoder on the falcon can be used by the falcon’s onboard PID at its full rate of 1khz. Additionally, and probably more important, there is inherent latency in the data reported back by the cancoder.

You guys are running swerve over the summer?!?

Sweet! Reach out if you need any help.

My issue with the CTRE mag encoder is it kind of makes for messy wiring (assuming you are using brushless motors). It’s solvable … Just takes some thinking. Our wiring setup using the CANcoders was more clean (in our opinion) took some thinking though.

You may also consider the ttb encoders. They cost less, and may be a little earlier to wire directly to the Rio.

1 Like

You’re correct that both are viable - pros/cons roughly fall into these categories (this is not by any means a comprehensive list):

Seeding from CANcoder and running Closed Loop with the Falcon’s Sensor:

  • No delays between Falcon’s sensor and closed-loop
  • You can reduce bus util of the CANcoder once you’ve seeded
  • You need to check for device resets (like if you trip a breaker) so you know if you need to re-seed your absolute position.

Using a CANcoder as a remote feedback device:

  • Always have direct absolute data
  • Have to keep CANcoder status data at default or faster
  • Update period of data from CANcoder as compared to the Falcon’s integrated sensor.
1 Like

We are definitely planning on it, as it seems to be the direction FRC is heading in, and we have the resources to do it.

The kids were really inspired by all the swerve bots in Indiana (yours included!) and are really excited to try it out. I told them we needed to prove it in the off-season before doing it in-season.

We’re also tentatively (contingent on a variety of factors) planning on building another robot atop the swerve base for the off-season events to practice different design and manufacturing techniques and to act as a training exercise for both new and returning members.

I will definitely reach out with any questions!

1 Like

Keeping the number of CAN devices low as a way to manage bus util is fine, but my primary point is that CANcoders are not the primary cause of high bus util.

Right, so this is where I think the disconnect is. From a bus util standpoint my earlier point still stands - CANcoder is the smallest user of the bus.

BUT we have seen many support issues with strange and difficult-to-diagnose CAN issues.
These come not from having CANcoder on the bus in general but rather the difficulty with properly soldering the wires to the CANcoder. The small through-hole connections have led to a lot of issues with wire whiskers and other CAN wiring issues. This is why we now sell both a wire kit with pre-tinned wire ends and a pre-wired version of the CANcoder.