Talon .setSensorPhase issues

We are having issues programming the Falcon 500 encoders. When the wheels move forward, we get a negative result on the right encoder. Calling .setSensorPhase() on the right encoder has no effect. Has anyone else had this issue? Thanks.

> Blockquote 
public void testInit() {












public void testPeriodic() {

System.out.println(rightFront.getSelectedSensorPosition() + "right");

System.out.println(leftFront.getSelectedSensorPosition() + "left");


Edit: It seems like CTRE says the .setSensorPhase() method does not work anymore. Will get back with more info.

SensorPhase determines the relationship between sensor and motor voltage. Talon FX uses an integrated sensor, so we ensure they are aligned regardless of setSensorPhase().

You need to correct the Invert, so that positive motor request spins the motor such that it produces forward motion in the robot. Use setInverted to solve this.

Note that instead of passing true/false, you could alternatively specify clockwise/counter-clockwise to clearly indicate what you want positive.

You know the inverts are correct when all Talons blink green and robot moves forward.

Roger that. The issue is, setInverted changes the direction of the motors without changing the LEDs. So, the robot goes forward but the two right motor controllers are red.
Sorry, I didn’t specify that. :grimacing:

@ozrien it would be nice if the API documentation for the TalonFX mentioned that .setSensorPhase() did nothing. Better yet, make that method throw an error.

I have yet to find where in the CTRE documentation that this is documented. I’ve only seen it noted on here on ChiefDelphi, and only after I narrowed the problem down to the setSensorPhase call was I able to search for the correct term on CD.

CTRE also needs to add a few TalonFX examples to the library of example code you provide. (The code samples are extremely useful!)

I suspect there are many teams this year that are 1) using FalconFXs and 2) implementing trajectory following using the WPILib Ramsete classes. The latter need the encoders to report the direction of travel correctly. An example implementation of this would be a huge service to FRC teams trying to learn both.


I disagree because calling the routine isn’t necessarily an error condition.
It is harmless.

This has nothing to due with sensor phase. Sensor phase is the relationship between the selected sensor’s direction and motor output. In the FX, the selected sensor (when integ is selected) is always in phase.

The test procedure is to select sensor phase, then drive positive motor output and confirm positive selected sensor velocity. This is what we document. This is what our examples reference. This has not changed. If you do this in FX, then you will find the test passes regardless of what bool you pass because we ensure they are in phase.

I suspect you didn’t setup your motor inverts correctly, meaning you want positive sensor velocity when the robot moves forward. Sensor phase has never been used to solve this situation. Use SetInverted to make positive-motor-output (and sensor velocity) occur when your mechanism moves forward/upwards.

This changes nothing. You still have to set your motor inverts so that forward is positive.
Your Talon SRXes, FXes, and Victor SPXes should be green when the robot drives forward.
If not, then the inverts are wrong.

I agree. They are being developed and will be merged soon. See FX branch below. FX examples will likely be in a sub-folder since they are essentially forks of the more generic examples.

Some references below.

Note that sensor phase only ensure sensor and motor output match (which they always do on FX). Then you call SetInverted to decide what direction you want positive sensor/motor-output to be.

Similar procedure here.

Test procedure below for how to align the motor and sensor phase. Again if this procedure was followed, it would passed.


I’m not against enhancing the docs/examples. This was on our schedule this week anyway @Jacob_C.
But I think some users treat “sensor phase” as “sensor direction”, which would be just arbitrarily flipping the sensor output. Remember there are 3 properties to track

  1. moving the robot forward/reverse
  2. motor output positive or negative
  3. sensor positive or negative

Sensor phase only addressed 2 ↔ 3.
SetInverted addresses 1 <->[2,3].

Also note on all CTRE MCs, changing the SetInverted() input does not require changing setSensorPhase(). That’s the difference between sensor phase and sensor direction.


First off, a big thank you @ozrien for your very comprehensive reply. I feel like maybe I hit a nerve, and for that I apologize.

Your post has help illuminate some of the corners how setting the motor invert and sensor phase relate.

I was coming at this from the point of view that the robot is a box with wheels and I want to flip the toggle switches so that when I apply a positive throttle input the robot goes forward. Then I want to toggle the other switches until all the wheels report positive distance travelled and positive speeds when I drive the robot forward.

This doesn’t take into account local closed loop control, where my positive throttle input, is actually a negative voltage on some of the motors and thus the sensor should be matched and reporting negative velocity. So obviously you shouldn’t toggle sensor phase so that the signedness of the velocity matches that of the robot, but keep it in phase with the motor’s inputs.

Now here you lose me a little in your terminology. You talk about positive/negative inputs to the motors, are you talking about positive/negative voltages? or are you talking positive/negative “throttle” inputs as in forwards/reverse (percent output). I think you’re saying the latter.

Let say I have a standard robot where the left and right side of the robot have mirrored drivetrains connecting the motors to the wheels. That is the left motor turns clockwise (CW) and the right motor turns counter-clockwise (CCW) for the robot to drive forward in a straight line. Let’s say inverting the right side motor makes it so positive motor inputs drive forward. Assuming the sensors are in phase with the motors (these are Falcon 500 motors). What is the sign of the left and right wheel velocities when I drive forward?

My experience is that the left reports a positive velocity and the right reports a negative velocity.

I’m just having a hard time shaking the feeling that that is wrong, and the sensor should report positive velocities for both left and right motors.

1 Like

@ozrien was kind enough to help me debug this problem.

I see the problem. Don’t use sensorCollection(). Use getSelectedSensorVelocity(). Sensor phase is handled by the “selected sensor” module in the Talon/Victor firmware. Take a Tuner self-test and look at your velocity under “PID0” vs the raw Integ-Sensor value lower in the self-test. The value under “PID0” is the value you want, which is returned in getSelectedSensorVelocity().

SensorCollection() gives you the raw (unconditioned) sensor at a much lower bandwidth (like 200ms per update). GetSelectedSensorPosition/Velocity is 20ms, is the recommended means of polling any sensor (Talon SRX or FX).

I was using getSensorCollection() to get a handle for an encoder for the Falcon 500 drive motors. This matches the semantics of the WPI Ramsete command example and it matches the semantics of the Rev Robotics SparkMax. However, this is the WRONG way to get the position and velocity for Talon motor controllers.

This explains why the encoders where reporting the incorrect sign for position and speed. The way I was getting these values were from the raw, non-inverted and non-setphase’d, encoder. So no matter what invert and setphase() setting I used, this would not change.

1 Like

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