The original idea of LiveWindow telemetry was to automatically make
telemetry data visible to users. This has proved increasingly
problematic in recent years due to the "spooky action at a distance"
of telemetry happening for objects that are only constructed but not
used, and blocking or slow object reads resulting in hard-to-debug
loop overrun conditions.
This allows us to error out on deprecation warnings for thirdparty
libraries and standard library features.
Co-authored-by: Starlight220 <53231611+Starlight220@users.noreply.github.com>
PMD requires that variables only initialized in the constructor be
final. The compiler errors if those final variables aren't guaranteed to
be initialized, so extra else branches were added to ensure that.
PMD also requires that classes with only private constructors be final.
The equivalent C++ classes were finalized as well, except for
TimeInterpolatableBuffer because it doesn't expose factory functions.
This creates a default log file that captures NT changes and
automatically renames the log file based on time and match info.
DriverStation joystick logging will be implemented by the DriverStation
class instead.
SetPositionOffset was added. Been requested multiple times, and easy to implement.
The javadocs mentioned GetPositionInRotation. It has tripped up many people how to get the absolute position from the encoder (You currently have to have precreated the DutyCycle object). Add this method (as GetAbsolutePostition) to make this easier to do.
The checks for making sure a matching set of values was read was doing direct double comparisions. This worked ok in the DutyCycle case, but has problems in the analog case. Solve this by using an epsilon comparison.
And finally, scale AnalogEncoders analog input to 0-1 instead of 0-5. This was reported a few years ago, but the issue was missed. This caused the encoder to count from 0-5, then 1-6, then 2-7 etc. This is solved and now works correctly.
Closes#3188Closes#4046Closes#4051
And fixes the following issue on CD
https://www.chiefdelphi.com/t/wpilib-analogencoder-java/372649
If xSpeed == -0.0 and zRotation > 0, the algorithm assumes it's in the
third quadrant instead of the first since +0.0 == -0.0.
Also added tests for inverse kinematic functions, fixed some
MecanumDrive test bugs, and added Java MecanumDrive.driveCartesianIK()
and KilloughDrive.driveCartesianIK() overloads with defaulted gyro angle
that C++ already had.
Fixes#4022.
It seems like the JVM does not handle recursive calls to object monitor based locks correctly. A few bugs in the past have been reported to have caused deadlocks if this occurs. It looks like the version of Java we use is fixed, but there could be other bugs, and it seems like this area of the code isn't tested much. Based on the stacks reported in #3896, it really seems like this is occurring. So we're going to attempt to switch to explicit mutex based classes, which shouldn't have bugs like this, and we will see if that fixes the issue.
The angular rate is treated somewhat like an angle during calibration,
but the datasheet says it's angular rate. The variables were renamed to
make this clearer.
