Lining up Falcon 500 motors with the robot chassis

Last season, my team attempted to try our hand at swerve drive using this module as we saw how powerful it can be. The problem, of course, becomes actually using it.

Our programming team has had quite the time trying to figure all of it out, with PIDs and encoders and everything else, as well as having little to no help from coaches (they’re all build people). One of our main problems has been having to manually line up the wheels with the chassis of our robot every time we want to run it because we can’t find a way to tell our motors that 0 is pointed towards the front of the robot without doing this. This is not practical for competition and there has to be some way around it, we just need a little help, and I’m hoping this is a place to get some.

Also, any advice on getting started with PIDs would be amazing. Thanks!

You can do this a couple of ways. The way we did it this year is in PhoenixTuner by setting the Magnet Offset. Basically, 0 them by hand, then open up PhoenixTuner and check what the current reading is. Put that reading into the Magnet Offset.

That seems simple enough, do we need to edit the code to do this or will PhoenixTuner do it all for us?

Depends on what you’re doing. If you’re resetting the TalonFXConfiguration in code (driveMotor.configFactoryDefault()), then yeah you’ll have to do something in code. But if you aren’t doing that, just phoenix tuner should get you close. At the very least, to the next bug.

It is important at this point to make sure you’re zero-ing your modules as precisely as possible. This is difficult. It’s the one complaint I have about the MK3’s that we don’t have a mechanical way of zeroing it (like a pin hole or something). Of course, I haven’t thought that through too much, so there very well may be a great reason why that is not the case.

But doing it poorly is going to result in “permanently” (until you do this again) misaligned wheels. So some kind of jig helps. We managed to get away with a 2x4 that we could wedge between our wheel and the siderail of our robot so that we know the wheel is at least parallel to that. I don’t love our solution, but it was better than eyeballing it.

It looks like we are actually using that in the code and I can see how it would definitely be a problem. Have you found a work-around?

I think you can set that same value with that same name in code. I guess I missed a part here. If you’re setting your falcons to factory default, that won’t effect this, but setting your encoder to factory default will. But you can use this in code.


1 Like

That makes sense. Hopefully everything will figure itself out once it’s put into practice. Thanks!

We (2910) align our modules for calibration by tipping the robot up on its side and placing a straight edge (we use a piece of 2 X 1) against the side of two of the wheels from the front to the back of the robot. We do this once for the left two wheels and then once for the right two wheels. This ensures that the wheels of the modules are aligned to each other and has been more accurate than alignment screw holes in our experience because there is no slop. You also will never accidently start a match with a calibration alignment screw still installed in one of your modules.


I’m a boomer and haven’t done swerve in forever, but I strongly endorse this alignment scheme.

If you do a proper tolerance analysis, you’ll find that this is hands down the most precise way to easily orient modules and it also had the upside of requiring no design or fabrication.

1 Like

We actually had a mechanism for zeroing it but it just wasn’t accurate enough(due to tolerances) so we deferred to the 2 x 1 method

1 Like

That’s essentially what we did with that 2x4.

And my point about the pin wasn’t to use it before each match, instead just for the initial calibration. But I can see the risk where teams use it as a potentially competition ruining crutch. That is the great reason I definitely overlooked.