How do you use the WPILib?

[Phoenix Spud]

As part of a university project, I'm looking at the WPILib (language independent) and how teams use it. In particular I'm interested in:

What classes do you use the most?
Do you edit any of the provided classes?
Do you extend any of the provided classes?
What features do you wish WPILib had?

Thanks!

[Ben Wolsieffer]

What classes do you use the most?

Well, for one, all the classes relating to hardware control (Jaguar, Talon, Double/SingleSolenoid). Also, our code uses are huge amount of Commands and CommandGroups.

Do you edit any of the provided classes?

We wrote our own analog gyro driver that was an edited version of the Gyro class. It was designed to follow the same pattern as the accelerometer drivers.

Do you extend any of the provided classes?

We extended the Command class to provide the ability to set parameters through the SmartDashboard easily. Also, we extend the Command, IterativeRobot and Subsystem classes through the normal usage of the API.

What features do you wish WPILib had?

I could probably think of a few smaller things if I were working on the robot code right now, but there is no major addition or change that I can think of.

[virtuald]

What classes do you use the most?

SampleRobot, Solenoid, AnalogInput, Jaguar/Talon et al, and Timer.

Do you edit any of the provided classes?

Well, we rewrote most of them in python...

The python version of WPILib tends to very strictly follow the spirit of the C++/Java API. I believe very strongly that if our team needs to modify WPILib, then we make a patch available on the WPILib bug tracker so that others can benefit from it, in all languages. Other modifications will tend to either extend existing objects, or create new objects based on the existing objects instead.

Do you extend any of the provided classes?

I tend to prefer creating new objects that hold WPILib objects as member variables instead of extending them.

What features do you wish WPILib had?

• I think command-based programming is too verbose.
• I would like better testing/simulation support in WPILib

[SoftwareBug2.0]

What classes do you use the most?

SampleRobot
Solenoid
VictorSP
AnalogInput
CANTalon
DigitalInput
DigitalOutput

Do you edit any of the provided classes?

Bugfixes only.

Do you extend any of the provided classes?

SampleRobot: Wrapper turns the various calls into it a call of a single function with what is happening as an argument.

What features do you wish WPILib had?

Simplicity and correctness. Despite the fact that we write C++ we wrap WPIlib extensively to avoid using its interface to the extent this is practical.

[calcmogul]

What classes do you use the most?

This year, we used the CANTalon in place of Encoder, PIDController, and DigitalInput.

SampleRobot
CANTalon
Solenoid
Timer

Do you edit any of the provided classes?

We edited the PIDController class to include dt in the I accumulation and error derivative calculations. In other cases, we replace classes. Some of the interfaces we've written already had equivalents in WPILib, but we didn't use the provided ones because we either didn't know about them, like the Preferences class, or we didn't like their implementation, like NetworkTables. There could also be some FUD with respect to the command-based paradigm versus our state machine classes (although we approached it differently than WPILib).

Do you extend any of the provided classes?

We wrap motor controllers in a GearBox template class when they control motors in the same physical gearbox. It allows us to control them as a single unit and includes an interface for shifting, encoders, and PID control.

What features do you wish WPILib had?

With regards to external features, one of my students wants the CANTalon PID interface and PIDController class to match so that one can switch between them easily.

Most of my complaints are about WPILib's implementation, and I'm trying to get them fixed. Const correctness was an issue, but a patch got accepted for that recently. There's also thread safety, which is being C++11'ified (if that's a thing) for maintainability. I wish WPILib handled ownership of objects properly with move semantics. Currently, one can pass pointers into classes like RobotDrive and still need to delete them externally later. (At least that's what the examples do.) It makes more sense for the RobotDrive instance to take ownership of them via smart pointers. I'm told there will be patches for that ready for review soon. The interfaces for classes could be smaller as well. I think some of it is common behavior and could be refactored back into its respective base classes.

[marshall]

Originally Posted by Phoenix Spud

What classes do you use the most?

Network Tables.

Originally Posted by Phoenix Spud

Do you edit any of the provided classes?

Network Tables.

Originally Posted by Phoenix Spud

Do you extend any of the provided classes?

Network Tables.

Originally Posted by Phoenix Spud

What features do you wish WPILib had?

Better Network Tables.

Yes, my tongue was firmly implanted in my cheek for those responses. Though we do use Network Tables and it really does need some work. Last I heard the WPI folks were working on it.

[Andrew Schreiber]

Originally Posted by virtuald

What features do you wish WPILib had?

• I think command-based programming is too verbose.
• I would like better testing/simulation support in WPILib

