This makes error messages point directly at the variable use, instead of
on the enclosing AST node:
```
error: `outerCoroutine` may not be in scope
outerCoroutine.yield()
^
error: `outerCoroutine` may not be in scope
consume(x, outerCoroutine);
^
```
instead of
```
error: `outerCoroutine` may not be in scope
outerCoroutine.yield()
^
error: `outerCoroutine` may not be in scope
consume(x, outerCoroutine);
^
```
Sequential group builder had an inverted if condition causing NPEs
Parallel group builder was building parallel groups using an old ctor
signature and creating groups that didn't match what was specified in
the builder
Test coverage has been added for both builder types
Supports Doxygen 1.14, and should be better with Doxygen 1.15 that we
use, compared to the current version.
Improves, but does not fix#8486. The sidebar now covers the search
results, rather then both bleeding through
<img width="1206" height="1969" alt="image"
src="https://github.com/user-attachments/assets/e8c0cefd-a72a-4c41-a5bf-c191752250f4"
/>
We need to wait, or otherwise OpModeRobot will immediately reinstantiate
and re-run the opmode, which is generally undesirable (e.g. for
autonomous).
Fixes#8475.
This got missed in the reorg, and these values aren't actually used for
anything when building in `allwpilb`, but we might as well fix them here
to make the copybara process easier.
Looks like a build failure got lost in the landing order of python
commands and the big opmode change. This makes it compile again, based
on the java / C++ changes from the opmode PR.
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>
These are the scripts I've been using to sync between mostrobotpy and
here. I debated putting it in the "source of truth" that is
`mostrobotpy` , but I think it makes more sense here since it already
has bazel set up, and I've also recently added the ability to sync the
`commands-v2` repository, so having it all in one copybara script makes
sense.
This includes a helper python script to make it a little bit easier to
run.
Adding an ack parameter to both set and cancel is cleaner than adding
all the set alarm parameters to the ack function. It also provides an
ack-and-cancel method.
ChassisAccelerations and the drivetrain acceleration types are added in
both Java and C++. `ChassisAccelerations` is basically just
`ChassisSpeeds` but for accelerations!
`DifferentialDriveWheelAccelerations`, `MecanumDriveWheelAccelerations`,
and `SwerveModuleAccelerations` are the acceleration equivalent of the
drivetrain speeds types.
In Java, the `Kinematics` interface now has an additional generic
parameter `A` which represents the accelerations, and
`toChassisAccelerations` and `toWheelAccelerations` methods, which are
implemented the same way as `toChassisSpeeds` and `toWheelSpeeds`.
Protobuf and struct classes were also added for all four classes in Java
and C++.
---------
Signed-off-by: Zach Harel <zach@zharel.me>
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
Co-authored-by: Tyler Veness <calcmogul@gmail.com>
Was caused by checking assignability like`Protobuf<Scheduler,
ProtoMessage>` instead of `Protobuf<Scheduler, ? extends
ProtoMessage<?>>`
This epilogue bug would have also applied to other protobuf-serializable
types
#8385 changed gamepad types to follow SDL_GamepadType, so 20 and 21
(previously `kHIDJoystick` and `kHIDGamepad`, respectively) are no
longer valid constants. This meant that after leaving the disconnected
state of the sim GUI, `GamepadType.getGamepadType()` would return null
(since it didn't match any constants). Since there aren't analogous
generic joystick and gamepad constants anymore, this PR changes
GlfwSystemJoystick and KeyboardJoystick to both unconditionally report
as kStandard.
This also updates the GenericHID.SetRumble doc comment to reflect the
two new types of rumble and changes some switch labeled statement groups
to use switch rules instead. If we want to keep on using switch labeled
statement groups (e.g. for consistency with C++, though
GenericHID::SetRumble currently uses if-else), then I could drop the
last change- I just made it since GenericHID.setRumble() previously used
switch rules and general switch rules are nice since there's no risk of
fall-through.
It was possible for the alarm to fire between the set alarm and ack,
resulting in a hang on next wait. It's not possible to ack before set
alarm due to a race in sim step timing, so the fix is to provide an
atomic ack and set alarm; the easiest way to implement this in the API
was to change ack to optionally also set the alarm again.
This changes the HAL notifier interface to:
- Use wpiutil signal objects. This means waiting is done through the
`WPI_WaitObject` API instead of a dedicated function and allows for
higher level code to simultaneously wait on notifiers and other events.
- Interval timers are supported at the HAL layer
- Handlers are now required to acknowledge notifications. This is
invisible to users unless they're directly using the HAL API.
- For interval timers, an overrun count is maintained to detect if the
handler didn't acknowledge
The underlying implementation still uses condition variables for the
actual waiting. In basic testing using this approach seemed to be lower
jitter than timerfd.
Currently, the simulation and systemcore implementations are nearly
identical except for a few additional sim hook bits. This could be
refactored, but keeping them separate may make sense to keep the
systemcore implementation easy to read and reason about, or if we ever
choose to use a different underlying timer implementation on systemcore.
The simulation side API is unchanged in form but does change in
function--waiting for notifiers now only waits for currently running (or
newly signaled) notifiers to acknowledge. To avoid a race condition in
sim stepTiming, users of the low level API must make any alarm updates
(especially for one-shot alarms) prior to acknowledging the previous
alarm.
The only current use of the interval timer feature is the `Notifier`
class. The `TimedRobot` implementation still uses a single notifier and
its own interval timing logic to ensure consistent callback order. Using
separate notifiers for each user-level interval would substantially
increase complexity. `Watchdog` also doesn't use the interval timer, as
it's looking for an amount of time since the last `set` call rather than
a recurring interval time.
To reduce flicker, the sim GUI uses a fade out when a timeout goes from
set to unset.
This fixes tsan for wpilib and commands, and also fixes some spurious
test failures.
* Moved makeWhiteNoiseVector() to random.Normal.normal()
* Moved isControllable() and isDetectable() to system.LinearSystemUtil
* Renamed makeCostMatrix() to costMatrix() (Java)
* Renamed makeCovarianceMatrix() to covarianceMatrix() (Java)
* Renamed MakeCostMatrix() to CostMatrix() (C++)
* Renamed MakeCovMatrix() to CovarianceMatrix() (C++)
* Removed deprecated poseTo3dVector(), poseTo4dVector(), poseToVector()
* Removed clampInputMaxMagnitude()
* We don't use it, and Eigen has this functionality built in via `u =
u.array().min(u_max.array()).max(u_min.array());`
* Simplified implementation of desaturateInputVector()
