I created a topic about suggestions for PathWeaver and was seeing lots of great feedback / problems with trajectory following. I wasn’t sure if everyone saw that (I know some don’t use PathWeaver) and wanted to start a more full discussion here on the pain points teams had with trajectory following, and what WPILib can do to make it less painful.
I think an example of RamseteCommand with PID on a smart motor controller would be useful. Though, I’m not sure on how much of a benefit, if any, there is to doing PID on the motor controller instead. It could use “ExampleSmartMotorController” like other examples.
3 Likes
An example of trajectory following without RamseteCommand would be helpful.
RamseteCommand also has no logging, which makes it very difficult to troubleshoot when it doesn’t work out of the box (which is most of the time). One could also claim it’s a case of overabstraction because the abstraction breaks down so often.
I also disagree with the concept of creating a temporary controller for the duration of a command (which means I’m also against PIDCommand). It makes more sense to have the controllers live in the subsystem and make “controller commands” thin wrappers around the subsystem telling it to do stuff or go somewhere.
6 Likes
This example already exists: allwpilib/wpilibcExamples/src/main/cpp/examples/RamseteController at main · wpilibsuite/allwpilib · GitHub. I agree that we need to make debugging in RamseteCommand a lot more approachable.
But the trajectory tutorial only mentions RamseteCommand. We don’t offer any integration help for the other approach.
Anecdotal data point to demonstrate how important this is: I was helping the OP of this thread on a Discord call yesterday, and they’ve been trying to get trajectories working well for several weeks if not a month. Lack of logging or clear guidance on what to log for troubleshooting meant they had no idea what troubleshooting steps to follow (there’s a process interspersed through the trajectory tutorial, but RamseteCommand makes it hard to follow), and they were basically fumbling around in the dark after a while.
Also, my team got trajectory following working months ago, but we couldn’t have done that without our custom CSV logging + Python plotting solution.
1 Like
If there is any issues that are documentation focused, please feel free to open a corresponding frc-docs issue. I notice that there are several documentation issues that can be fixed.
I agree that this kind of feedback is essential. Instead of this, we used Field2d; that was incredibly helpful for us. We just pushed our trajectory to the field 2d in one auto command, and then to the robot in another one. It allowed us to fine-tune the waypoints and compare the expected results with our actual results.
Granted, we have only used it with the Romi thus far which is arguably a much easier device to dial in (one motor per side, less wheel scrub, and the fact that they are all similar means the characterization is approximately transferable), but it helped us a lot.
Also, in the other thread, people were asking for a zero to trajectory video walkthrough. This video helped us a lot. Thank you @Prateek_M
1 Like
I just want to say that we were able to follow the trajectory tutorial, make the modifications needed for our NEO drivetrain, and successfully follow trajectories which is a big win compared to all our failed attempts in the past with other tools. The trajectory generator and RamseteCommand are great!
I think I remember that the next the release will let you concatenate different trajectories which is pretty much our only pain point currently.
2 Likes
We had some of that too, but actually, the concatenation was a great teachable moment. The students ended up doing it in Google Sheets but the fact that they could identify the problem, come up with a solution independently, and implement it effectively (while learning the syntax to do so) is a huge win in my book.
2 Likes
Having a form of logging is extremely helpful for tuning/debugging everything from PID controllers, to ramsete, to figuring out why your robot’s browning out. On 687 our workflow involved logging from CSVs to a flashdrive on the RIO and analyzing logs in Logger Pro. while tuning pretty much anything. I believe WPILib might have a logging solution in the works (citation very much needed). Regardless, logging is an overrated underrated thing which teams should definitely be looking into.
You mean underrated based on context, I think.
2 Likes
Again, I point to the importance of all the requirements that should come on all the steps to do it right. Prime example is this thread where the student(s) didn’t understands the importance of making sure that their values for the frc-characterization ‘matches’ and make sense. And just blindly plugging in values that turns out to be meaningless. Maybe more warning/notes that ppl should pay closer attention to what they are doing each step of the way.
I wholeheartedly agreed 100000% with calcmogul, the importance of loggings are so important in every step of the way. It’s one of the most important and useful debugging tool that ppl don’t use enough of unfortunately.
sysid (the frc-char replacement) plots a simulation of the robot with the given voltages and feedforward gains to show you how well it matches the recorded measurements, so users will soon have an easy way to verify that step at least.
4 Likes
Yes, this is in our development roadmap for 2022, in two different ways:
- Upgrading NetworkTables to be logging-friendly by sending timestamp information along with the value changes and preserving every change.
- Binary logging on the Rio side, with tooling for viewing/analysis (Glass-based) and CSV conversions (for third party tooling).
My aim is to integrate these two things from the API perspective, so logging feels “automatic”.
6 Likes
Now we just need to convince ppl to take the extra time and patience to get things to work in simulation first.
2 Likes
@jdaming - We really could never get the turning overshoots/oscillations out of our robot when following pathweaver trajectories. In the end we managed by limiting the rotation rates, but it certainly cost us time by not smoothly following the paths. We couldn’t get rid of it with PID tuning or Beta/Zeta adjustments. We suspect it has something to do with some strange curvature outputs with pathweaver?
1 Like
This is one of the drawbacks of commanding zero curvature at knot points as a way to guarantee continuity of curvature when using quintic splines - it works, but it’s not always the actual shape you want.
I recommend using the clamped cubic spline implementation and computing your trajectories on the RIO until PathWeaver offers a better solution.
1 Like
Here’s an example video showing the turning issues. This path was very smooth looking in pathweaver.
Also note if we create a circular path on the rio without pathweaver, the robot can follow it smoothly.
Yeah, that almost certainly looks like oscillations in the actual splines, rather than follower error.