Extend PathPlanner to build paths for FLL competitions

[WarrenReynolds]

Feature Request. I know this is not what PathPlanner was initially designed for but with the recent enhancements to load you own background images with the pixels per metre option, this has now opened this product up to the FLL space. Would it be possible to scale the size of the control handle dots relative to the field image size so they don't cover so much of the screen when a smaller image is loaded like the one shown below (approx 2m x 1m image)

[bckircher]

@WarrenReynolds I'm very intrigued by this! Is your team using this for purely planning purposes, or do they have code that can actually follow the trajectories that are generated by PathPlanner? My FRC team used PathPlanner last season and were very happy with the results, now I'm wondering if/how I can integrate it into my FLL teams...

[WarrenReynolds]

@bckircher Hi Brian, This was our first year using pathplanner also. We also took on swerve drive for the first time as well, so pathplanner was the perfect fit for us because it allowed us to build the paths for the 5 ball auto incorporating the holonomic rotation along the path. We didn't get it working for the official season, but once we ironed out some pose initialization problems we manged to nail our 5 ball auto in the off-season events in Australia. In regards to using pathplanner for FLL, in my current roles I mentor 11 FLL teams in coding. So I'm always looking for next level stuff for when that group of students comes along that can really run with something. A couple of years back I worked with an FLL team and we built a trapezoidal follower that tracked perfectly straight trajectories to the millimeter with the smoothest acceleration and deceleration. It worked using 2 simple proportion controllers on a moving setpoint on each side of the lego robot with most of the work being done with a velocity feedforward. It never went any further then a straight line follower.
But now that the spike prime has hit the scene with heaps less backlash in the motors and a really good gyro I think this could be revisited by building an inside and outside follower. One PID controller tracking the distance travelled along the path and another controller applying adjustments to each side to drive the heading error to zero. A bit like the way CTRE do trajectory following on the Talon SRX's. A couple of things need to be done. Firstly you need to post process the CSV file generated by pathplanner to have a running distance column (another feature request there maybe, I think this could be very easy to do as I assume this value is already known when generating the trajectory.) Then all you would need to do is build a follower. To do this, initialize a timer at the point in time that you start following the path. On each execution cycle calculate the time since starting. Step through the array of trajectory points, keeping track of the previous point as you go along. As soon as you find a point that is in front of the current point in time, do a linear interpolation between the last point and the current point to find the current desired heading and desired distance for that exact point in time. Then feed these to two setpoints to the distance and heading controllers.
In theory this could work, and now that pathplanner can be used to build these trajectories for a Lego table it's just a matter of finding some students that want to go to the next level. Cheers

[WarrenReynolds]

I'm very intrigued by this! Is your team using this

Video Showing Spike prime robot following a path generated in Path Planner

The follower that ended being built used distance travelled as the indicator that stepped it through the trajectory points instead of time. We found this to be easier to implement as the internal PID controllers on the move at speed blocks looked after making sure the robot was moving at every point.

The excel sheet that is generated by Path Planner was post processed a bit. A column was added that calculated the distance travelled for each point on the path from the delta x, delta y between points. A cumulative distance column added. In another blank sheet a column was added with 0.1 increments in left most column (Representing time) A vlookup was used to reduce the list of points from the trajectory list down to a list of points every 100ms. (about 40 points for the path shown in the video) A formula was added to convert the distance traveled from metres to degrees turned on a spike prime wheel. Another formula was added to covert m/s to Percentage Speed. The file was exported as a CSV List. Fixed width fields so the values could easily be extracted in scratch Then the file was feed through a CRLF cleaner as the Spike software doesn't handle CRLF pairs at the end of lines when importing lists. ( Linux issue here)

This path was followed using scratch based code. Based on a simple my block that tracks a heading (corrects on gyro error) for a distance (repeat until degrees counted > ) at a % speed level. A list of trajectory points was stepped through that had degrees of wheel rotation, heading to track,, and percentage speed from the spreadsheet above.

Also tried feedforwarding the the path curvature, but didn't really make that make difference so dropped that option.

[bckircher]

That is really cool! If there is a particular data format that is easily ingestible into a Scratch trajectory follower (i.e. all those computations you describe above), that can be packaged up into an "FLL robot" output from PathPlanner and none of the conversions and massaging and whatnot that you describe would need to be done manually. Change the path, take the output file and put it into the Scratch program. Done!

[WarrenReynolds]

In the end we managed to get it down to opening one excel file that had hard links to a CSV file that was created by PathPlanner, one copy paste operation and then run one macro in excel. This did everything required and saved the file ready to import into scratch, so it wasn't too bad as we could adjust paths fairly quickly. I'd have to do a lot more work to make it user friendly enough to use by anyone. At the moment all the paths and linked files are all hard coded in the macros and worksheets, so I'd have to add file pickers and modified the macros to build the links between files on the fly at run time. Maybe a project for next year's FLL team as part of the sharing their knowledge section. Alternatively I could learn dart and flutter and then suggest a feature update to PathPlanner and provide the files that do the work. I don't know if I've got it in me to learn another language.

Which file/s in the PathPlanner repo are the ones that build the CSV export files. I could start by having a look there I suppose. Cheers Warren

[bckircher]

In lib/robot_path/robot_path.dart, it starts with the savePath() method. Most of the heavy lifting, though, is in lib/services/generator/trajectory.dart and its getWPILibJSON() and getCSV() methods. Based on what is in trajectory.dart, create a new method to generate the export you need, then add an export of it to savePath() (based on a checkbox, like the others, which has other tentacles in lib/widgets/dialogs/settings_dialog.dart).

[WarrenReynolds]

Thanks Brian, I had a quick look and I think this might be a bit beyond my current skill levels. Also do you know how the I would deal with making sure the last character in every line of the export is only a LF (0x0A) instead of CRLF (pair? (0x0D 0x0A) It needs to be in this format for the list importer in scratch to work.