Skip to content

v2.0.0

Compare
Choose a tag to compare
@rcahoon rcahoon released this 15 Oct 08:19

This release is intended to contain the API-breaking changes for the 2022-2023 season. Further improvements and features are planned for this season, but they will be (at least mostly) backwards compatible.

The code in this release has been validated for use with the tutorial in the simulator. Further validation is required to make sure that all features will run correctly on physical robots.

This is also a pretty big release, since the repo hasn't been versioned since the 2022 competition season ended.

New Features

  • 84f4536 The user code package has been renamed to com.team766.robot (used to be called com.team766.robot.frc2020/frc2022).
    • This reduces maintenance on training materials, so we don't need to update everything at the beginning of each year.
    • We originally thought that we might have multiple robots' code contained in one git repository, but we've settled on using a separate repo for each robot, so having a unique package for each robot's code is not necessary.
  • d354930 5a5a6b8 SpeedController and CANSpeedController have been replaced by one unified interface called MotorController.
    • "MotorController" was chosen to be less misleading: motor controllers control motors, but they don't directly control speed, only the amount of voltage being applied to motors.
    • All motor controllers are now retrieved with RobotProvider.instance.getMotor (RobotProvider.instance.getCANMotor has been removed).
    • Motor controllers can either use an on-device sensor interface (such as with brushless motors or CAN speed controllers with an external sensor port like the Talon SRX) or can be configured (via the config file) to use an encoder or analog sensor attached to the RoboRIO (in which case, Position and Velocity control are processed on the RoboRIO). For PWM motor controllers that haven't been configured with a RoboRIO-attached sensor, trying to read their sensor value will return 0; trying to use Position or Velocity control will log an error.
  • 84f4536 The Robot class has been greatly simplified to make it more approachable to beginning programmers. This is also a step towards making Maroon Framework into a Maven package, instead of copying it into each repo. The following is now the entirety of the class (the rest of the code has been moved to com.team766.hal.GenericRobotMain):
package com.team766.robot;

import com.team766.robot.mechanisms.*;

public class Robot {
	// Declare mechanisms here


	public static void robotInit() {
		// Initialize mechanisms here

	}
}
public class AutonomousModes {
	public static final AutonomousMode[] AUTONOMOUS_MODES = new AutonomousMode[] {
		// Add autonomous modes here like this:
		//    new AutonomousMode("NameOfAutonomousMode", () -> new MyAutonomousProcedure()),
		//
		// If your autonomous procedure has constructor arguments, you can
		// define one or more different autonomous modes with it like this:
		//    new AutonomousMode("DriveFast", () -> new DriveStraight(1.0)),
		//    new AutonomousMode("DriveSlow", () -> new DriveStraight(0.4)),

		new AutonomousMode("DoNothing", () -> new DoNothing()),
	};
}
  • 2dfa917 In the simulator, autonomous modes will now automatically reset when the level is reloaded. This should remove the need to switch to Teleoperated mode in order to get your autonomous procedure to run from the beginning. Autonomous mode will also be reset whenever the autonomous mode picker form is submitted in the web UI.
  • 8f23131 d629d21 3abeaec Motors on the simulated robot are now emulating CAN motor controllers, rather than PID motor controllers. This means you can use Position/Velocity/etc control mode with them and read the associated encoders directly from the motor controller interface, rather than needing separate EncoderReaders (through the EncoderReader interface still works as well, for now). This should be mostly transparent to users, since CAN and PWM motor controllers how use the same interface.
  • b62ef6e Added a separate logging category for framework messages reporting Procedures starting and ending, etc. This frees up the default PROCEDURES logging category to be more useful to users trying to add logging to their Procedures (though users are encouraged to add their own logging categories whenever appropriate). 5b998a2 Mechanisms also now get their own default logging category, MECHANISMS.
  • 9d1dc83 c937482 Switch to using Google Protobuf for logging, rather than Java's object streams. This should resolve the memory leak that 766 experienced with logging in the 2022 season, and also be more performant (perhaps after some tuning; this is just the first version of this code). Note that users will need to do a Gradle build after cloning the repo in order to do the Protobuf code generation; without this step, VS Code or other IDEs will report that some of the logging classes are missing. 12f3460 adds an easy shortcut for doing a gradle build from within VS Code.
  • d7ac504 Class member variables in the starter user code are renamed to remove the m_ prefix, so as to be a bit more readable to beginning programmers.
  • The framework will automatically enable the Cross the Road Electronics Pneumatics Control Module (even if no solenoids are configured). This should permit the air compressor to turn on from the first time that code is deployed, even if no code for pneumatics has been added by the user.

ce9d143 Features brought in from 766's 2022 robot code

  • 61687b8 Upgrade to WPILib version 2022.4.1 to resolve an issue where Java Threads can deadlock when exiting (i.e. when a Procedure ends).
  • Deadlock monitor which will log error messages with stack traces when it detects that Procedure hasn't yielded control in a while. This helps to catch cases where a Procedure has a long-running while loop which ought to call context.yield() or one of the context.wait* methods.
  • Permit Mechanisms to call their own mutating functions from their run() method (i.e. a Mechanism's run() method always has "ownership" of the Mechanism). Mechanism authors should ensure that there aren't any bad interactions between automatic state mutations done in run() and ways in which Procedures may want to use them.
  • Add a web UI page to view logs from previous runs.
  • Add simple visual feedback mechanism for drivers to the web UI via "Dashboard widgets".
  • Addition of a feed-forward controller to the PIDController class.
  • Expose setting current limit and using voltage-control mode through the CANSpeedController HAL interface (now the MotorController interface).
  • Fixes for the NavX gyro HAL adapter.
  • Added the RateLimiter utility class that is useful for throttling control loops and logging.