I am looking for feedback on things teams would like to see in next year’s version of PathWeaver. Some of the requested features targeted for 2021:
Cubic / Quintic Splines Toggle
More intuitive path creation (I can dive into more detail if wanted)
Reorganization of the properties (see below)
Export Waypoint to code
Autonomous (Path Group) file export that is a concatenation of all paths it contains.
Path level Max Velocity & Max Acceleration
Constraints. Including the region constraints.
Robot Outline. Wheel Path outline.
Path level start and end velocity control.
More hotkeys allowing for quicker navigation.
Here is an overview of my proposal for what the different properties will look like. The current waypoint properties will instead display the properties for whatever object is selected (waypoint, path, or auto):
Any thoughts on allowing the project paths and output paths to be done relative to… hmmm… something? I’m not 100% sure…
The main goal I’m thinking of is putting a project inside a robot code git repo, having it spit out generated files to another folder inside that repo (but specified relative to the project directory). The avoidance of absolute paths would prevent issues when the repo is pulled on someone else’s PC at a different folder location. I suppose this could be accomplished just by having the project path be whatever directory the project files are at, and making the output directory relative to that.
Along those same lines - thoughts on command line and/or gradle integration support? The goal would be to ensure that generated files are up to date as part of a robot code build/deploy cycle.
In any case… Take these with a small grain of salt, I’ve only spent about three hours this season actually trying to use it. These were just things I ran into in that time frame and couldn’t immediately see a solution, so figured I’d toss them out here.
I think it currently does this if I am understanding you correctly. I for example have my (and recommend other do too) PathWeaver files in my Git repo. PathWeaver has two set of files it outputs one is the files to the PathWeaver directory which I would advise teams never to touch, the other is to an output directory you specify. By default if you specify the root project folder it will go to the deploy directory that is automatically transferred to the roboRIO.
The at home challenges were unique compared to a normal game in that they had many different fields and that required keeping different PathWeaver directories for each challenge but I think that is mainly a problem with the uniqueness of this year.
I have written a path generation (Index of /xeroprogs/xeropath) program and some of the features I have found most useful are …
Cut and paste waypoint pose, shift paste to paste with the heading rotated 180 degrees. Helpful when creating paths that are back to back, but the second one runs in reverse.
Plot of position, velocity, and acceleration along plot. Very helpful in teaching how path generation works and how the robot follows a path.
Ability to print spline equations on the screen. Must also be able to turn off. Useful for teaching path following.
Command line mode that could generate the paths from the waypoint as part of a build process.
Scrollbar allowing you to “drive” a robot along the path and see time, position, velocity, and acceleration values along the path. Also useful in teaching how path following works.
One of the next features I am going to put into place is the ability for the path generation program to “publish” to the robot. This will may also require code on the robot side depending on the approach. Basically, while tuning paths, I can run a “publish” step that will save the path file, generate the paths locally to the target directory, and then connect with the robot and push the updated files to the deploy directory on the robot. This will save time while tuning paths and prevent one of the most common errors in tuning where a path is changed, saved, and generated, but not deployed to the robot.
Just a handful of my thoughts …
Thanks for the good work on this tool.
It would be wonderful if there were a better interface for adding custom fields. It would be extremely helpful if Pathweaver used the same .json that FIeld2d uses (which we have gotten working successfully to great effect, but it is slower because we have to guess at the waypoints first).
We are having difficulty using custom fields and robots with Pathweaver. We can write the .json, and they seem to load, but the coordinates are off the edges of the frame so, there is no way to edit the waypoints.
To that end, if you could see each waypoint without clicking on it first, that would be helpful.
Here is an example of what we are seeing (I do not mean to derail this thread, I am just reporting what we see)…
We implemented circular arcs for our IR@Home skills challenges; this experience suggested that wpilib trajectories could be based on a more general, parameterizable curve class, instead of being restricted to only spline curves. For PathWeaver, it makes one think about ways one might specify circles, points of entry and exit, transition curves (so you don’t have velocity discontinuities when moving from lines or other paths to arcs), etc.
We used a text-based specification for our paths this year, but adding a tool to build them visually is certainly appealing.
Can you elaborate on the differences you’ve found between the Field2d JSON and the Pathweaver JSON? They should be the same (Field2d was designed to take the Pathweaver JSON). Or are you saying that you wish Pathweaver had a GUI to create the JSON file?
Hello. Unfortunately, I cannot elaborate on the differences save that the .json above works in field2d, but does not in Pathweaver. I wonder if either, there is a bug, or if I am missing a step.
By works/not work, I mean that in field2d, every waypoint we enter is 1-1 with real-world geometry.
In Pathweaver, if we finagle the scale, (in the project selecting inches or feet rather than meters, we can see at least one of the waypoints, but if we select the units the project should be in, we do not.
This seems to happen with every project we create manually. However, not with the example projects in git. I will play a bit to see if I can flesh out what is hapenning a bit more.
I’d love to see the ability to write expressions in the coordinate fields like you can with dimensions in CAD sketches. I’m guessing you could use something like Jep Java.
Something like:
X: 3.5 + .67
As a stretch, have the ability to use user-defined constants such as lengths and points.
X: 3.5 + robotWidth
X: 3.5 + pointA.x
Neat program! I would encourage anyone writing a program like this to consider talking to WPILib and seeing what can be done to include / integrate development. We can always use more help!
I agree that pasting is a good idea. But I would really hope to avoid needing to do it in most cases. The PathWeaver reverse spline feature automatically makes it go backwards. We are also adding a feature that when creating a new path with Waypoint selected instead of it going to a random spot the first point of the new path uses the selected waypoint so you would just hit reverse spline a go from there no copying needed.
I added this as a feature but I think I am going to hold off on 2021 as I think it is of limited usefulness outside of teaching.
This is pretty much handled by PathWeaver via the files being placed in the deploy directory such that a code deploy will automatically push them.
This is resolved in this PR that has already been merged. PathWeaver was hard coding the default path at like 10 feet and since this field was so small it went off the edge.
Another thing that I didn’t list about but I began to add in this PR was a waypoint list. That would allow you to view and manage all of the different waypoints associated with a given path.
Lets debug this. I helped someone in this issue get that image working. There was no issue with the JSON.
Thank you for your wonderful reply. I had just figured out some the main issue is that all of our fields are so small :).
Issue 1: the beginning pose is at 0,0 so there is no way to grab the handle.
Issue 2 involved the waypoints of the default path. It seems relatively easy to build pathweaver from source, so I wonder if it would be easier to just use the updated version.
If anyone does not want to go that route, I was able to get a solid path using inches as the default scale and moving the top of the field down a bit. However, when I try to open a new path, the same issue seemed to reappear.
Issue 1: We always include a bit of area around the field just for this purpose. Even if it is just 10% white space on all sides. I now realize this isn’t documented and isn’t obvious so I created an issue
Issue 2: If you don’t want to build PathWeaver from source you can always go into the PathWeaver/Paths directory and adjust the X and Y values of the waypoint you want. It will look like this:
Thank you. That is incredibly helpful.
All this playing with scales brings up a related question. If we output the trajectory.json in inches, is WPILib going to convert that to meters on import? Currently, we are casting each pose and waypoint using Units.InchesToMeters(). But, we are not yet using Pathfinder due to the aforementioned issues (but will start now. Thanks).
Detail Video Tutorials…not just on how to do certain function/feature but the WHY and WHAT this function/feature are for.
From my observations, the more and more advance software are GREAT…in principle. or to teams who has a solid SW foundation already (or mentors who are already familiar/involved). But too often, you get a lot of teams who are just cutting and pasting and are completely clueless as to what is it that they are doing (both students and possibly mentors too). I feel that if there are more video tutorials (like the from Zero to Robots) but more specific topic and promoted/stored/linked right off the WPILIB docs, those would be great for not only the advance team but for the newer team that are just starting.
I think PathWeaver Video Tutorials are definitely possible but everyone must remember that PathWeaver can only get you so far the real tricky part is getting your robot to accurately follow the paths that PathWeaver creates.
Video Tutorials are tricky, they seem to quickly get outdated and there is no real way for us to splice them in such a way that we could just cut out or update the parts that are outdated (may only be 10% of the video). I agree that more beginner oriented documentation is needed but I think people also need to be realistic that this is HARD! Trajectory generation and following has been traditionally only been done by elite teams. While all of the new WPILib features make it MUCH easier to accomplish it is still really hard and requires a good understanding of a lot of other programming / controls fundamentals (PID, characterization, feedforward, odometry, simulation etc).
I would generally say that teams that are “just starting” probably shouldn’t be doing PathWeaver and should be focused on PID, sensors, Command Framework, simulation and source code control as their “reach goals” before they come anywhere near trajectory generation and following.
This is actually something I used a fair amount in vannaka’s pathfinder gui. It’s very handy for optimizing the paths. Although I agree it’s a tertiary issue.
I was thinking whether 1) there were any whole path manipulation tools and 2) whether there was any specific needs for that.
For example if you could select the path, and drag the entire path to a new starting point. Or if you could select the entire path and then sort of like an image, grab corners or edges to scale the entire path, possibly scaling X & Y or each separately. Or with the whole path selected then you could rotate the entire path, or with a difference selection mirror it (though some of that functionality is readily accessible).
Honestly, don’t really know if whole path changes like this might be useful, if this would be easier or more intuitive (treating more like image manipulation) than already available stuff, but it’s a thought.
