|
CTRE Phoenix 6 C++ 26.3.0
|
Contains all control functions available for devices that support Talon controls. More...
#include <ctre/phoenix6/hardware/traits/HasTalonControls.hpp>
Public Member Functions | |
| virtual | ~HasTalonControls ()=default |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DutyCycleOut const &request)=0 |
| Request a specified motor duty cycle. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::VoltageOut const &request)=0 |
| Request a specified voltage. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::PositionDutyCycle const &request)=0 |
| Request PID to target position with duty cycle feedforward. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::PositionVoltage const &request)=0 |
| Request PID to target position with voltage feedforward. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::VelocityDutyCycle const &request)=0 |
| Request PID to target velocity with duty cycle feedforward. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::VelocityVoltage const &request)=0 |
| Request PID to target velocity with voltage feedforward. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::MotionMagicDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final position using a motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::MotionMagicVoltage const &request)=0 |
| Requests Motion Magic® to target a final position using a motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::MotionMagicVelocityDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final velocity using a motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::MotionMagicVelocityVoltage const &request)=0 |
| Requests Motion Magic® to target a final velocity using a motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::MotionMagicExpoDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final position using an exponential motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::MotionMagicExpoVoltage const &request)=0 |
| Requests Motion Magic® to target a final position using an exponential motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DynamicMotionMagicDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final position using a motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DynamicMotionMagicVoltage const &request)=0 |
| Requests Motion Magic® to target a final position using a motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DynamicMotionMagicExpoDutyCycle const &request)=0 |
| Requests Motion Magic® Expo to target a final position using an exponential motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DynamicMotionMagicExpoVoltage const &request)=0 |
| Requests Motion Magic® Expo to target a final position using an exponential motion profile. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialDutyCycle const &request)=0 |
| Request a specified motor duty cycle with a differential position closed-loop. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialVoltage const &request)=0 |
| Request a specified voltage with a differential position closed-loop. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialPositionDutyCycle const &request)=0 |
| Request PID to target position with a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialPositionVoltage const &request)=0 |
| Request PID to target position with a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialVelocityDutyCycle const &request)=0 |
| Request PID to target velocity with a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialVelocityVoltage const &request)=0 |
| Request PID to target velocity with a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialMotionMagicDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final position using a motion profile, and PID to a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialMotionMagicVoltage const &request)=0 |
| Requests Motion Magic® to target a final position using a motion profile, and PID to a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialMotionMagicExpoDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final position using an exponential motion profile, and PID to a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialMotionMagicExpoVoltage const &request)=0 |
| Requests Motion Magic® to target a final position using an exponential motion profile, and PID to a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialMotionMagicVelocityDutyCycle const &request)=0 |
| Requests Motion Magic® to target a final velocity using a motion profile, and PID to a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialMotionMagicVelocityVoltage const &request)=0 |
| Requests Motion Magic® to target a final velocity using a motion profile, and PID to a differential position setpoint. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::Follower const &request)=0 |
| Follow the motor output of another Talon. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::StrictFollower const &request)=0 |
| Follow the motor output of another Talon while ignoring the leader's invert setting. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialFollower const &request)=0 |
| Follow the differential motor output of another Talon. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::DifferentialStrictFollower const &request)=0 |
| Follow the differential motor output of another Talon while ignoring the leader's invert setting. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::StaticBrake const &request)=0 |
| Applies full neutral-brake by shorting motor leads together. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::NeutralOut const &request)=0 |
| Request neutral output of actuator. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::CoastOut const &request)=0 |
| Request coast neutral output of actuator. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_DutyCycleOut_Position const &request)=0 |
| Differential control with duty cycle average target and position difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_PositionDutyCycle_Position const &request)=0 |
| Differential control with position average target and position difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VelocityDutyCycle_Position const &request)=0 |
| Differential control with velocity average target and position difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicDutyCycle_Position const &request)=0 |
| Differential control with Motion Magic® average target and position difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicExpoDutyCycle_Position const &request)=0 |
| Differential control with Motion Magic® Expo average target and position difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVelocityDutyCycle_Position const &request)=0 |
| Differential control with Motion Magic® Velocity average target and position difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_DutyCycleOut_Velocity const &request)=0 |
| Differential control with duty cycle average target and velocity difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_PositionDutyCycle_Velocity const &request)=0 |
| Differential control with position average target and velocity difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VelocityDutyCycle_Velocity const &request)=0 |
| Differential control with velocity average target and velocity difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicDutyCycle_Velocity const &request)=0 |
| Differential control with Motion Magic® average target and velocity difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicExpoDutyCycle_Velocity const &request)=0 |
| Differential control with Motion Magic® Expo average target and velocity difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVelocityDutyCycle_Velocity const &request)=0 |
| Differential control with Motion Magic® Velocity average target and velocity difference target using duty cycle control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_DutyCycleOut_Open const &request)=0 |
| Differential control with duty cycle average target and duty cycle difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_PositionDutyCycle_Open const &request)=0 |
| Differential control with position average target and duty cycle difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VelocityDutyCycle_Open const &request)=0 |
| Differential control with velocity average target and duty cycle difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicDutyCycle_Open const &request)=0 |
| Differential control with Motion Magic® average target and duty cycle difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicExpoDutyCycle_Open const &request)=0 |
| Differential control with Motion Magic® Expo average target and duty cycle difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVelocityDutyCycle_Open const &request)=0 |
| Differential control with Motion Magic® Velocity average target and duty cycle difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VoltageOut_Position const &request)=0 |
| Differential control with voltage average target and position difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_PositionVoltage_Position const &request)=0 |
| Differential control with position average target and position difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VelocityVoltage_Position const &request)=0 |
| Differential control with velocity average target and position difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVoltage_Position const &request)=0 |
| Differential control with Motion Magic® average target and position difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicExpoVoltage_Position const &request)=0 |
| Differential control with Motion Magic® Expo average target and position difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVelocityVoltage_Position const &request)=0 |
| Differential control with Motion Magic® Velocity average target and position difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VoltageOut_Velocity const &request)=0 |
| Differential control with voltage average target and velocity difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_PositionVoltage_Velocity const &request)=0 |
| Differential control with position average target and velocity difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VelocityVoltage_Velocity const &request)=0 |
| Differential control with velocity average target and velocity difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVoltage_Velocity const &request)=0 |
| Differential control with Motion Magic® average target and velocity difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicExpoVoltage_Velocity const &request)=0 |
| Differential control with Motion Magic® Expo average target and velocity difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVelocityVoltage_Velocity const &request)=0 |
| Differential control with Motion Magic® Velocity average target and velocity difference target using voltage control. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VoltageOut_Open const &request)=0 |
| Differential control with voltage average target and voltage difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_PositionVoltage_Open const &request)=0 |
| Differential control with position average target and voltage difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_VelocityVoltage_Open const &request)=0 |
| Differential control with velocity average target and voltage difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVoltage_Open const &request)=0 |
| Differential control with Motion Magic® average target and voltage difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicExpoVoltage_Open const &request)=0 |
| Differential control with Motion Magic® Expo average target and voltage difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::compound::Diff_MotionMagicVelocityVoltage_Open const &request)=0 |
| Differential control with Motion Magic® Velocity average target and voltage difference target. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::EmptyControl const &request)=0 |
| Apply a generic empty control used to do nothing. | |
| virtual ctre::phoenix::StatusCode | SetControl (controls::ControlRequest const &request)=0 |
| Control device with generic control request object. | |
Public Member Functions inherited from ctre::phoenix6::hardware::traits::CommonDevice | |
| virtual | ~CommonDevice ()=default |
| virtual int | GetDeviceID () const =0 |
| virtual CANBus | GetNetwork () const =0 |
| virtual uint64_t | GetDeviceHash () const =0 |
| Gets a number unique for this device's hardware type and ID. | |
| virtual std::shared_ptr< controls::ControlRequest const > | GetAppliedControl () const =0 |
| Get the latest applied control. | |
| virtual std::shared_ptr< controls::ControlRequest > | GetAppliedControl ()=0 |
| Get the latest applied control. | |
| virtual bool | HasResetOccurred ()=0 |
| virtual std::function< bool()> | GetResetOccurredChecker () const =0 |
| virtual bool | IsConnected (units::second_t maxLatencySeconds=500_ms)=0 |
| Returns whether the device is still connected to the robot. | |
| virtual ctre::phoenix::StatusCode | OptimizeBusUtilization (units::frequency::hertz_t optimizedFreqHz=4_Hz, units::time::second_t timeoutSeconds=100_ms)=0 |
| Optimizes the device's bus utilization by reducing the update frequencies of its status signals. | |
| virtual ctre::phoenix::StatusCode | ResetSignalFrequencies (units::time::second_t timeoutSeconds=100_ms)=0 |
| Resets the update frequencies of all the device's status signals to the defaults. | |
Contains all control functions available for devices that support Talon controls.
|
virtualdefault |
|
pure virtual |
Request coast neutral output of actuator.
The bridge is disabled and the rotor is allowed to coast.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with duty cycle average target and duty cycle difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with duty cycle average target and position difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with duty cycle average target and velocity difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® average target and duty cycle difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® average target and position difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® average target and velocity difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Expo average target and duty cycle difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Expo average target and position difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Expo average target and velocity difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Expo average target and voltage difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Expo average target and position difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Expo average target and velocity difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Velocity average target and duty cycle difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Velocity average target and position difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Velocity average target and velocity difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Velocity average target and voltage difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Velocity average target and position difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® Velocity average target and velocity difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® average target and voltage difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® average target and position difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with Motion Magic® average target and velocity difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with position average target and duty cycle difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with position average target and position difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with position average target and velocity difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with position average target and voltage difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with position average target and position difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with position average target and velocity difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with velocity average target and duty cycle difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with velocity average target and position difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with velocity average target and velocity difference target using duty cycle control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with velocity average target and voltage difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with velocity average target and position difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with velocity average target and velocity difference target using voltage control.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with voltage average target and voltage difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with voltage average target and position difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Differential control with voltage average target and velocity difference target.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Control device with generic control request object.
User must make sure the specified object is castable to a valid control request, otherwise this function will fail at run-time and return the NotSupported StatusCode
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, ctre::phoenix6::hardware::traits::CommonTalon, and ctre::phoenix6::hardware::traits::CommonTalonWithFOC.
|
pure virtual |
Request a specified motor duty cycle with a differential position closed-loop.
This control mode will output a proportion of the supplied voltage which is supplied by the user. It will also set the motor's differential position setpoint to the specified position.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Follow the differential motor output of another Talon.
If Talon is in torque control, the differential torque is copied - which will increase the total torque applied. If Talon is in duty cycle output control, the differential duty cycle is matched. If Talon is in voltage output control, the differential motor voltage is matched. Motor direction either matches leader's configured direction or opposes it based on the MotorAlignment.
The leader must enable its DifferentialOutput status signal. The update rate of the status signal determines the update rate of the follower's output and should be no slower than 20 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using a motion profile, and PID to a differential position setpoint.
Motion Magic® produces a motion profile in real-time while attempting to honor the Cruise Velocity, Acceleration, and (optional) Jerk specified via the Motion Magic® configuration values. This control mode does not use the Expo_kV or Expo_kA configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using an exponential motion profile, and PID to a differential position setpoint.
Motion Magic® Expo produces a motion profile in real-time while attempting to honor the Cruise Velocity (optional) and the mechanism kV and kA, specified via the Motion Magic® configuration values. Note that unlike the slot gains, the Expo_kV and Expo_kA configs are always in output units of Volts.
Setting Cruise Velocity to 0 will allow the profile to run to the max possible velocity based on Expo_kV. This control mode does not use the Acceleration or Jerk configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using an exponential motion profile, and PID to a differential position setpoint.
Motion Magic® Expo produces a motion profile in real-time while attempting to honor the Cruise Velocity (optional) and the mechanism kV and kA, specified via the Motion Magic® configuration values. Note that unlike the slot gains, the Expo_kV and Expo_kA configs are always in output units of Volts.
Setting Cruise Velocity to 0 will allow the profile to run to the max possible velocity based on Expo_kV. This control mode does not use the Acceleration or Jerk configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final velocity using a motion profile, and PID to a differential position setpoint.
This allows smooth transitions between velocity set points.
Motion Magic® Velocity produces a motion profile in real-time while attempting to honor the specified Acceleration and (optional) Jerk. This control mode does not use the CruiseVelocity, Expo_kV, or Expo_kA configs.
Acceleration and jerk are specified in the Motion Magic® persistent configuration values. If Jerk is set to zero, Motion Magic® will produce a trapezoidal acceleration profile.
Target velocity can also be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final velocity using a motion profile, and PID to a differential position setpoint.
This allows smooth transitions between velocity set points.
Motion Magic® Velocity produces a motion profile in real-time while attempting to honor the specified Acceleration and (optional) Jerk. This control mode does not use the CruiseVelocity, Expo_kV, or Expo_kA configs.
Acceleration and jerk are specified in the Motion Magic® persistent configuration values. If Jerk is set to zero, Motion Magic® will produce a trapezoidal acceleration profile.
Target velocity can also be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using a motion profile, and PID to a differential position setpoint.
Motion Magic® produces a motion profile in real-time while attempting to honor the Cruise Velocity, Acceleration, and (optional) Jerk specified via the Motion Magic® configuration values. This control mode does not use the Expo_kV or Expo_kA configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target position with a differential position setpoint.
This control mode will set the motor's position setpoint to the position specified by the user. It will also set the motor's differential position setpoint to the specified position.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target position with a differential position setpoint.
This control mode will set the motor's position setpoint to the position specified by the user. It will also set the motor's differential position setpoint to the specified position.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Follow the differential motor output of another Talon while ignoring the leader's invert setting.
If Talon is in torque control, the differential torque is copied - which will increase the total torque applied. If Talon is in duty cycle output control, the differential duty cycle is matched. If Talon is in voltage output control, the differential motor voltage is matched. Motor direction is strictly determined by the configured invert and not the leader. If you want motor direction to match or oppose the leader, use DifferentialFollower instead.
The leader must enable its DifferentialOutput status signal. The update rate of the status signal determines the update rate of the follower's output and should be no slower than 20 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target velocity with a differential position setpoint.
This control mode will set the motor's velocity setpoint to the velocity specified by the user. It will also set the motor's differential position setpoint to the specified position.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target velocity with a differential position setpoint.
This control mode will set the motor's velocity setpoint to the velocity specified by the user. It will also set the motor's differential position setpoint to the specified position.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request a specified voltage with a differential position closed-loop.
This control mode will attempt to apply the specified voltage to the motor. If the supply voltage is below the requested voltage, the motor controller will output the supply voltage. It will also set the motor's differential position setpoint to the specified position.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request a specified motor duty cycle.
This control mode will output a proportion of the supplied voltage which is supplied by the user.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using a motion profile.
This dynamic request allows runtime changes to Cruise Velocity, Acceleration, and (optional) Jerk. Users can optionally provide a duty cycle feedforward.
Motion Magic® produces a motion profile in real-time while attempting to honor the specified Cruise Velocity, Acceleration, and (optional) Jerk. This control mode does not use the Expo_kV or Expo_kA configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
Jerk: Jerk for profiling. The signage does not matter as the device will use the absolute value for profile generation.
Jerk is optional; if this is set to zero, then Motion Magic® will not apply a Jerk limit.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® Expo to target a final position using an exponential motion profile.
This dynamic request allows runtime changes to the profile kV, kA, and (optional) Cruise Velocity. Users can optionally provide a duty cycle feedforward.
Motion Magic® Expo produces a motion profile in real-time while attempting to honor the specified Cruise Velocity (optional) and the mechanism kV and kA. Note that unlike the slot gains, the Expo_kV and Expo_kA parameters are always in output units of Volts.
Setting the Cruise Velocity to 0 will allow the profile to run to the max possible velocity based on Expo_kV. This control mode does not use the Acceleration or Jerk configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
kV: Mechanism kV for profiling. Unlike the kV slot gain, this is always in units of V/rps.
This represents the amount of voltage necessary to hold a velocity. In terms of the Motion Magic® Expo profile, a higher kV results in a slower maximum velocity.
kA: Mechanism kA for profiling. Unlike the kA slot gain, this is always in units of V/rps².
This represents the amount of voltage necessary to achieve an acceleration. In terms of the Motion Magic® Expo profile, a higher kA results in a slower acceleration.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® Expo to target a final position using an exponential motion profile.
This dynamic request allows runtime changes to the profile kV, kA, and (optional) Cruise Velocity. Users can optionally provide a voltage feedforward.
Motion Magic® Expo produces a motion profile in real-time while attempting to honor the specified Cruise Velocity (optional) and the mechanism kV and kA. Note that unlike the slot gains, the Expo_kV and Expo_kA parameters are always in output units of Volts.
Setting the Cruise Velocity to 0 will allow the profile to run to the max possible velocity based on Expo_kV. This control mode does not use the Acceleration or Jerk configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
kV: Mechanism kV for profiling. Unlike the kV slot gain, this is always in units of V/rps.
This represents the amount of voltage necessary to hold a velocity. In terms of the Motion Magic® Expo profile, a higher kV results in a slower maximum velocity.
kA: Mechanism kA for profiling. Unlike the kA slot gain, this is always in units of V/rps².
This represents the amount of voltage necessary to achieve an acceleration. In terms of the Motion Magic® Expo profile, a higher kA results in a slower acceleration.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using a motion profile.
This dynamic request allows runtime changes to Cruise Velocity, Acceleration, and (optional) Jerk. Users can optionally provide a voltage feedforward.
Motion Magic® produces a motion profile in real-time while attempting to honor the specified Cruise Velocity, Acceleration, and (optional) Jerk. This control mode does not use the Expo_kV or Expo_kA configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
Jerk: Jerk for profiling. The signage does not matter as the device will use the absolute value for profile generation.
Jerk is optional; if this is set to zero, then Motion Magic® will not apply a Jerk limit.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Apply a generic empty control used to do nothing.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, ctre::phoenix6::hardware::traits::CommonTalon, and ctre::phoenix6::hardware::traits::CommonTalonWithFOC.
|
pure virtual |
Follow the motor output of another Talon.
The follower will atomically change its output type when it receives the leader's latest output status signal (DutyCycle, MotorVoltage, TorqueCurrent). If Talon is in torque control, the torque is copied - which will increase the total torque applied. If Talon is in duty cycle output control, the duty cycle is matched. If Talon is in voltage output control, the motor voltage is matched. Motor direction either matches the leader's configured direction or opposes it based on the MotorAlignment.
The leader must ensure the status signal corresponding to its control output type (DutyCycle, MotorVoltage, TorqueCurrent) is enabled. The update rate of the status signal determines the update rate of the follower's output and should be no slower than 20 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using a motion profile.
Users can optionally provide a duty cycle feedforward.
Motion Magic® produces a motion profile in real-time while attempting to honor the Cruise Velocity, Acceleration, and (optional) Jerk specified via the Motion Magic® configuration values. This control mode does not use the Expo_kV or Expo_kA configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using an exponential motion profile.
Users can optionally provide a duty cycle feedforward.
Motion Magic® Expo produces a motion profile in real-time while attempting to honor the Cruise Velocity (optional) and the mechanism kV and kA, specified via the Motion Magic® configuration values. Note that unlike the slot gains, the Expo_kV and Expo_kA configs are always in output units of Volts.
Setting Cruise Velocity to 0 will allow the profile to run to the max possible velocity based on Expo_kV. This control mode does not use the Acceleration or Jerk configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using an exponential motion profile.
Users can optionally provide a voltage feedforward.
Motion Magic® Expo produces a motion profile in real-time while attempting to honor the Cruise Velocity (optional) and the mechanism kV and kA, specified via the Motion Magic® configuration values. Note that unlike the slot gains, the Expo_kV and Expo_kA configs are always in output units of Volts.
Setting Cruise Velocity to 0 will allow the profile to run to the max possible velocity based on Expo_kV. This control mode does not use the Acceleration or Jerk configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final velocity using a motion profile.
This allows smooth transitions between velocity set points. Users can optionally provide a duty cycle feedforward.
Motion Magic® Velocity produces a motion profile in real-time while attempting to honor the specified Acceleration and (optional) Jerk. This control mode does not use the CruiseVelocity, Expo_kV, or Expo_kA configs.
If the specified acceleration is zero, the Acceleration under Motion Magic® configuration parameter is used instead. This allows for runtime adjustment of acceleration for advanced users. Jerk is also specified in the Motion Magic® persistent configuration values. If Jerk is set to zero, Motion Magic® will produce a trapezoidal acceleration profile.
Target velocity can also be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is duty cycle based, so relevant closed-loop gains will use fractional duty cycle for the numerator: +1.0 represents full forward output.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final velocity using a motion profile.
This allows smooth transitions between velocity set points. Users can optionally provide a voltage feedforward.
Motion Magic® Velocity produces a motion profile in real-time while attempting to honor the specified Acceleration and (optional) Jerk. This control mode does not use the CruiseVelocity, Expo_kV, or Expo_kA configs.
If the specified acceleration is zero, the Acceleration under Motion Magic® configuration parameter is used instead. This allows for runtime adjustment of acceleration for advanced users. Jerk is also specified in the Motion Magic® persistent configuration values. If Jerk is set to zero, Motion Magic® will produce a trapezoidal acceleration profile.
Target velocity can also be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Requests Motion Magic® to target a final position using a motion profile.
Users can optionally provide a voltage feedforward.
Motion Magic® produces a motion profile in real-time while attempting to honor the Cruise Velocity, Acceleration, and (optional) Jerk specified via the Motion Magic® configuration values. This control mode does not use the Expo_kV or Expo_kA configs.
Target position can be changed on-the-fly and Motion Magic® will do its best to adjust the profile. This control mode is voltage-based, so relevant closed-loop gains will use Volts for the numerator.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request neutral output of actuator.
The applied brake type is determined by the NeutralMode configuration.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target position with duty cycle feedforward.
This control mode will set the motor's position setpoint to the position specified by the user. In addition, it will apply an additional duty cycle as an arbitrary feedforward value.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target position with voltage feedforward.
This control mode will set the motor's position setpoint to the position specified by the user. In addition, it will apply an additional voltage as an arbitrary feedforward value.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Applies full neutral-brake by shorting motor leads together.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Follow the motor output of another Talon while ignoring the leader's invert setting.
The follower will atomically change its output type when it receives the leader's latest output status signal (DutyCycle, MotorVoltage, TorqueCurrent). If Talon is in torque control, the torque is copied - which will increase the total torque applied. If Talon is in duty cycle output control, the duty cycle is matched. If Talon is in voltage output control, the motor voltage is matched. Motor direction is strictly determined by the configured invert and not the leader. If you want motor direction to match or oppose the leader, use Follower instead.
The leader must ensure the status signal corresponding to its control output type (DutyCycle, MotorVoltage, TorqueCurrent) is enabled. The update rate of the status signal determines the update rate of the follower's output and should be no slower than 20 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target velocity with duty cycle feedforward.
This control mode will set the motor's velocity setpoint to the velocity specified by the user. In addition, it will apply an additional voltage as an arbitrary feedforward value.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request PID to target velocity with voltage feedforward.
This control mode will set the motor's velocity setpoint to the velocity specified by the user. In addition, it will apply an additional voltage as an arbitrary feedforward value.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.
|
pure virtual |
Request a specified voltage.
This control mode will attempt to apply the specified voltage to the motor. If the supply voltage is below the requested voltage, the motor controller will output the supply voltage.
EnableFOC: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see hardware::traits::SupportsFOC). Set to false to use trapezoidal commutation.
FOC improves motor performance by leveraging torque (current) control. However, this may be inconvenient for applications that require specifying duty cycle or voltage. CTR-Electronics has developed a hybrid method that combines the performances gains of FOC while still allowing applications to provide duty cycle or voltage demand. This not to be confused with simple sinusoidal control or phase voltage control which lacks the performance gains.
IgnoreHardwareLimits: Set to true to ignore hardware limit switches and the LimitForwardMotion and LimitReverseMotion parameters, instead allowing motion.
This can be useful on mechanisms such as an intake/feeder, where a limit switch stops motion while intaking but should be ignored when feeding to a shooter.
The hardware limit faults and Forward/ReverseLimit signals will still report the values of the limit switches regardless of this parameter.
IgnoreSoftwareLimits: Set to true to ignore software limits, instead allowing motion.
This can be useful when calibrating the zero point of a mechanism such as an elevator.
The software limit faults will still report the values of the software limits regardless of this parameter.
UseTimesync: Set to true to delay applying this control request until a timesync boundary (requires Phoenix Pro and CANivore). This eliminates the impact of nondeterministic network delays in exchange for a larger but deterministic control latency.
This requires setting the ControlTimesyncFreqHz config in MotorOutputConfigs. Additionally, when this is enabled, the UpdateFreqHz of this request should be set to 0 Hz.
| request | Control object to request of the device |
Implemented in ctre::phoenix6::hardware::core::CoreTalonFX, ctre::phoenix6::hardware::core::CoreTalonFXS, and ctre::phoenix6::hardware::traits::CommonTalon.