LiveWindow.updateValues() is now called from IterativeRobotBase on every
loop iteration. Telemetry for all WPILib classes is enabled by default;
it can be disabled for specific classes using LiveWindow.disableTelemetry(),
or all telemetry can be disabled using LiveWindow.disableAllTelemetry().
This necessitated changing the hook methodology into other classes to
be more property-based rather than each class providing multiple functions.
This had the benefit of reducing boilerplate and increasing consistency.
- Remove NamedSendable, add name to Sendable.
- Provide SendableBase abstract class.
- Deprecate LiveWindow addSensor/addActuator interfaces.
- Add LiveWindow support to drive classes.
- Add addChild() helper functions to Subsystem.
- Fix inheritance hierarchy. Now only sensors inherit from SensorBase.
Other devices inherit from some combination of SendableBase, ErrorBase, or
nothing.
To make this work in PIDController.java, the use of synchronized had to be
replaced with ReentrantLock and try-catch blocks. The locking in
PIDController.java was made equivalent to PIDController.cpp and some existing
race conditions in PIDController.java were fixed in the process.
Fixes#30.
m_pidInput and m_pidOutput are considered constant after their construction.
Setting the input range, output range, tolerance, or continuous mode locks the
controller. m_error and m_result are held in temp variables and set at the end
of the calculation.
Getters of P, I, D, F, m_error, m_setpoint, m_result, and m_enabled lock the
critical section. P, I, D, F, and m_setpoint are retrieved at the beginning of
Calculate().
Fixes#40.
This provides a way to stop motor operation even if the DIO is disconnected.
Also change Set() to enable the PWM instead of having the constructor do it.
Provide an explicit Enable() call to re-enable after Disable() is called.
This is different from the other motor controllers (which automatically
re-enable when Set() is called) due to the dual-wiring of this motor
controller.
Motor safety results in disabling the motor only until the next Set() call.
This race was caused by holding a lock while calling into FRC_ChipObject,
which was waiting for the callback to exit before returning, and our
callback wanted to grab the same lock.
* GetClock() is now officially deprecated since its comment already informally
did so and the function just forwards to Timer::GetFPGATimestamp().
* The declaration of GetPPCTimestamp() is missing a definition and has been
removed.
* std::this_thread::sleep_for() returns immediately when given a negative
duration, so the check for that was removed from Wait().
I also found some inconsistencies in MecanumDrive and KilloughDrive and fixed
them.
Drive now uses the NED axes convention. Therefore, the positive X axis points
ahead, the positive Y axis points to the right, and the positive Z axis points
down.
Translation in X assumes forward is positive. Translation in Y assumes right is
positive. Rotation rate assumes clockwise is positive. Angles are measured
clockwise from the positive X axis.
Based on the angle origin convention, DrivePolar() for both Mecanum and Killough
needed the normalization removed, sine used to compute the Y component, and
cosine used to compute the X component.
The vector rotation done in DriveCartesian() needs to rotate by a negative angle
instead of positive to undo the robot's rotation. RobotDrive assumed a clockwise
angle and sensors returned counter-clockwise angles, which is why it used a
positive angle for rotation.
Added callback scheme for a pass through to something higher
level. Since the ID is embedded into the arbitration ID, and some
devices can use different schemes whether it is plugged in through a
device or put into the daisy chain (pigeonImu), I made one "internal
data object" for max reusability.
