v2.0.0
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 calledcom.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
andCANSpeedController
have been replaced by one unified interface calledMotorController
.- "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 tocom.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
}
}
- 21b3c69 Declaring an autonomous mode is now both more flexible and less magical. It's now possible to create autonomous modes from
Procedure
s with constructor arguments.
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
EncoderReader
s (through theEncoderReader
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
Procedure
s starting and ending, etc. This frees up the defaultPROCEDURES
logging category to be more useful to users trying to add logging to theirProcedure
s (though users are encouraged to add their own logging categories whenever appropriate). 5b998a2Mechanism
s 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 aProcedure
has a long-running while loop which ought to callcontext.yield()
or one of thecontext.wait*
methods. - Permit
Mechanism
s to call their own mutating functions from theirrun()
method (i.e. aMechanism
'srun()
method always has "ownership" of theMechanism
).Mechanism
authors should ensure that there aren't any bad interactions between automatic state mutations done inrun()
and ways in whichProcedure
s 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 theMotorController
interface). - Fixes for the NavX gyro HAL adapter.
- Added the
RateLimiter
utility class that is useful for throttling control loops and logging.