Author Topic: CTRE Phoenix Framework Documentation Links  (Read 196 times)


ohad z

  • Newbie
  • *
  • Posts: 15
Re: CTRE Phoenix Framework Documentation Links
« Reply #1 on: January 18, 2018, 11:13:05 PM »
Our Swerve libraries have been affected by the changes to the CTRE libraries. Below are the observations that we have collected so far as for the relevant changes and how to accommodate them:

Method signature changes
  • Motor’s set() method now takes 3 parameters. The old way to set the steer motor was to set the “mode” to ControlMode.Position and then to call motor.set(angle). The new way combines mode and angle to one call: motor.set(ControlMode.Position, angle, timeout). Timeout value of 0 means wait indefinitely, otherwise timeout in ms before the method continues.
  • The old motor.enable() that was called after setting the angle is gone - not sure what happened there.
  • setFeedbackDevice is now configSelectedFeedbackSensor(FeedbackSensor.QuadEncoder, 0, 0)
  • setEncPosition is now setSelectedSensorPosition(value, 0, 0)
  • getEncPosition() is now getSelectedSensorPosition(0)
Logic changes
  • Controllers now operate in “Native” units. Before, setting the steer motor was done in units of 0-1 (0 is forward, 0.5 Is for 180 degrees, 1 for 360 degrees). There was another method to configure the number of “ticks” for the encoder to make full rotation. In the new code, you can’t set the “ticks-per-turn” and have to use the native “ticks” when telling the motor where to point. Practically, our gear ratio for the swerve modules is 1988/1.2 or appx 1657. That means that setting the motor value to 0 will point forward, setting 414 will point 90 degrees and 828 will point at 180 degrees.
  • Encoder values are still read in “native” units: The documentation says that the units are 4096 per revolution but our experimentation shows that the same values from the encoder are returned: 1657 per revolution.
  • Encoders can be inverted: In the old library there were ways to invert the motor output but no way to invert the encoder readings. The new library allows to invert the encoder phase to match the motor direction. I haven’t tested this yet though. In addition, the motor values can be inverted, and the promise is that this will invert both motor output and encoder consistently

Motor Inversion
  • In the old libraries, Motor inversion works by calling reverseOutput() and reverseSensor(). These had to be called together with the same value to ensure that the shouldReverse() method will work properly. reverseSensor, though, did not reverse the readout from the QuadEncoders and these had to be reversed in software (e.g. in the CanTalonSwerveEclosure).
  • In the new version, the method setSensorPhase() in meant to invert the sensor consistently with the motor (e.g. making the values increase clockwise instead of counter clockwise) and invertMotor() is meant to reverse the motor direction (together with the correct sensor direction) to effectively reverse the system direction. We were not able to make this work. In the end, we created reverseMotor() and reverseSensor() in software to reverse the direction of the steer motor and ignored the two CTRe provided methods.
« Last Edit: January 20, 2018, 04:18:44 PM by ohad z »