Field-centric swerve control behaving oddly

So at the end of last night’s meeting we installed a Pigeon 2.0 on our robot to try and restore our field centric control (rest of the backstory is here), and saw some odd behavior.

At headings of 0 and 180 degrees, everything functioned as expected (i.e. up on the joystick was field-forward, left on joystick was field-left, etc.) but at 90 and 270 degree headings things seemed to get inverted (joystick-left was field-right, joystick-up was field-down).

We didn’t have much time to try and find a solution, but I did note that when we were previously using a NavX we would return -getAngle for heading, which I did not do with the Pigeon. The above behavior makes me think inverting the gyro value like that may be a fix, but I was wondering if anyone else in the community had seen/dealt with a similar issue, and how you might have solved it.

Our code is located here and I used the FRC 0 to Autonomous swerve example as the base for our drivetrain code.

Thanks in advance for any input the community may have!


It certainly sounds like inverting the angle from the gyro might fix your problem. This year, we mounted all of our electronics on the bottom of our bellypan (upside down) including our RIO where our NavX is mounted. Therefore we knew that we would need to reverse the sign on our gyro heading since it was mounted upside down.

1 Like

Navx is CW positive, most other things are expecting CCW positive. So, doing the tutorials and things with the Navx you have to negate the Gyro.

Is the Pigeon CCW positive? If so, you’ll need to undo the inversion of the gyro you had with the Navx.

What confuses me a bit is that we’ve mounted the Pigeon according to its typical sign convention (x is robot-forward, y is robot-left, z is up) and aren’t doing anything in the code to invert that.

The Pigeon is indeed CCW positive, and as I noted in the OP we are NOT inverting the signal like we were with the NavX previously.

At this point my plan is to try inverting the gyro values again and see what happens, but I’m having a hard time wrapping my head around why that would fix things (if it does, which is tbd).

We also have the pigeon mounted according to its sign convention, but I am inverting it because it wasn’t CCW positive. Maybe we have differences in mounting, but I think our navX and pigeon were reporting the same raw values.

This is good to know, thanks for sharing your experience.

Maybe I’m misunderstanding something, but if the NavX and Pigeon were reporting the same values that does seem to run counter to the Pigeon 2.0’s documentation:

I found that on the CTRE phoenix lib documentation. I guess we have it mounted backwards then.

So I was able to confirm that, mounted according to the documentation convention, the Pigeon 2.0 is CCW positive.

That being said, inverting the gyro value fixed things and field-oriented control looks good. So I still don’t fully understand why I needed to invert the value, but that’s a mystery to solve sometime that isn’t the day before our district load-in.

I’m using WPI_Pigeon class so I’m not sure if this getAngle() might invert the gyro. I’m not sure why it would, but it might.

1 Like

It seems that it does, because apparently the WPILib gyro interface is designed around gyros returning CW positive


This probably explains why I was seeing the behavior I did.

Our code is using the Pigeon2 library for the gyro, but the WPILib swerve library.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.