Remove WaitForCachedData as it's no longer required.
Also properly handle caching / transition detection logic that occurs at the
WPILib level.
This also changes DriverStation::IsNewControlData() to check for WPILib-level
caching instead of wrapping the HAL function.
The new getRotation2d() method in the Gyro interface was passing
an angle in degrees to a constructor that accepts radians.
Use fromDegrees() factory function instead.
Using GetAverageVoltage will reduce the noise in potentiometer reading. Potentiometers are unlikely to be used where the minimal lag averaging introduces would impact control loop stability.
When not direct mapped, make index constructors private and add factory
functions for channel and index.
Co-authored-by: GabrielDeml <gabrielddeml@gmail.com>
pose.Translation().X() and pose.Translation.Y() are common operations,
so shortening them to pose.X() and pose.Y() would be convenient.
Java uses the getX() convention so that is used instead of X() for Java.
Also move some things in HAL for consistency.
WAS:
C++:
- C APIs: #include "mockdata/AccelerometerData.h"
- User side class: #include "simulation/AccelerometerSim.h"
Java:
- JNI APIs: hal.sim.mockdata.AccelerometerData (and a few classes in hal.sim)
- User side classes: hal.sim.AccelerometerSim
IS:
C++:
- C APIs: #include "hal/simulation/AccelerometerData.h"
- C++ class: #include "frc/simulation/AccelerometerSim.h"
Java:
- JNI APIs: hal.simulation.AccelerometerData
- User side class: wpilibj.simulation.AccelerometerSim
The most common mistake users (including contributors to WPILib) seem to make while creating new constraints is ignoring some sort of edge case that causes the calculated minimum acceleration to be greater than the calculated maximum acceleration.
This specialized exception, with its detailed error message, should make it easier and quicker for said users to debug and fix bugs within their constraints.
Co-authored-by: Tyler Veness <calcmogul@gmail.com>
The DutyCycleEncoder class initializes AnalogTrigger, which is not supported in simulation.
To avoid this, do not use AnalogTrigger (or Counter) in simulation mode.
Fixes#2367
Co-authored-by: Peter Johnson <johnson.peter@gmail.com>
This was caused by m_epochs storing the timestamps as nanoseconds while
the epoch printing code expects microseconds. Adding a duration cast
fixes this.
Java stores the epoch timestamps in a double as microseconds, so it
doesn't exhibit this bug. The comments were updated to make this more
obvious.
Fixes#2392.
Previously, it could take the long way around. This recomputes the
profile goal with the shortest error, thus taking the shortest path.
Also removed the setpoint clamping from PIDController::SetSetpoint()
because it's unnecessary to make PIDController behave correctly for
a modular arithmetic input, and it breaks the setpoint calculation in
ProfiledPIDController otherwise.
Fixes#2277.
This is useful for undoing transformations. One application my FRC team
found was converting perspective n-point data from a "camera to target"
coordinate frame transformation to a "target to camera" coordinate frame
transformation.
What would happen is the Stop() call would happen between the notifier loop being triggered and calling UpdateAlarm(). This would cause the Update to overwrite the stop.
The current hasPeriodPassed() function is confusing. In preparation for deprecating it,
add new advanceIfElapsed() function with same functionality and hasElapsed() function
which only checks that the time period has elapsed and does not advance the timer.
Also fix a couple of incorrect usages of hasPeriodPassed().
The field image and robot image can be loaded or just a wireframe used.
The robot can be moved and rotated with a mouse click + drag.
The robot position is settable in robot code via the Field2d class.