@AustinSchuh's `rules_cc` patches have all been merged upstream. This
updates `rules_cc` to include the relevant patches, removing the need to
patch it here.
This also squashes this warning on every build:
> WARNING: For repository 'rules_cc', the root module requires module
version rules_cc@0.2.13, but got rules_cc@0.2.14 in the resolved
dependency graph. Please update the version in your MODULE.bazel or set
--check_direct_dependencies=off
This fixes simulation WaitForProgramStart(true) potentially advancing
due to a stale or pre-start notifier created before SetProgramStarted()
was called.
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.
Fix SetPeriod() valuePos handling when an ID moves between period queues
In SendValue(), don't append older values, and fix the total size
accounting for the underflow case when a smaller value replaces a larger
value.
Add comprehensive unit tests.
This is increasingly difficult to maintain, and has very limited
benefit. Modern coprocessors with enough horsepower to run Java
applications can use the Gradle or Bazel build systems instead.
Useful for catching bad behavior when doing math or configuring ratios
with integers. Errors can be turned off with
`@SuppressWarnings("IntegerDivision")`
```java
double kV = 12 / 6000; // error: integer division in a floating-point context
double kV = 12. / 6000; // OK
double kV = 12 / 6000.; // OK
int kV = 12 / 6000; // OK, but evaluates to 0
double ratio = 42 / 12; // error: integer division in a floating-point context
@SuppressWarnings("IntegerDivision")
double ratio = 42 / 12; // OK, evaluates to 2
```
```
Execution failed for task ':developerRobot:compileJava'.
> Compilation failed; see the compiler output below.
/Users/sam/code/wpilib/allwpilib/developerRobot/src/main/java/wpilib/robot/Robot.java:10: error: integer division in a floating-point context
double kV = 12 / 6000;
^
1 error
```
Also adds the compiler plugin as a dependency to the developerRobot
project for dev testing
The original implementation was `m_gyroOffset + (rotation -
m_pose.Rotation())`, which means the first `RotateBy` should be using
`-m_pose.Rotation()` (see `ResetPose()`). Java is already correct. This
also adds new tests to catch this particular error.
When the bazel remote cache was switched from buildbuddy to a self
hosted server in #8342, I asked that the buildbuddy hooks be remain so
that I could still use their caching service for local builds.
The downside of this was that my forks builds aren't leveraging
buildbuddy, so if I'm fiddling with something heavy like a wpimath
robotpy thing, my CI builds never update a cache and never are warm when
I push fixups.
This PR combines the `setup-bazel-remote` and `setup-build-buddy`
actions which set up the bazel remote cache. Rather than having two
different version, the correct one will be choosen in the following
order:
1. Use wpi's server with write access if the `bazel_remote` information
is set (This basically would only happen on main branch in
`wpilibsuite/allwpilib` since secrets aren't accessible from builds
originating in forks)
2. Use buildbuddy if the key it is present (This would work for my fork
builds)
3. Fall back to the readonly version of wpi's server
As seen
[here](https://github.com/bzlmodRio/allwpilib/actions/runs/25777428163/job/75712863120#step:7:28)
the build in my fork will run with buildbuddy, and my PR's build here
should fall back to readonly mode.
This also updates the bazel scripts to behave more like the C++ and Java
examples, and updates the copybara scripts to be able to sync up
`mostrobotpy`
These two functions were changed to return new objects instead of
modifying in-place, so the `const` qualifier should be added. Otherwise,
users with a const reference to a `SwerveModuleVelocity` need to make a
temporary copy first.
`added ^ removed` (XOR) is incorrect for the update guard.
Both `added` and `removed` can be true simultaneously (e.g. subscription
options change), and XOR would incorrectly skip the period update. Fixed
to `added || removed`.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
If a `ClientMessageQueue` is at a
memory limit, `ClientMessageQueueImpl::ClientSetValue` will still
increment `m_valueSize.size` even though no element has actually been
actually been added.
This quickly results in things like topics completely shutting down
under high load, as no new elements can be added as `m_valueSize.size`
explodes to infinity unless `ClearQueue()` is explicitly called. You can
see this pretty easily with the following code, be it in sim or on a
robot:
```cpp
#include "wpi/framework/TimedRobot.hpp"
#include "wpi/smartdashboard/SmartDashboard.hpp"
class Robot : public wpi::TimedRobot {
public:
// ...
uint64_t value{0};
/**
* This function is called periodically during all modes
*/
void RobotPeriodic() override {
for (int i = 0; i < 1'000'000; i++) {
value += 1;
wpi::SmartDashboard::PutNumber("value", value);
}
}
}
```
Connecting via your favorite dashboard quickly reveals that no new
values get added after a while. However, with this patch implemented,
values do still continue to increment as updates gradually get serviced.
Generate an `update` method for any logged Robot class, not just
TimedRobot
Continue to generate a `bind` method for TimedRobot subclasses
Also removes unnecessary import statements for generated loggers, since
they're using fully-qualified names in the generated Epilogue class now.
Use [pattern matching switch
expressions](https://docs.oracle.com/en/java/javase/17/language/pattern-matching-switch.html)
where possible. This is a JVM 21+ feature which wasn't available until
recently.
If you look at the Java bytecode, this improves performance from an O(n)
runtime check of literally each of the `if (x instanceof y)` checks to
instead be an O(1) tableswitch.
---------
Signed-off-by: Jonah Snider <jonah@jonahsnider.com>
Since Servo has been removed from WPILib, add a RomiServo to replace it
(similar to XRPServo).
For Romi, move allocation of PWM channels to OnBoardIO since Motor and
Servo share channels.
`Trigger.multiPress(N, T)` creates a trigger that fires when there are
at least N rising edges within the last T timespan, eg `multiPress(3,
Seconds.of(1.25))` for 3 rising edges within the last 1.25 seconds.
`Trigger.retryWhileTrue` and `retryWhileFalse` will continuously attempt
to schedule a command while the binding condition is met. This is
similar to `whileTrue` and `whileFalse`, but will reschedule the command
if it ends or is canceled while the binding condition is still met,
rather than requiring a new rising edge to reschedule it.
As discussed in the discord. lb-in^2 is the common imperial MOI unit,
e.g. Onshape uses it.
Also, improved the Java docstring for `KilogramMetersSquaredPerSecond`
to explain what it represents.
---------
Co-authored-by: Benjamin Hall <bhall@ctr-electronics.com>
This pulls in the `mrclib` maven repository as shared libraries, as a
prereq for #8858.
Alternative to #8869, which avoids the unnecessary lockfile entry. This
should be a one-to-one replacement for that PR.
Closes#8869
---------
Co-authored-by: PJ Reiniger <pj.reiniger@gmail.com>
Since there is no longer a requirement for Subsystems/Mechanisms to be
registered to the command scheduler via a register() call, Mechanism can
be changed to an interface instead to allow for more flexible
inheritance structures.
Specifically, this would allow compatibility with CTRE swerve (which
previously required implementing Subsystem so that it could extend
CTRE's base class).
