[POLL] Why didn't you use the WPILib trajectory generator this year?

WPILib has a new trajectory generator, relatively complete system identification tools, and tons of documentation for all of it. If you didn’t (or did) use the WPILib trajectory generator it would be great if you could answer the poll. If you avoided the trajectory stuff because it lacked features you need, or because you found something was difficult to use then it would be great if you could detail your case in a reply to the thread! Let everyone know what features you want, or what you found difficult or confusing.

Why didn’t you use the WPILib trajectory generator?

  • My team used it.
  • We have our own trajectory generator with more features.
  • We have our own trajectory generator that we know better.
  • We didn’t know it existed.
  • We never got it to work well.
  • We ran out of time and didn’t try it.

0 voters


I think good physics simulation will help address “we ran out of time and didn’t try it” at least (we’re working on it for 2021). Not having a complete robot to test trajectory generation on before competition is common.


Never got around to it, plus we had issues with one of our drivetrain encoders we were trying to debug before all the stuff went down.

We used it, but I wouldn’t recommend it (in its current state) to teams without programming mentors. It took a fair bit of patience to set up - we ran into a few issues:

  1. We goofed up on units in the characterization tool, which is a common mistake, but an easy one to make

  2. Field-relative (as opposed to robot-relative) trajectory generation was a minor pain that we wound up not having time to finish (this was mostly due to us messing up gyro math, not necessarily the trajectory generator being at fault)

  3. We found a bug fairly early on (thanks to Oblarg for the fix) with short paths (even paths that were just “drive straight 2 feet”), which didn’t inspire confidence and took a few days of auto off the schedule

  4. It took us a bit to work out a system for making paths easily without Pathfinder (we have no real reason not to use Pathfinder though); while WPILib’s API is fine for now I think it could be improved with some small utility classes.

Overall, I’d use it again next year, but mostly just due to us having experience with it. Many high school students (and even college students) are unfamiliar with launching an executable from command line, so while the current characterization tool works, I think a more beginner friendly way to launch it would be better. It would also be nice to be able to configure a permanent unit so that we can always work in, say, inches, and have WPILib auto convert to meters for Ramsete on the backend.

I’d say it took us about 15-20 hours with active mentor involvement to go from nothing to acceptable pathing. Another 10ish hours of utility code design & implementation to make it easier (for us) to make autos.

Additional thanks to Prateek from 5190 for the example repository that we could reference.


While we did use the WPILib trajectory generator, we wrote a decent amount of code to support using it with the Neo and Falcon internal encoders, along with encoders connected to Talon SRXs. I think some sort of WPILib function to make converting from Talon/Spark internal units to meters could be helpful for a lot of teams.

That sounds like something vendors should provide since they decide what their internal units are, and they can change them for arbitrary reasons (and have in the past). We don’t want WPILib to take a dependency on that since it makes things fragile. Someone should reach out to REV and CTRE to support conversions to SI units though.


For what it’s worth, it’s been pretty clear that the way we handle units is a major pain point for frc-characterization users, and there is a bunch of refactoring planned that will allow you to enter your units once in the data logger and have the tools “remember” from there.

Command line avoidance isn’t really in any plans that I know of (i.e. Oblarg hasn’t said he’s planning to do it and I’m not either), but it’s always good to be reminded how difficult the “install Python, use the command line to install frc-characterization, and launch frc-characterization from the command line” workflow is. The best way to deal with this would probably be to bundle frc-characterization and Python with the WPILib installer and modify the VSCode plugin so that you can launch from VSCode… This is a fair amount of work, and also a big change to how we do releases (right now once a PR is merged we have CI push it right to PyPi); this change would tie us to the WPILib release schedule.


We ended up having the infamous issue where the characterization data looks very wonky when using CTRE MAG encoders. This issue is mentioned in the frc docs I think. I made a rogue simulator to see if our trajectory code would have worked in autonomous and it looked amazing. We ordered REV through-bore encoders a few days before the FIRST season was suspended.

Simulation for anyone curious: Simulating Drive Train accurately and Limelight for Autonomous

I think we can still publish to pypi. We could have the installer release pipeline bundle the latest version published at the time in a venv. venvs bundle a python binary as well, so it’s self-contained. https://docs.python.org/3.8/library/venv.html

For me, I preferred to make my own trajectory generator. While I do see WPILib as a good resource, for me at least it’s too black box and I personally don’t like to just take software without fully knowing how it works. That’s for me at least, I don’t have a problem with others using it.

Here’s a presentation on how it works:

1 Like

I really wish we could get to the bottom of the various sources of encoder noise that teams have encountered. It’s baffling.

The only noise whose root cause we really understand is the discretization error on the timing when using the WPILib Encoder class, and that’s maybe a third of all cases that we’ve seen.

I’d love to organize a more rigorous investigation into what causes noisy encoders, but am extremely busy with work at the moment. Later this summer I’ll see if I can recruit a few teams to gather a more-curated data set.

1 Like

Curious, if the source code is available (and it is), what else is required for it to not be ‘black box’ for you?

1 Like

Tyler already linked my trajectory explanation slides, but if you want an accompanying video of me presenting those slides you can find that here.

I think I’ll add a little button on the first slide that links to that video.

I’ve seen that resource before and it’s pretty helpful. I have successfully implemented a splining tool + trajectory generation for a differential drive robot and working on implementing a generalized state space controller for my team. I probably should’ve worded my intent better. I find more satisfaction in making my own code than just using a library. I acknowledge that wpilib has a more robust and advanced trajectory generator than my own, but for educational purposes I took on the challenge to try and make my own. If it came down to it during build season and I was running out of time, I wouldn’t hesitate to use WPILib. But seeing how there is so much time in between build seasons(and a certain pandemic going on right now), I feel as if it’ll be vastly more educational for me if I tried to implement the techniques used in wpilib in my own code. Sorry if anything came out as passive aggressive. WPIlib is a great resource and if it came down to it, I wouldn’t hesitate to use it.

1 Like

Funny you should mention that. :slight_smile:

That’s fair.

We didn’t use it because there is no support for LabView. We did however build our own trajectory generator for the first time this year.

1 Like

oh geez, state space for wpilib? That’s some exciting stuff. Will there also be kalman filters added as well? Also would users have to define their own State Space matrices or would wpilib derive them based on a pre-made model?

1 Like

There are some premade models, but you can do your own. We also have a Kalman filter, Extended Kalman filter, and Unscented Kalman filter, along with latency-compensated localization wrappers that use those.

I wrote the Java EKF in that PR so that I could use it on our robot this year, and we fused vision, VSLAM, and encoders to localize ourselves.

Yea, this is probably as close as you can get for now: Ramsete Path following and Labview. It sounds like they didn’t actually wrap the new trajectory generation.

The majority of our developers only know C++ and Java. It’s actually very hard to (1) find competent LabVIEW programmers that (2) are interested in and have the patience for contributing to WPILib and (3) actually facilitate the contribution process on our end; if the FRC palettes are open source to begin with (idk if they are), they certainly aren’t accessible to contributors.