SendableChooser::InitSendable() is written such that it saves the table
being used in an instance variable. This doesn't work if the chooser is
added to both LiveWindow and SmartDashboard. Normally it is not added to
LiveWindow because the name is empty, but if setName() is called this could
still happen. Note adding the same SendableChooser to SmartDashboard with
two different names is also not currently supported, for the same reason.
The correct solution will be to remove the instance variable, but this is
too high risk to implement mid-season, so instead just remove from LiveWindow.
This normalizes within -1..1 to avoid clipping and maintain the ratio between
wheel speeds, since that ratio determines the center of rotation.
Fixes#923.
* Fix SmartDashboard PutData to hook setters.
Also update all PutData values in main periodic loop (same as LiveWindow).
* Improve SmartDashboard.putData() repeat call handling.
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.
* 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.
