Added a TalonController to work with hardware-based PID control on Talon SRX devices

[rhauch]

Not yet ready for merging

Slightly modified the existing Controller interface (which is implemented for software-based PID control with PIDController) and added a TalonController that is able to configure, manage, monitor, and use PID control on the Talon SRX motor controller. The TalonController interface is quite large and complex, since it attempts to expose all of the wpilibj.CANTalon functionality without exposing any of the CANTalon class.

The new TalonController works with the existing ControlledCommand class that takes a Controller implementation.

A MockController class was also implemented to allow testing of components that use a Controller implementation, where the tests can manually set the error and verify the component responds correctly. This might be difficult for components that directly use PIDController or TalonController, but where possible the components should limit their use to Controller, which does allow changing the setpoint, tolerance, and enabling/disabling the controller. (This will not always be possible, since components may need to set or change PID gains.)

Closes #40

[rhauch]

@granjef3, @Zabot: please review this PR and see if it sufficiently exposes the PID functionality on the Talon SRX.

[rhauch]

Updated the PR to reflect changes recently merged in #44, with a separate PIDController interface.

[rhauch]

Changed TalonSRX fairly significantly:

• Many of the methods that were in TalonController were not specific to feedback control, and thus were moved up to TalonSRX, which now has a lot of methods.
• The methods that read the wired input sensors exposed a very small subset of the CANTalon functionality. Now, the quadrature encoder and analog input (pot or encoder) sensors can be read at any time on the TalonSRX, regardless of the mode of control. Both return the position (really an angle) and velocity (really a rate), so rather than expose individual AngleSensors and such, each is exposed as a single Gyroscope. This works really well, since the outputs are angles in degrees and rates in degrees per second, and are based upon the frame rates (which can be different for the encoder and analog sensor, and even changed by the user).
• You can select which of these inputs is used as the "selected" input (even without using feedback control), in which case the corresponding input sensor is also exposed through a separate "selected" sensor Gyroscope. Here's the tricky part: the selected input sensor is sent from the Talon to the software at a much faster frame rate (by default 20ms rather than 100ms for the analog input and encoder sensors), so it's often much better and faster to select the desired input and then read it using the selected input rather than cranking up the frame rate.

The old TalonSRX interface was pretty small and introduced only 2 methods, but the old getAngleSensor():AngleSensor method was named poorly, so this PR deprecates the method and replaces it with getEncoderInput():Gyroscope. Existing code that uses Strongback 1.0.1 will work (since getAngleSensor() now just calls getEncoderInput(), but users will want to change to use the new method to get access to the rate.

[rhauch]

@granjef3, @Zabot: If you don't have time to review, perhaps you could at least look at how HardwareTalonSRX is creating the gyroscope implementations, and specifically how it is converting from the analog bits or quadrature counts to angles and angular rates.

[xortive]

I don't have thorough experience with the encoder functionality of the Talon SRX, but the gyroscope implementations look sane. Have you tested on real hardware yet?

[rhauch]

@granjef3, thanks for scanning. No, this has not yet been tested on real hardware, though I hope to do that during the next week, at least with a quadrature encoder on our last robot. But we don't have an analog encoder or pot handy, so that will take a bit longer.

I realized that the target is exposed as raw position of whichever input sensor is selected, so I'll have another commit that will make it in degrees, and it will use the selected "enhanced" gyroscope (really, a special subclass of Gyroscope that can back-calculate the raw position or angles given a raw position). It'll also have unit tests for the "enhanced" gyro classes that use some examples from the Talon SRX Software Reference Manaual and the JavaDoc.

[rhauch]

Rebased with latest from master.