I'll second both of these. One of the big reasons we're evaluating python for future uses is the strong simulation and testing support. (Ok, and the fact that I think Java is too verbose in general).

[Thad House]

We use LabVIEW currently, but are potentially looking at switching to .NET or Java.

Since LabVIEW works differently then the other 2, the WPILib is different there. However, since I've been working on the .NET port, better simulator support would be very helpful. I've been using Pythons implementation as a base, and it easily works better then either of the 3 officially supported languages. If teams had an easy to use simulator and test bench, I bet we would see much better code from teams.

The other think I would like to see is more code uniformity. I know they are working on that, so it should be better for next season, but for now you can tell it's been written over 5 years, and its time for some cleanup.

[Camilo86]

Would be nice if there was any support for simulation/testing like robotpy has

[virtuald]

Actually, we use NetworkTables extensively too -- I forget it's part of WPILib because we split it out from WPILib for the python implementation.

I'm pretty sure the Java/C++ implementations of NetworkTables have difficult to reproduce deadlock issues in them, which is something I wish they would fix.

[Joey1939]

What classes do you use the most?

CANTalon (With direct encoder input and PID control)
RobotDrive (Makes driving easy)
CommandGroup (Create multiple autonomous modes easily)
Command

Do you edit any of the provided classes?

No

Do you extend any of the provided classes?

Yes, I extended Joystick to make a custom mapping for our specific joystick. I may extend CANTalon next year to make controlling it easier.

What features do you wish WPILib had?

1. A built in way to simulate the code running on a RoboRIO, manipulate inputs, and display outputs. (Side note: I realize that there are other options for this, but all of them require you to use their library. I prefer using the plain WPILib library.)
2. Documentation on how to make SmartDashboard plugins/more plugins

[Toa Circuit]

What classes do you use the most?
IterativeRobot, Jaguar/Talon/Victor etc. DoubleSolenoid... DigitalInput... Encoder... you know, your basic I/O stuff.
And SmartDashboard.

Do you edit any of the provided classes?
We don't modify source... but...

Do you extend any of the provided classes?
YES. Most classes get extended:
1. Joystick gets a custom class with stuff like GetButtonTripped(), GetLX(), GetLMagnitude(), GetLAngle(), etc. specific to the joystick mapping.
2. Jaguar/Talon/Victor have:
- A "invert" flag so we can wire correct colors AND have our higher level code look like what corresponds to what is going on (I.E. invert one side of a tank drivetrain)
- A throttle variable so we can slowly ramp up/down a motor

What features do you wish WPILib had?
Having the invert flag built into the SpeedController interface would be nice.
An intelligent SmartDashboard which guaruntees values will exist for the client to modify. I.E. SmartDashboard.guarunteeValue("Gyro KP", 1.5);
I know it isn't really WPILib, but fixing SmartDashboard so it actually retains layouts and values would be great. WPILib is nice and stable, not much to change. It's the other tools that are icky.

[calcmogul]

Originally Posted by Toa Circuit

2. Jaguar/Talon/Victor have:
- A "invert" flag so we can wire correct colors AND have our higher level code look like what corresponds to what is going on (I.E. invert one side of a tank drivetrain)

SpeedController already has a SetInverted() method that does what you describe.

[Joe Ross]

Originally Posted by mathmogul

SpeedController already has a SetInverted() method that does what you describe.

It was added this summer.

[Peter Johnson]

Originally Posted by virtuald

Actually, we use NetworkTables extensively too -- I forget it's part of WPILib because we split it out from WPILib for the python implementation.

I'm pretty sure the Java/C++ implementations of NetworkTables have difficult to reproduce deadlock issues in them, which is something I wish they would fix.

I have good news for you (and others who've run into issues with NetworkTables). I'm currently rewriting the NetworkTables implementation core from the ground up as a portable C++ library (with C interfaces) to fix the deadlocks and improve performance. The plan for WPILib is to update both the C++ and Java higher level classes to use this core library (similar to how NetworkCommunication is used) for consistency across languages. It's currently TBD whether LabView will use this library or continue using a LabView-native implementation. And before anyone asks, yes, the new implementation will be extensively unit-tested (I'm expecting to have at least several hundred unit tests).

In addition to the implementation rewrite, we're revising the protocol (in a backwards-compatible way) to fix a number of issues (more consistent synchronization) and make the protocol in general a bit more robust. As part of this, we're also adding a few features, including integrated value persistence (think Preferences++), remote procedure calls, server reboot detection, and client self-identification.