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.
This PR changes the spline parameterizer to use an explicit stack instead of recursion. This is motivated by the fact that splines with adjacent waypoints with approximately opposite headings will never parameterize. In this case the parameterizer subdivides these malformed splines fine for a while, and then gets stuck parameterizing infinitely on some interval. In the recursive approach, this would lead to a stack overflow. We could implement a recursion depth counter (this is what my team did on our similar trajectory code last season), but it's hard to choose a good number for max depth because the initial amount of stack used varies based on how the user calls Parameterize.
A good solution for this is converting the recursion to an "explicit stack," which basically simulates recursion, but allows us to have a much larger maximum stack size. Because we avoid the stack overflow, we can instead throws a more informative MalformedSplineException. If the user is using the TrajectoryGenerator instead of the SplineParameterizer directly then the TrajectoryGenerator will go ahead and catch the exception, return a harmless empty trajectory, and report and error to the driver station.
Both floating point and 8-bit integer classes are included, as well as a wide selection of color constants.
Co-authored-by: Austin Shalit <austinshalit@gmail.com>
