Unexplored Features of WPILib

Jason Daming & WPILib Team

Potential Topics

• Simulation
• Data Logging
• Timing and Memory Profiling
• System Characterization
• Command Factory API

• Using WPILib with XRP and Romi mini-robots
• Network Tables 4
• Triggers
• Testing FRC Robots (Unit Test vs Functional Test)
• Debugging

​

Simulation

• Allows testing of your robot at home.

​

• Offers physics based simulation for mechanisms and tank drivetrains

​

Simulation Limitations

• REVLib offers incomplete support introduced in 2022. Most users will just use a generic sim object and stub it out rather than deal with the poor support.
• Limelight offers no simulation support.
• Physics based swerve simulation is very hard. Not fully simulating all of the physics works “good enough” for most things

​

Data Logging

• No data is logged by default. With one line of code (DataLogManager.start();) all NT data will be logged with very minimal CPU utilization.
• Teams using a roboRIO1 should insert a FAT32 USB flash drive for additional space as the onboard space of the roboRIO1 is extremely small.
• Joystick data can also be logged with a single line
• Users can write specifically to the datalog via API or use a tool like Monologue
• It is likely an annotation based logging tool will be built into WPILib “soon”

​

​

CAN Signal Logging

• CTRE has .hoot logging takes the CAN data from each motor and logs it extremely efficiently.
• REV has no such official support. URCL is a widely used alternative. It sends the data to NT which is then read by the regular Data Logging.
• This is extremely useful for troubleshooting.
• Logging can be performed at a high rate making it slightly better for SysID

​

​

​

Advantage Scope

• Not AdvantageKit – This is for viewing data. Kit is for collecting and playback.
• Built in ability to extract log files off of the RIO
• Primary tool for analyzing pretty much all types of data
• Ability to do a “live” mode

​

​

​

​

Timing & Memory Profiling

• Can I avoid profiling? Read timing warning. Try disabling large memory users.
• Timing
• Calling configuration or blocking code periodically?
• Using loops? Possibly getting stuck?
• Memory:
• Do I have a constant or increasing memory problem?
• Disabling the System Web Server / Periodically calling Garbage Collection

​

VisualVM Profiling

• Follow the linked guide on frc-docs
• Don’t forget to start a heap dump if required.
• You also need to retrieve that dump off of your robot.
• Look for outliers not in the blank robot program

System Characterization

• By logging specific data during mechanism movement this tool can mathematically determine ideal PID & Feedforward gains.
• Now just a post collection analysis tool. No project generation included.
• You need to add code to log voltage, position, and velocity data. I recommend removing (or disabling) this code for competition.
• Using .hoot or URCL logging is another way to gain a small performance improvement.

​

System Characterization Tests

• Make sure you have some space (minimum 10’ ideally 20’) before running
• You must characterize in a set of exactly 4 tests.
• Tests are called Quasistatic (slowly speeding up) forwards and backwards.
• Dynamic (a starting “step voltage” to measure acceleration) forwards & back
• To characterize swerve you will need one set of tests for the drive motors and one set of tests for the steer. I recommend rebooting robot code in between.

​

Command Factory API

• Simplifies new command creation. Anywhere you use the “new” keyword
• Using static imports is a way to avoid constantly needing “Commands.”�import static edu.wpi.first.wpilibj2.command.Commands.either;
• ​
• run, runOnce, parallel, deadline, race, either, select, RepeatingSequence

Command Requirements

• Rather than specify requirements directly via parameter use the subsystem being required to tell it what to require.
• intake.runOnce(intake::ingest);
• Commands created in a subsystem will automatically require
• Proxy Commands allow you to release requirements, but should be used with great care.
• ​
• Changes are incoming on the way requirements are handled in Auto. It will be designed around the use of triggers and not one monolithic command.

Command Composition

• Used to easily declare inline all of the traditional parts of a command.
• Dramatically reduces the number of commands that need to be explicitly defined in a separate file to only the most extremely complex.
• Requires all of the subsystem its composed commands require.
• ​
• withTimeout, until, andThen, repeatedly, beforeStarting, finallyDo, handleInterrupt, unless, asProxy

Returning Commands

• Many teams create commands in robot container when called and have those commands execute subsystem actions
• Instead create commands in your subsystem and return the entire command
• operator.a().onTrue(intake::deploy);
• ​
• PLEASE use CommandXboxController

Using WPILib with the XRP / Romi

• XRP is an inexpensive ($65) modular 3D printed mini-robot that can be used as an “at home” “desktop” programmers training tool.
• Can run Python or Blockly natively onboard using a web programming interface
• WPILib code can be run on your computer that has outputs forwarded to the Romi, giving all the features of the code running locally onboard
• Comes with: gyro, encoders, line follower, proximity, and a servo
• ​
• Romi is the older version running an actual RaspberryPI and allows it to use cameras onboard the robot
• DEMO TIME!

Network Tables 4

• Most teams won’t need to change anything. Backwards compatible with NT3
• You can take advantage of these features without the work using Monologue
• ​
• Uses Publish / Subscribe structure
• Static datatype of topics on Publish
• ​

Triggers

• Allows you to run robot code when an event occurs without needing to wait or constantly poll for the condition.
• Built in for CommandXboxController
• Commonly used for responding to a change in sensor value
• Can be triggered off any boolean
• ​
• Will likely be used at EventMarkers in future updates for PP Autos
• Avoids unnecessarily reserving unneeded resources

Testing FRC Robots

• Test mode can be used to enable LiveWindow (not on by default)
• Some teams use Unit Tests to verify their code.
• We have a guide for JUnit 5 but other frameworks will work.
• Instead of Unit Tests I recommend a functional test.
• This can be as simple as enabling your robot in your pit and testing out each of the mechanisms while the robot is up on blocks.
• For more robust testing you can code the robot upon going into test mode it will perform a series of actuations (pausing in between) and check for sensor feedback. This also helps ensure all of the proper sensors are working!

Debugging - Print

• Most basic debugging tool
• Logged to DriverStation Logs
• Extremely slow when compared to other types of logging
• PLEASE avoid repeated prints, especially in competition code!
• I recommend against using it entirely, there are better tools.

Debugging - NT

• Send data to NT instead of printing
• MUCH faster
• Works with Data Logging for review afterwards if something is missed
• Can be viewed with “Programming Dashboards” to graph and trend data over time. I recommend Glass or AdvantageScope
• ​
• Mention to CSA if you have Data Logging enabled! Great for debugging competition match issues also.

Debugging - On robot

• Use WPILib: Debug Robot Code from the Command Palette
• Set Breakpoints and do traditional debug actions
• Keep in mind timing of the robot and what it will do without code running!

​

• DEMO!

The End

• You can find multiple members of WPILib active on both Chief Delphi and the Unofficial FIRST Discord
• We have a booth down in the Robot Service Center. Come find me and/or any of the other WPILib members there!
• Would be happy to go through any of the other topics we couldn’t get to today at the booth.
• Slides and video will be posted to CD under the post that advertised this presentation.
• We are always looking for more contributors! Ideas, feedback, PRs, documentation, and translations all help.
• Jason Daming -> jasondaming@gmail.com