FtcRobotController SDK

OnBot Java is an integrated development environment (IDE) served directly by the Robot Controller. It allows you to create, edit, and build OpModes dynamically using only a JavaScript-enabled web browser (Google Chrome is recommended).

Unlike traditional Android Studio development, OnBot Java:

• Does NOT require Android Studio.
• Saves OpModes directly on the Robot Controller Android device.
• Features web-based programming and management that is "always on" (you do not need to put the Robot Controller into a specific programming mode).

Known Limitations of Autocomplete: The OnBot Java autocomplete function currently does not support:

• Access via this or super keywords.
• Members of the superclass that are not overridden.
• Methods provided in the current class.
• Inner classes.
• Casted objects.
• Objects coming from parenthetically enclosed expressions.

Introduced in version 8.2, VisionPortal is the new entry point for both AprilTag and TensorFlow Object Detection (TFOD) processing. It replaces older vision methods and provides a unified way to handle computer vision tasks.

Note: This API may be subject to change for final kickoff releases.

Key features include:

• Support for detecting AprilTags.
• Support for webcam camera controls in Blocks.
• Integration with TensorFlow dependencies.
• New sample OpModes for AprilTag driving and exposure optimization.

The SDK provides a blackboard member within the OpMode class. This allows you to maintain state between different OpModes during a single robot session. Note that this state is cleared when the robot is reset.

To use it, refer to the ConceptBlackboard sample program for implementation details.

For certain motors (including AndyMark, goBILDA, and TETRIX configurations), the SDK supports PIDF control. When using RUN_USING_ENCODERS or RUN_TO_POSITION modes, PIDF adds Feedforward control to the basic PID loop.

Feedforward helps the controller "anticipate" the required control voltage to reach a new speed set-point, rather than waiting for an integrated error to accumulate. This results in more responsive and stable speed control, especially under heavy motor loads (drag or friction).

The OpMode class provides an event-driven programming model.

• Required Methods: Users must override both init() and loop().
• Optional Methods: The start() and stop() methods are optional.
• Lifecycle: The init() method is triggered before the start() method. In later versions, init() is triggered when the user presses the 'INIT' button on the Driver Station.

Starting with version 8.0, I2C devices are initialized only when they are first retrieved from the HardwareMap. To prevent performance issues or hangs during the robot's operation, you must follow this pattern:

1. Declare variables for every hardware device the OpMode will use.
2. Assign values to these variables by calling hardwareMap.get() during the Init phase of your OpMode.
3. Avoid retrieving devices during the Run phase, as this can cause the OpMode to briefly hang while the device initializes.

For improved motor control, the SDK supports PIDF coefficients (Proportional, Integral, Derivative, and Feed Forward). This requires REV Robotics Expansion Hub firmware 1.8 or greater.

Users can utilize DcMotorEx methods to access enhanced motor control features, such as setting PIDF coefficients and motor velocity (in encoder pulses per second).

When using multiple VisionPortal instances, you can switch which camera stream is sent to the Driver Station. This is typically done during the INIT phase using the CameraStreamServer singleton.

Example logic: CameraStreamServer.getInstance().setSource(visionPortal)

As of Release 16.03.09, the FTC SDK has transitioned to a synchronous model. This is a significant change that affects how hardware interactions are handled:

• Deprecated Methods: waitOneFullHardwareCycle() and waitForNextHardwareCycle() are no longer needed and are deprecated.
• Decoupled Execution: Both runOpMode() (for LinearOpMode) and loop() (for OpMode) are now decoupled from the system's hardware read/write thread.
• Guaranteed Completion: Methods are now synchronous. For example, calling setMode(DcMotorController.RunMode.RESET_ENCODERS) for a motor guarantees that the encoder is reset by the time the method call completes.
• Legacy Modules: For NXT-compatible legacy modules, users no longer need to manually toggle between read and write modes when interacting with devices.

In version 3.0 and later (including 3.10), the setMaxSpeed and getMaxSpeed methods have been removed from the DcMotor class.

Action Required: If you are migrating an OpMode that previously used these methods, you must remove all references and calls to them.

New Approach: Instead of manual speed setting, the software now incorporates motor profiles. Users select these profiles during the robot configuration process to manage motor performance.

The REV 9-Axis IMU (REV-31-3332) is supported via the Universal IMU interface.

• Compatibility: The RevHubOrientationOnRobot class is compatible with this sensor if you treat the IMU's I2C port as if it were the Control Hub's USB ports.
• Java Class: Use Rev9AxisImuOrientationOnRobot for direct implementation.
• Blocks Support: Includes blocks for RevHubImuOrientationOnRobot.xyzOrientation and RevHubImuOrientationOnRobot.zyxOrientation.