This updates gamepad trigger naming from cardinal-style face buttons
(`northFace/southFace/eastFace/westFace` and
`NorthFace/SouthFace/EastFace/WestFace`) to directional naming
(`faceUp/faceDown/faceRight/faceLeft` and
`FaceUp/FaceDown/FaceRight/FaceLeft`) to match the requested API shape.
The change is applied across Java and C++ HID/command layers, along with
related examples and binding metadata.
- **API surface updates (Java)**
- Renamed trigger/event methods in:
- `wpilibj` `Gamepad`
- `commandsv2` `CommandGamepad`
- `commandsv3` `CommandGamepad`
- Mapping preserved:
- `southFace` → `faceDown`
- `eastFace` → `faceRight`
- `westFace` → `faceLeft`
- `northFace` → `faceUp`
- **API surface updates (C++)**
- Renamed trigger/event methods in:
- `wpilibc` `Gamepad`
- `commandsv2` `CommandGamepad`
- Mapping preserved:
- `SouthFace` → `FaceDown`
- `EastFace` → `FaceRight`
- `WestFace` → `FaceLeft`
- `NorthFace` → `FaceUp`
- **Python semiwrap updates**
- Updated `wpilibc/src/main/python/semiwrap/Gamepad.yml` method mappings
to the renamed C++ method names (`FaceDown/FaceRight/FaceLeft/FaceUp`).
- **Callsite migration**
- Updated Java examples/template code and C++ examples/template code to
use the new method names so samples remain aligned with the API rename.
- **Docs/comments alignment**
- Updated related Javadoc/reference text and example comments to use
directional terminology.
```java
// Before
driverController.southFace().onTrue(command);
driverController.eastFace().onTrue(command);
// After
driverController.faceDown().onTrue(command);
driverController.faceRight().onTrue(command);
```
```cpp
// Before
driverController.SouthFace().OnTrue(command);
driverController.EastFace().OnTrue(command);
// After
driverController.FaceDown().OnTrue(command);
driverController.FaceRight().OnTrue(command);
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ThadHouse <7727148+ThadHouse@users.noreply.github.com>
People generally have expressed a dislike for the Hungarian notation
used in member variables, especially in examples/templates, and our
styleguide shouldn't be forced on downstream consumers, so this removes
all Hungarian notation from the examples/templates.
There are _some_ benefits to Hungarian for private member variables
(like knowing what's a member vs. local in a PR review) so we'll keep
private member variables the same for now, but public variables should
no longer use Hungarian notation, since it looks much worse. A new PMD
XPath rule has been added to accomplish this goal. Some other
non-compliant variables were fixed for the new rule.
The "Utility" name better matches its intended generic use case and
avoids overloaded terminology with unit testing (e.g. the need to name
the opmode annotation `@TestOpMode`).
The driver station will also be updated to reflect this change.
Commands are no longer able to outlive their schedule-site's scope,
regardless of how they were scheduled (set as a default command, bound
to a trigger, or manually scheduled)
As a consequence, default commands need better tracking so the default
command setting can be released when their scope exits and the next-most
appropriate default command can be rescheduled (eg, an opmode sets a
default command, then the globally-scoped default is restored when the
opmode exits). Some complexity is required here to make it work well for
edge cases.
Like `schedule()`, `setDefaultCommand()` will immediately start the new
default command if called inside of another command to avoid 1-loop
delays. However, this does not apply when called by the _current_
default command, as it would result in attempting to cancel the default
command while it's mounted (which is impossible and would throw an
exception)
```java
class Robot extends OpModeRobot {
final Drive drive = new Drive();
final CommandXboxController controller = new CommandXboxController(1);
public Robot() {
// global default command, active unless overridden in an opmode or command
drive.setDefaultCommand(drive.stop());
// global trigger binding, always active
controller.rightBumper().onTrue(drive.setX());
}
}
@Teleop
class ExampleOpMode extends PeriodicOpMode {
public ExampleOpMode(Robot robot) {
// opmode-specific default command
robot.drive.setDefaultCommand(robot.drive.operatorControl(robot.controller));
// opmode-specific binding
robot.controller.leftBumper().whileTrue(robot.drive.stop());
// opmode-specific binding that takes precedence over the global binding
// because it happens last; it "wins out" over the `setX()` binding
robot.controller.rightBumper().onTrue(robot.drive.selfTest());
}
@Override
public void periodic() {
Scheduler.getDefault().run();
}
}
```
Easier then the last one that put everything in a sub namespace. By
prefixing the name less things break, and intellisense will be less
confusing to new users during the transition.
User code:
- OpModeRobot used as the robot base class
- LinearOpMode and PeriodicOpMode are provided opmode base classes
- In Java, annotations can be used to automatically register opmode classes
Additional user code functionality:
- OpMode (string) is available in addition to the overall
auto/teleop/test robot mode
- OpMode does not indicate enable (enable/disable is still separate)
- The HAL API uses integer UIDs; these are exposed at the user API level
as well for faster checks
- User code creates opmodes on startup (these have name, category,
description, etc).
DS:
- DS will present opmode selection lists for auto and teleop for
match/practice. During a match, the DS will automatically activate the
selected opmode in the corresponding match period.
- For testing, an overall mode is selected (e.g. teleop/auto/test) and a
single opmode is selected
Future work:
- Command framework support/integration
- Python annotation support
- Unit tests (needs race-free DS sim updates)
- Porting of examples
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
It's only syntactic sugar over the CommandScheduler's schedule method and creates a footgun because it’s too obvious to try to use in incorrect places.
Co-authored-by: Starlight220 <53231611+Starlight220@users.noreply.github.com>
We now use a wrapper (wpi::print) to catch exceptions since we can't patch
std::print() to not throw when we ultimately migrate to it.
fmtlib and std format/print throw the same exceptions and always have. We previously patched fmt::print() to not throw a write failure exception, but we can't do that for std::print(); wpi::print() is the migration plan.
Moves all CommandBase functionality into Command and deprecates CommandBase for removal.
Moves all SubsystemBase functionality into Subsystem and deprecates SubsystemBase for removal.
Adds a function to CommandScheduler to remove all registered Subsystems.
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
This reverts commit a79faace1b.
This change will be superseded in a non-breaking way by changing to static functions and deprecating GetInstance() entirely.
Improves consistency across all classes.
Affects Preferences, LiveWindow, and CameraServer.
Old commands Scheduler::GetInstance() was not updated as this is already
deprecated.
This makes code easier to read and more consistent between C++ and Java.
Also update clang-format settings to always add a line break (even if no braces are used).
