Since the was no official “autonomous period” last season, my team is wanting to make a test auto before the season starts. In previous years my team has done very simple stuff (i.e go 3 feet, turn 90 degrees, go 4 feet, etc) but we want to have a more elaborate and effective auto if this years game calls for it. I could be wrong but it seems teams with insanely good autos typically do well, a stand out being team 254 in 2018. I was looking at their code on git hub and noticed something about path following, but it doesn’t seem to be the Jaci’s path stuff I’ve seen that used pathweaver. Did they create their own or something? My main question is how effective would using Jaci’s pathfinder be over your simple auto that I mentioned before? Also, I can’t seem to find any tutorials or documentation that relates to Jaci’s pathfinder specifically other than this . Are there any other helpful resources?
The documentation for generating trajectories is here.
PathWeaver is in the process of being updated to support the new WPILib trajectories.
A full example of a robot project that follows trajectories during the autonomous period is here.
Note that to use these classes, you will either need to copy the required classes out to your own robot project or be a beta team with access to the new roboRIO image. The 2020 release of WPILib will be available on Kickoff day.
Many teams high top tier teams have created their own because the level they wanted to be at was above the available resources at the time. Each typically have the same basic outline: Create a path, create a trajectory, follow that trajectory. How they accomplish those tasks can vary.
While it is true that strong autos typically accompany strong teams, it sometimes is more of a correlation then a causation. A great auto means a team can control their robot very well. This means their mechanism functions reliably, quickly, and predictably. There are many steps to along the way to getting a “knock your socks off” auto that make those teams preform better.
It really depends on if you can control your robot. Your “simple auto” might seem like it not “fancy” enough to compete against others, but many robots barely move in auto! Jaci’s pathfinder used poorly is a million times worse than your simple auto, because it wouldn’t work.
With it being so close to build season, here is my advice. Don’t give up on motion profiling, but make sure you have one kick-butt “go 3 feet, turn 90” auto first. Don’t make the mistake of soaking tons of hours into something complex unless you know you’ve got a fall back plan.
Let me know if you have any questions about the inter-workings of anything, my roommate and I have been spending many late hours working to learn motion profiling so we can teach our students properly. (Even installing 18 sq ft of hidden whiteboard in our room just for the occasion)
Most teams look at the best and said, “Wow, they do everything great, I want to be just like them”. Their problem? You only get to choose one to start, and many choose everything over great.
In addition to what @Prateek_M mentioned, there’s a 2020 tool for automatically tuning your drivetrain feedback controllers for trajectory tracking (the resulting tuning is theoretically least-squares optimal). All you have to do is let it drive your robot forward and backward a bit.
We’ve had several teams get their robots from nothing to following a trajectory accurately within half an hour.
I genuinely appreciate the response! Since I’m very new to this whole trajectory tracking, could you explain what you by tuning drivetrain feedback controllers? Are you referring to something like PID control? I am very familiar with that, we have tried to implement that in the past.
You are correct about 2020 being the first year trajectory generation is available in WPILib. The new changes for WPILib are not able to be tested just by updating your WPILib version because the new WPILib versions cannot run on the 2019 image for the roboRIO.
So, if you want to test these new changes, you have to do some copy and pasting magic. You can copy the required classes to somewhere in your robot project and then import them just like you’ll be able to do in 2020.
For some classes, this isn’t easy because many things in the WPILib library depend on so many things. Luckily, I think the path generation is relatively simple so it doesn’t depend on too much.
Yes it’s PID control. A typical PD controller is two proportional controllers, one on position and one on velocity. We construct a mathematical model from the characterization’s Kv and Ka, then use some linear algebra to find the optimal P and D gains. We use an LQR for that. If you’re curious, consider this optional (and frankly not recommended) reading: https://en.wikipedia.org/wiki/Linear–quadratic_regulator.
Teams were able to do simple 2017 autos without path planning, and do them reliably (> 90% on the side peg). We prefer KISS, and “Crawl, then Walk, then Run” mentalities. It’s worked way better than an over-built path planner that only needs move in a straight line.
For 2018 & 2019, path planning helped tremendously if the robot c.g. had to shift (e.g. raise an elevator) while the robot was in transit. 2018 was still doable without path planning, but our cross-field scale autons were pretty unreliable. In 2019, driving in the Sandstorm was just as reliable as a dead-reckon straight-turn-straight type of auton. Driving was usually faster as well.
Path following also has a role in vision tracking. If a path can be generated fast enough with the appropriate initial conditions, then following it live is more reliable than using vision as a raw gyro PID (due to relative alignment of the robot to the scoring location).
5499 had good success with pure pursuit path following. The students were able to develop it over the 2018 summer, and had a lot of prior art to “steal” from other teams. I wrote a quick (and unfinished) intro about it.