#8787 Added a new compound unit that was tripping up the pybind11
stubgen when trying to mirror over to mostrobotpy land. This fixes the
error, and also cleans up some `create-imports` things.
```
[680/680] Generating semiwrap/modules/_wpimath.pyi with a custom command
FAILED: [code=1] semiwrap/modules/_wpimath.pyi
/usr/local/bin/python -m semiwrap.cmd.make_pyi wpimath._wpimath wpimath/_wpimath.pyi semiwrap/modules/_wpimath.pyi -- wpimath /tmp/build-via-sdist-2hfn0_cv/robotpy_wpimath-2027.0.0a6.post1/wpimath/__init__.py wpimath._init__wpimath semiwrap/_init__wpimath.py wpimath._wpimath semiwrap/modules/_wpimath.cpython-311-x86_64-linux-gnu.so
pybind11_stubgen - [ ERROR] In wpimath._wpimath.AntiTipping.__init__ : Invalid expression 'wpi::units::unit_t<wpi::units::unit<std::ratio<1l'
pybind11_stubgen - [ ERROR] In wpimath._wpimath.AntiTipping.getP : Invalid expression 'wpi::units::unit_t<wpi::units::unit<std::ratio<1l, 1l>, wpi::units::base_unit<std::ratio<1l, 1l>, std::ratio<0l, 1l>, std::ratio<-1l, 1l>, std::ratio<-1l, 1l>, std::ratio<0l, 1l>, std::ratio<0l, 1l>, std::ratio<0l, 1l>, std::ratio<0l, 1l>, std::ratio<0l, 1l> >, std::ratio<0l, 1l>, std::ratio<0l, 1l> >, double, wpi::units::linear_scale>'
pybind11_stubgen - [ ERROR] In wpimath._wpimath.AntiTipping.setP : Invalid expression 'wpi::units::unit_t<wpi::units::unit<std::ratio<1l'
Warning: stubgen - [WARNING] Raw C++ types/values were found in signatures extracted from docstrings.
Please check the corresponding sections of pybind11 documentation to avoid common mistakes in binding code:
- https://pybind11.readthedocs.io/en/latest/advanced/misc.html#avoiding-cpp-types-in-docstrings
- https://pybind11.readthedocs.io/en/latest/advanced/functions.html#default-arguments-revisited
pybind11_stubgen - [ INFO] Terminating due to previous errors
ninja: build stopped: subcommand failed.
```
This piggy-backs off #8362. `wpiformat` will handle all the non-python
files (C++ trailing spaces in yaml files, etc), and the robotpy files
(guarded by being under src/main/python or src/test/python) will be
handled by black only.
This updates to the 2027-1 toolchains. This also is the first version
with the `rules_bzlmodrio_toolchains -> wpilib_toolchains` rename, so
the surface area of the change is a little bit big.
The opencv dep has bzlmod'ified as part of this as well.
- Fix a dependency on other test global state via Vin by calling
ResetData() to ensure consistent state
- Clamp the ground truth voltages to match sim.SetInputs()
- The C++ test was checking the noisy measurement output instead of
using sim.GetState()
- Make GetState() public in C++ and Java
This turns the styleguide on for the non-python robotpy files.
The overwhelming amount of changes were
related to whitespace, followed by some IWYU for standard library
headers.
I tasked Claude with converting the existing C++ tests to python for
wpilib. I gave it a decent review for comparison to the existing tests,
and it seems to have covered everything. I did do some small cleanup in
a couple of places. One notable test that is missing is the LED
patterns, but that is getting handled in
[mostrobotpy](https://github.com/robotpy/mostrobotpy/pull/254) land.
This helps reduce lock contention on Synchronization Signal objects if
the user does not intend to use this signaling path.
Use this option on the RobotBase MultiSubscriber to all topics.
There were a few issues with the generated classes.
Python had a __getattr__ forwarder that we defintely did not want.
C++ was using a struct with constexpr values, and not an enum class for
button types.
In all 3, the forwarders from gamepad didn't exist on the generated
types.
This fixes all 3.
---------
Co-authored-by: David Vo <auscompgeek@users.noreply.github.com>
The `RobotState::GetRobotMode()` API returns this enum class, but
`DriverStationSim` was using the `HAL_RobotMode` enum instead. This
commonizes the two APIs to return the same `RobotMode` enum class.
This difference in the APIs also affected Python, as the `hal.RobotMode`
and `hal._wpiHal._RobotMode` types are not compatible with each other.
Store DriverStation-owned GenericHID and Gamepad instances in Java and
C++, and expose the cached objects to Python bindings.
Move hand-written command gamepad and joystick wrappers to compose
cached CommandGenericHID instances plus typed HID wrappers, including a
Python CommandGamepad.
This will let us remove UserControls, while helping ensure that we don't
have state smashing between GenericHID objects.
Another bonus is without inheritance, intellisense will no longer show a
bunch of annoying methods, and instead just what actually exists.
---------
Co-authored-by: Peter Johnson <johnson.peter@gmail.com>
Using MrcLib on the robot is going to be the plan for the future, to
make things easier.
MrcLib is how sim is supported going forward. The desktop version of
mrclib can act as a robot server.
This is set up where the mrclib interface is in shared code. On robot,
that is the only backend used. On desktop, a default sim backend is
used. However, the sim plugin can switch that to the real robot backend,
so the robot code will exactly look like a real robot.
This addresses a race condition caused by TimedRobot and other
frameworks not creating their first notifier alarm until after signaling
program start.
Default this to true because it's the most common desired use case when
combined with TimedRobot.
The FTC DS had a deadband. Additionally, the FRC one had an implicit
deadband due to the only 8 bit resolution. We need a deadband by default
now with the high resolution gamepads.
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>
The initial build file generation for robotpy projects was relatively
naive and purpose built to get `allwpilib` compiling, without supporting
all the available features.
This modifies the generation scripts to be able to support multiple
embedded libraries, which will be necessary for #8858, since `mrclib.so`
will need to be bundled along with the hal libraries. In addition some
cleanup was done to get the wheels looking more like what is in pypi.
This provides the ability to simulate parts of the Onboard IMU at the
HAL level. This allows team to use and simulate the IMU in code, and a
follow up PR could be made to the halsim_gui to add a new widget to view
and modify the data graphically.
Since the C++ IMU uses radians for angles that is what I did for the
simulator.
Partially deals with #8845
Right now, the `zipBaseName` variable in various publish.gradle files
contains the group ID and artifact ID for use by the combiner, however,
they are also duplicated in `artifactGroupId` and `baseArtifactId`,
leading to potential mistakes if they aren't updated together. This
fixes that by adding a new utility function `makeZipBaseName` to
automatically create the right name given a group ID and artifact ID.
This also fixes publishing for thirdparty subprojects, which didn't
update `zipBaseName`.
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.
There were complaints about no patch files being created from CI when
the examples pre-gen fails for people who don't build with bazel. This
adds a new action step to run just the non-robotpy pregen.
I also added an argument to the diff tests to make it a unified diff,
which might make it easier to hand fix.
This removes the confusion of the `ExpansionHubServo` class serving both
purposes, and thus having a `set` method that functions as `setPosition`
when in servo mode and `setThrottle` when not in continuous mode. It
also removes the `setContinuousRotationMethod` which could be confused
for a method that switches the actual servo firmware itself from servo
to continuous mode, which is not a thing that is physically possible I
think.
---------
Signed-off-by: Zach Harel <zach@zharel.me>
Part of the `semiwrap` process that hasn't been ported over yet is
generating pyi stubs. It is possible to not have your semiwrap setup
correctly and "leak" native types into the generated python docstrings,
which causes the process to
[fail](https://github.com/pjreiniger/mostrobotpy/actions/runs/24618640845/job/71985311682#step:12:3652).
semiwrap also has a tool you can run, 'create-imports' that will read
the symbols from a build pybind library and automatically create and
sort the imports in the `__init__.py` file. This step is not enforced by
CI, which is why it hasn't been failing in `mostrobotpy` land.
This PR fixes the stubgen problems and runs reorganizes the imports. I
will have a follow up PR that can bring these automatically into the
build system after this lands. I'd do a fancy new `gh stack` but I can't
figure out if it works on forks.
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.
Clang 21 catches returning `0` from `GetOpMode` as returning `null`.
Since this state is very momentary and all comparisons inside WPILib are
done against `GetOpModeId` instead, I changed it to return an empty
string.
1. Make the OpMode interface itself periodic; this means the only
differences between `OpMode` and `PeriodicOpMode` are the latter's
methods to add sideloaded periodic callbacks
2. Make OpModeRobot process callbacks in a similar fashion to TimedRobot
and
3. Add some lifecycle functions (discussed below)
4. Pull the callback priority queue from TimedRobot to a new class
called `PeriodicPriorityQueue` so that `TimedRobot` and `OpModeRobot`
have less duplication
5. Fix a typo in the DriverStationJNI class that causes a memory leak
when certain driver station sim calls
6. Port the C++ OpModeRobot tests to Java
`OpModeRobot` now possesses some `IterativeRobotBase`-stye lifecycle
functions; these functions
1. `robotPeriodic`
2. `simulationInit` and `simulationPeriodic`
3. `disabledInit`, `disabledPeriodic`, and `disabledExit`
(note that `simulationInit` and `disabledInit` may be renamed to match
wpilibsuite#8719)
`OpModeRobot` also now processes `OpMode` changes (by the Driver
Station) in its `loopFunc` method, similar to
`IterativeRobotBase.loopFunc` processing game mode changes; `loopFunc`
is, similarly to `TimedRobot`, provided as a default `Callback`
---------
Signed-off-by: Zach Harel <zach@zharel.me>
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
