This adds a C++, Java and Python version of a Biquad filter class to
wpimath.
For testing, I took output from scipi functions and commented the inputs
I used above each test case.
---------
Co-authored-by: Drew Williams <drew.williams@capstanmedical.com>
- 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
The `command3` example project contains a program that could plausibly
play in the 2026 rebuilt game. It includes nested mechanisms (`Intake`
has an inner `IntakeWrist` and `IntakeRoller` and is similar to the v2
superstructure concept), swerve drive with localization and path
following (albeit stubbed for sake of example), opmodes and
opmode-scoped commands, and command-scoped triggers.
The template projects are basic skeletons. The larger template includes
a basic command that just increments and prints a counter variable every
time it runs.
The hatchbot v3 example has been refactored to be more idiomatic:
- `RobotContainer` removed
- "Subsystem" names in packages, comments, and classes has been replaced
with "Mechanism"
- Some v2-specific comments and structures have been reworded or deleted
- The Drive mechanism now provides commands for arcade drive and driving
a distance, instead of exposing public methods that write directly to
hardware (which broke encapsulation and made it possible to issue
conflicting hardware requests)
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.
Resolves#8587
This PR implements the requested anti-tipping utility and refactors the
math to correctly adhere to the NWU coordinate system.
**Key Changes:**
* Fixed the axis mapping: Positive pitch now correctly maps to a forward
tip (+X), and positive roll maps to a rightward tip (-Y).
* Inverted the proportional control logic: The correction vector now
applies a positive `kP` to drive *into* the direction of the fall to get
the wheels back under the center of gravity, rather than driving away
from it.
* Added a comprehensive JUnit test suite (`AntiTippingTest.java`) to
verify the calculated `ChassisSpeeds` correctly zero out the orthogonal
axis and provide the correct positive/negative velocity across all four
tipping directions.
Tested locally against `testDesktopJava` and passes all style/formatting
guidelines.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
TL;DR: kill https://github.com/wpilibsuite/bzlmodRio-libssh, update
versions, and make things easier for a script to update.
The main motivation behind this was that libssh was out of date with the
gradle version. Using these "external" dependencies can cause agita as
we churn through toolchain updates. Unlike the toolchains and opencv,
which can be used by external users (i.e. a all bazel robot, if a vendor
wanted to use bazel) a C++ wrapper around libssh maven deps almost
certainly wouldn't be pulled in, much like ceres and mrclib.
As a result of vendor'ing libssh, and knowing some potential pitfalls
and annoyances, this PR does the following:
- Vendor libssh, akin to how mrclib is pulled in
- Moves the vendor'd ceres to `shared/bazel/thirdparty`, and refactors
it to better match mrclib. To me it doesn't necessarily belong in its
`thirdparty` location because it is bazel only.
- Due to the refactoring, libssh and ceres can now be pulled into
`MODULE.bazel` instead of the `WORKSPACE.bzlmod` helper. This is good
prep for a potential upgrade to killing `--enable_workspace` / bazel 9
- Write a python script that can deal with the integrity / sha256 of the
http_archives. I suggested this be added to davo's mrclib PR, but this
one is a little bit more robust and will actually edit the files in
place. This makes upgrading versions substantially easier.
- Upgrade libssh version to what gradle is using, and mrclib to the
version in #8858. These changes have been tested against that PR.
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>
