Control requests

Duty, velocity, position, follower control, and stopping the motor.

Java 0.33.0 / firmware 2.6.6: zero duty coasts; brake is unsupported. Stator and supply current-limit settings are inactive compatibility fields and do not limit amperes. Supply current is observational; stator current is unavailable. The speed-based duty governor can reduce applied output.

A setpoint is the value you ask the motor to reach: an output percentage, speed, or position. Send commands repeatedly from your robot’s periodic code while the mechanism should run.

Duty cycle

Duty is an output fraction: 0.10 requests 10%, 1.0 requests 100%, and a negative value requests the opposite direction. Use values from −1 to +1. Finite out-of-range values are clamped and warned about; NaN and infinity are rejected. Applied duty can be smaller because ramps, limits or protection intervene.

motor.setDutyCycle(0.10);  // Positive 10% duty.
motor.set(-0.10);         // set() uses duty cycle too.

Velocity

setVelocity() takes motor-shaft speed in RPM (revolutions per minute). The library handles the conversion used to send it to the controller. Velocity control runs on the controller and requires usable gains. Do not interpret a zero request as a guaranteed active hold; coast behavior and the deadband (the range of small commands treated as zero) also apply.

motor.setVelocity(1500); // Rotor RPM; repeat periodically.

Position

setPosition() takes motor-shaft angle in radians: one full turn is 2 × Math.PI. The controller counts complete turns since startup, but loses that count when it restarts. Move the mechanism to a known reference position, called homing, before using targets that depend on previous turns.

Factory-default position gain is zero. Position entry is refused until the required gains are configured. See Closed-loop control before enabling a position mechanism.

motor.setPosition(Math.PI / 2); // +quarter rotor turn from the reference.

Follower

The Java follower uses the leader’s observed state to issue follower commands. Your robot program must keep running and receiving measurements from the leader. Following does not guarantee that two mechanically linked motors stay at exactly the same position. Current-limit settings are inactive on both motors with firmware 2.6.6.

import com.swyftrobotics.cyclone.v4.Follower;
import com.swyftrobotics.cyclone.v4.MotorAlignmentValue;

follower.setControl(new Follower(1, MotorAlignmentValue.Opposed));
// Later, before returning to direct commands:
follower.stopFollowing();

Stop and enable again

motor.disable();       // Normal disable: drop the command and coast.
// Emergency path, when needed:
motor.estop();         // Keep output stopped until released.
motor.releaseEstop();  // Release the stop; normal enable checks still apply.

Keep sending the intended command

Send the intended command each time your periodic control code runs. A CAN motion command expires after 100 ms without a refresh. The library also sends a separate enable heartbeat to show that control is still active; it does not replace repeated motion commands.

The controller also requires a live robot heartbeat that permits motor output. Driver Station disable or loss of the required heartbeat stops output. Recovered heartbeats alone do not replay the last setpoint; your program must send a fresh intended command. See connection-loss behavior for CAN and USB-C.

Restart after Driver Station disable

Firmware 1.6.9 stops output and forgets pending CAN targets on DS disable or loss of robot permission. Re-enabling DS while a trigger or stick is held must leave the motor idle. Return the inputs to neutral while enabled, then move them again. Use the Java input interlock to check the actual inputs before constructing a target.

The firmware unlocks robot control with an exact-zero duty or velocity command received after enable. That unlocking command does not energize the motor. A zero position is a destination and does not unlock control. While position/follower controls are released, send zero duty to each affected motor; only start the position request or follower after the input interlock permits it.

For an autonomous routine, deliberately begin with neutral after DS enables and before starting the planned trajectory. Existing routines that start with only a nonzero or position command will remain blocked. Do not add a blanket automatic zero before each request: that defeats the protection for held controls. Firmware cannot determine whether a target came from a physical joystick, a stored variable or an autonomous routine.