New Path Generation Front End

This past season Error Code Xero took our first shot at path following. We used Path Weaver to generate the paths and a simple follower that was seen in other robot code that was a modified PID with feed forward terms for both velocity and acceleration. We also use a NAVX for correcting the heading. While teaching the students about path following via many white board sessions, I wished I had a tool that would do a better job of demonstrating this to the students. To that end, I have spent a great deal of time this off season creating my version of a Path Weaver style tool. In addition to making something more usable, the idea was to make something to help in teaching path following to each new generation of students as they come through.

This is all alpha code, don’t bet your season on anything here. I’m sure there are things I got wrong as I am learning, so feedback welcome.

It comes with the last two years field. It comes with a version of the Jaci Path generator, a generator taken from the Cheesy Poofs code, and a couple of highly experimental backend we are working on here.

This tool has the following features

  • 100% open source
  • Display the X and Y spline equations generated from the waypoints.
  • Plots the trajectory profile below the field window
  • Velocity constraints as a function of distance along the path for those generators that support it
  • Output trajectories as JSON or CSV
  • All generators are separate program. A new executable program and a JSON file describing it is all that is required to add a new generator backend.
  • Uses the Path Weaver format for game fields so the next year’s field should drop right in. There is also a download capability so when the new field is available, it can be dropped automatically detected and downloaded.
  • Undo
  • Uses your units of choice (inches, feet, meters, cm, etc.)
  • Arrow keys (position)/Page Up (rotate)/Page Down(rotate) movement of waypoints
  • Ability to publish generated trajectories to network tables for quick tuning of paths
  • Ability to print paths, helpful for documenting automodes
  • Help documentation (not my strong suit)
  • Demo mode so you can see paths in action.
  • Written in C++ and Qt so there are Windows, Mac OS and Linux versions. I must say I am way more familiar with Window so the Mac OS and Linux versions may need more work.

Jack (Butch) Griffin


Sweet, this is excellent. Having some fun playing around with it now. A few suggestions:

I assume the Velocities/Accelerations/Jerks are all inches-per-second* ?

The help documentation was super useful, and just the right size. I wasn’t sure what to do when I opened the GUI (and clicking around randomly didn’t have productive results). But, five minutes after reading the help docs, I knew exactly what to do. Maybe have something to either walk people through the process the first time, or point to the documentation on the first launch?

Finally, any way to provide a customized field? And/or will the 2020 game be added within the first week or two of build season? Derp I can’t read.

But other than that, this is excellent. I love the integration of multiple path algortihms, and how smooth and easy it is to adjust and visualize the paths. The generation to CSV/JSON in a specified folder is exactly what I’d be looking for - keep the path source files in the repo, generate csv’s into a folder that gets copied to the robot, parse the files at robot init - all super sweet.

This actually gives me one more idea - is there a command line method to generate paths “headless”? I’m thinking integration into the gradle build process to ensure whatever paths are archived are always freshly generated to CSV files, every build.

I think the team will definitely find this useful this year!!

The velocities, accelerations, and jerks are all in whatever units you put into the units field. There are actually two different units fields that are important. First, what you show is the for the robot. Enter the units you want to use in the second item there and that is the units used for the velocity, acceleration, jerk, etc for the robot. There is a second units field in the Edit/Preference menu that gives the units displayed when interacting with paths on the field. These are the u nits used when editing waypoint fields, path velocities in the path properties windows, etc. The idea is that on the fields you have the units you like to work with. In our case its inches. Other people prefer feet or metric. However, you may get a robot file (via the robot export/import feature) from anywhere and therefore the units for these are independent.

It may seem a little confusing, but think about the robot units independently. The units for the robot internally get converted to field units before being used.

Thanks for the suggestions. I’ll start looking into them this weekend.

Jack (Butch) Griffin

Gotcha, the independent units make sense to me. For us, robot is usually in inches, but field locations in feet. It’s all about intuition. I much more readily can imagine “about 12 feet” than “150 inches”.

I have added a new executable program called “PathGenerate”. It is a command line tool that will take a paths file and generate the trajectories giving you ability to create the generated trajectories in the gradle build. It does require that the application be installed on the machine and that the robot be present (created or imported) on that machine in the robot database. I am working on the ability to check the robot file into GIT (so decouple this somewhat) and refer to the robot file via the GUI tool as well as the Path Generator, but there is a bit of work to do there as of yet.

I’ve also added what our team calls flags. Flags are a range within the path, identified by distance along a path, where the flag is true or active. You enter an after distance (where the flag goes active) and a before distance (where the flag goes inactive) for the flag. When the path is generated, a flags file is generated for the path if a flag is present. The flags file contains the flag name and the active and inactive times for the flags. This can be read by the robot code and used to set flags in the robot code. Flags are used in our robot code to cause locations along a path to initiate actions on the robot. For instance, you can set up a flag such that two thirds along a path, the flag goes active and this in turn causes a robot ARM to be raised. These are basically path drive events, but the word event is so overloaded that we used the term flag to refer to these.

Jack (Butch) Griffin