:py:mod:`phoenix6.controls.dynamic_motion_magic_expo_voltage` ============================================================= .. py:module:: phoenix6.controls.dynamic_motion_magic_expo_voltage Module Contents --------------- .. py:class:: DynamicMotionMagicExpoVoltage(position: phoenix6.units.rotation, k_v: phoenix6.units.volts_per_rotation_per_second, k_a: phoenix6.units.volts_per_rotation_per_second_squared, velocity: phoenix6.units.rotations_per_second = 0, enable_foc: bool = True, feed_forward: phoenix6.units.volt = 0.0, slot: int = 0, override_brake_dur_neutral: bool = False, limit_forward_motion: bool = False, limit_reverse_motion: bool = False, ignore_hardware_limits: bool = False, ignore_software_limits: bool = False, use_timesync: bool = False) Requires Phoenix Pro and CANivore; 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. :param position: Position to drive toward in rotations. :type position: rotation :param k_v: 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. :type k_v: volts_per_rotation_per_second :param k_a: 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. :type k_a: volts_per_rotation_per_second_squared :param velocity: Cruise velocity for profiling. The signage does not matter as the device will use the absolute value for profile generation. Setting this to 0 will allow the profile to run to the max possible velocity based on Expo_kV. :type velocity: rotations_per_second :param enable_foc: Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see 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. :type enable_foc: bool :param feed_forward: Feedforward to apply in volts. This is added to the output of the onboard feedforward terms. :type feed_forward: volt :param slot: Select which gains are applied by selecting the slot. Use the configuration api to set the gain values for the selected slot before enabling this feature. Slot must be within [0,2]. :type slot: int :param override_brake_dur_neutral: Set to true to static-brake the rotor when output is zero (or within deadband). Set to false to use the NeutralMode configuration setting (default). This flag exists to provide the fundamental behavior of this control when output is zero, which is to provide 0V to the motor. :type override_brake_dur_neutral: bool :param limit_forward_motion: Set to true to force forward limiting. This allows users to use other limit switch sensors connected to robot controller. This also allows use of active sensors that require external power. :type limit_forward_motion: bool :param limit_reverse_motion: Set to true to force reverse limiting. This allows users to use other limit switch sensors connected to robot controller. This also allows use of active sensors that require external power. :type limit_reverse_motion: bool :param ignore_hardware_limits: 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. :type ignore_hardware_limits: bool :param ignore_software_limits: 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. :type ignore_software_limits: bool :param use_timesync: 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. :type use_timesync: bool .. py:property:: name :type: str Gets the name of this control request. :returns: Name of the control request :rtype: str .. py:property:: control_info :type: dict Gets information about this control request. :returns: Dictonary of control parameter names and corresponding applied values :rtype: dict .. py:attribute:: update_freq_hz :type: phoenix6.units.hertz :value: '100' The frequency at which this control will update. This is designated in Hertz, with a minimum of 20 Hz (every 50 ms) and a maximum of 1000 Hz (every 1 ms). Some update frequencies are not supported and will be promoted up to the next highest supported frequency. If this field is set to 0 Hz, the control request will be sent immediately as a one-shot frame. This may be useful for advanced applications that require outputs to be synchronized with data acquisition. In this case, we recommend not exceeding 50 ms between control calls. .. py:attribute:: position Position to drive toward in rotations. - Units: rotations .. py:attribute:: k_v 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. - Units: V/rps .. py:attribute:: k_a 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. - Units: V/rps² .. py:attribute:: velocity :value: '0' Cruise velocity for profiling. The signage does not matter as the device will use the absolute value for profile generation. Setting this to 0 will allow the profile to run to the max possible velocity based on Expo_kV. - Units: rotations per second .. py:attribute:: enable_foc :value: 'True' Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see 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. .. py:attribute:: feed_forward :value: '0.0' Feedforward to apply in volts. This is added to the output of the onboard feedforward terms. - Units: Volts .. py:attribute:: slot :value: '0' Select which gains are applied by selecting the slot. Use the configuration api to set the gain values for the selected slot before enabling this feature. Slot must be within [0,2]. .. py:attribute:: override_brake_dur_neutral :value: 'False' Set to true to static-brake the rotor when output is zero (or within deadband). Set to false to use the NeutralMode configuration setting (default). This flag exists to provide the fundamental behavior of this control when output is zero, which is to provide 0V to the motor. .. py:attribute:: limit_forward_motion :value: 'False' Set to true to force forward limiting. This allows users to use other limit switch sensors connected to robot controller. This also allows use of active sensors that require external power. .. py:attribute:: limit_reverse_motion :value: 'False' Set to true to force reverse limiting. This allows users to use other limit switch sensors connected to robot controller. This also allows use of active sensors that require external power. .. py:attribute:: ignore_hardware_limits :value: 'False' 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. .. py:attribute:: ignore_software_limits :value: 'False' 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. .. py:attribute:: use_timesync :value: 'False' 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. .. py:method:: with_position(new_position: phoenix6.units.rotation) -> Self Modifies this Control Request's position parameter and returns itself for method-chaining and easier to use request API. Position to drive toward in rotations. - Units: rotations :param new_position: Parameter to modify :type new_position: rotation :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_k_v(new_k_v: phoenix6.units.volts_per_rotation_per_second) -> Self Modifies this Control Request's k_v parameter and returns itself for method-chaining and easier to use request API. 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. - Units: V/rps :param new_k_v: Parameter to modify :type new_k_v: volts_per_rotation_per_second :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_k_a(new_k_a: phoenix6.units.volts_per_rotation_per_second_squared) -> Self Modifies this Control Request's k_a parameter and returns itself for method-chaining and easier to use request API. 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. - Units: V/rps² :param new_k_a: Parameter to modify :type new_k_a: volts_per_rotation_per_second_squared :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_velocity(new_velocity: phoenix6.units.rotations_per_second) -> Self Modifies this Control Request's velocity parameter and returns itself for method-chaining and easier to use request API. Cruise velocity for profiling. The signage does not matter as the device will use the absolute value for profile generation. Setting this to 0 will allow the profile to run to the max possible velocity based on Expo_kV. - Units: rotations per second :param new_velocity: Parameter to modify :type new_velocity: rotations_per_second :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_enable_foc(new_enable_foc: bool) -> Self Modifies this Control Request's enable_foc parameter and returns itself for method-chaining and easier to use request API. Set to true to use FOC commutation (requires Phoenix Pro), which increases peak power by ~15% on supported devices (see 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. :param new_enable_foc: Parameter to modify :type new_enable_foc: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_feed_forward(new_feed_forward: phoenix6.units.volt) -> Self Modifies this Control Request's feed_forward parameter and returns itself for method-chaining and easier to use request API. Feedforward to apply in volts. This is added to the output of the onboard feedforward terms. - Units: Volts :param new_feed_forward: Parameter to modify :type new_feed_forward: volt :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_slot(new_slot: int) -> Self Modifies this Control Request's slot parameter and returns itself for method-chaining and easier to use request API. Select which gains are applied by selecting the slot. Use the configuration api to set the gain values for the selected slot before enabling this feature. Slot must be within [0,2]. :param new_slot: Parameter to modify :type new_slot: int :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_override_brake_dur_neutral(new_override_brake_dur_neutral: bool) -> Self Modifies this Control Request's override_brake_dur_neutral parameter and returns itself for method-chaining and easier to use request API. Set to true to static-brake the rotor when output is zero (or within deadband). Set to false to use the NeutralMode configuration setting (default). This flag exists to provide the fundamental behavior of this control when output is zero, which is to provide 0V to the motor. :param new_override_brake_dur_neutral: Parameter to modify :type new_override_brake_dur_neutral: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_limit_forward_motion(new_limit_forward_motion: bool) -> Self Modifies this Control Request's limit_forward_motion parameter and returns itself for method-chaining and easier to use request API. Set to true to force forward limiting. This allows users to use other limit switch sensors connected to robot controller. This also allows use of active sensors that require external power. :param new_limit_forward_motion: Parameter to modify :type new_limit_forward_motion: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_limit_reverse_motion(new_limit_reverse_motion: bool) -> Self Modifies this Control Request's limit_reverse_motion parameter and returns itself for method-chaining and easier to use request API. Set to true to force reverse limiting. This allows users to use other limit switch sensors connected to robot controller. This also allows use of active sensors that require external power. :param new_limit_reverse_motion: Parameter to modify :type new_limit_reverse_motion: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_ignore_hardware_limits(new_ignore_hardware_limits: bool) -> Self Modifies this Control Request's ignore_hardware_limits parameter and returns itself for method-chaining and easier to use request API. 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. :param new_ignore_hardware_limits: Parameter to modify :type new_ignore_hardware_limits: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_ignore_software_limits(new_ignore_software_limits: bool) -> Self Modifies this Control Request's ignore_software_limits parameter and returns itself for method-chaining and easier to use request API. 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. :param new_ignore_software_limits: Parameter to modify :type new_ignore_software_limits: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_use_timesync(new_use_timesync: bool) -> Self Modifies this Control Request's use_timesync parameter and returns itself for method-chaining and easier to use request API. 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. :param new_use_timesync: Parameter to modify :type new_use_timesync: bool :returns: Itself :rtype: DynamicMotionMagicExpoVoltage .. py:method:: with_update_freq_hz(new_update_freq_hz: phoenix6.units.hertz) -> Self Sets the frequency at which this control will update. This is designated in Hertz, with a minimum of 20 Hz (every 50 ms) and a maximum of 1000 Hz (every 1 ms). Some update frequencies are not supported and will be promoted up to the next highest supported frequency. If this field is set to 0 Hz, the control request will be sent immediately as a one-shot frame. This may be useful for advanced applications that require outputs to be synchronized with data acquisition. In this case, we recommend not exceeding 50 ms between control calls. :param new_update_freq_hz: Parameter to modify :type new_update_freq_hz: hertz :returns: Itself :rtype: DynamicMotionMagicExpoVoltage