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()
#8363 split all the cross-compilation into separate jobs, however these
jobs are still also building the world (including the tests) targeting
the host.
Since `//:publish` and its dependencies are transitioned to target the
desired platforms for each artifact, `bazel build //:publish` in the CI
jobs that aren't running tests to only build what we actually care about
in these jobs.
This saves around 1 to 1.5 minutes for each cross-compile job with 100%
cache hit rates.
Now rgb() and color constants are supported.
Changed from constructor to fromString() factory function to enable
directly returning color constant values.
I'm not entirely sure why Java header compilation is disabled for the
macOS build. But this option will be causing rebuilds to happen more
often than strictly necessary.
[Turbine](https://github.com/google/turbine) takes Java class sources
and spits out .class files with all method bodies, and private fields
and methods stripped. This provides a .jar with sufficient information
on the classpath to build dependent Java libraries without depending on
the implementation in the build graph.
`--local_ram_resources=value` and `--local_cpu_resources=value` have
been replaced by `--local_resources=[memory|cpu]=value`, so the Bazel
README is updated to recommend the new form.
The update yaml step _might_ cause changes that would affect the build
file generation. Since `bazel run //:write_robotpy_update_yaml_files`
runs them all at once, user that was using the github action to fix
their python stuff would end up having to run it twice.
By running the steps individually in series, this should be able to get
it in one swoop.
These were added in Windows 10 1703. Technically Windows 10 in general
is out of support, but versions of Windows 10 older than that are _well_
out of support. And we do directly link to other APIs that are newer. So
no need to do the dynamic linking.
The order of the Swerve Modules in the m_odometry.Update call needs to
match the order they are defined in the creation of the kDriveKinematics
object.
Fixes#8386
Was already working on this when more people started hitting issues so I
prioritized getting this PR up. This updates the wrapper script to look
for the 3 biggest categories of "everything should be fine if you run
this step first" tool failures.
Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
Co-authored-by: David Vo <auscompgeek@users.noreply.github.com>
Support joystick outputs, including Rumble and LEDs.
Also requires an update to Joystick descriptors, as that has also
changed in mrccomm to support showing what outputs are supported.
