Our team is using YAGSL and pathplanner to follow a path 2 meters forward and 2 meters back to the original position. We have been unsuccessful in getting the robot to go precisely 2 meters. It’s usually off by 4-6 inches.
What we did so far:
Used FRC Web Components to tune swerve pod velocity and turn.
Used Path Planner telemetry to tune path following and rotation adherence.
We’ve set the drive and turn conversion factors in YAGSL to the correct value (hopefully).
I’m wondering if anyone can share the steps they would take to tune and configure their swerve system. Am I missing something? Thank you!
Do you have to specify wheel diameter? A small inaccuracy on that will result in a pretty large discrepancy. For example, if you have your wheel listed as 12.56cm diameter, and it rotates 30 times, your kinematics will think it moved about 2367.5cm. However, if in reality the wheel diameter is only 12.5cm, then the robot will have only moved 2356.2cm. That is a 11cm(4.33in) difference resulted from an inaccuracy of 0.06cm(0.02in) from your initial wheel radius measurement.
Another thing to note is that for path planner, while accuracy is nice (hitting the 2 meter mark exactly), I would be much much more concerned about precision (hitting the same point every single time). So if you are off by almost exactly 5" every time you run path planner, then you can account for that inaccuracy with the path drawn in the UI. Even if this is not ideal, it is fairly easy to work around such an issue.
That’s a great point, I would much rather have consistency over precision!
We have the billet wheels which I believe are 4inches exactly.
I guess what I would like most is to know whether we are following a suitable, repeatable process for getting the most out of our system. There are a lot of different components and factors to this system.
The ultimate goal is to have students understand how to take a machine and end up with code that can control it to a high degree of accuracy, i’d like to know that we aren’t missing steps in this characterization and tuning process.
Well, you mentioned that you’re USUALLY off by 6 inches. Is it ALWAYS the same offset for the same trajectory? That’s what would tell you whether you have a conversion/calibration issue, like indicated by Andrew above, or you have a PID constants or other issue.
In our case while we do not use YAGSL we calibrated linear motion (translation from wheel rotations to meters) manually and experimentally, precisely because both the wheels and gearbox have tolerances, which would accumulate over time.
On the other hand, if running the same trajectory twice ends at two different spots, that’s much bigger issue, and in my experience USUALLY indicates either a drag issue (some component occasionally rubs around part of the frame, bumper etc) or a PID/characterization issue, especially if your PID is on 20ms loop (meaning uses CAN-connected encoders to track wheel turns).
An answer i was thinking about in regards to this may be my fault, 4-6in may be good enough for most to test their paths but if you true precision don’t use my getDrivebaseRadius function as that only takes into account your wheel drivebase radius (which goes from center of robot to center of wheel) about 4-6in cutoff in diameter
If the tread on the billet wheels is worn, it can be substantially less than 4" diameter. The tread wear can be significant enough to cause an auto to drift as an event progresses if its not replaced during comp.
They’re probably not; at least, not to the level of precision that’s needed for 4.00 inches in code to be accurate for odometry. It’s gonna vary a bit with the tread, and they’re also gonna get smaller as the tread wears. Just as a quick reference from a known MK4i billet wheel team, 1678’s public code release has a 3.85" measured wheel diameter. And if my math is right, a 3.85" wheel that is being treated by code as a 4" wheel is gonna undershoot around 3" over two meters.
It’s good practice to regularly measure all 4 wheels; they won’t necessarily wear at similar rates due to uneven weight distribution. You could also consider moving the robot a known distance (say, three meters) and back-computing wheel diameters based on the reported encoder readings from there to have something to compare physical measurements to; it’s not always obvious how much the tread will sink into the carpet, lowering the effective wheel diameter.
If I was to print a process on a piece of paper for students to reference, how would that process look for some of you?
Use FRC Web Components to tune PID of swerve pod velocity and rotation.
Use PathPlanner telemetry to tune PID path following (found here) and rotation PIDhere.
Create a Path that moves the bot forward 2 meters. Drive the path and measure the distance traveled.
4a. If the value is consistent, rejoice.
4b. If the value is inconsistent, check for mechanical issues.
5a. If the value is the expected distance to travel, rejoice.
5b. If the value is off, create a shorter and longer path, does the distance error track linearly?
Add a fudge factor to multiply to the wheel diameter to try to reduce the error???
Test with more complicated paths that include rotation and more complex motions.
Wouldn’t the radius and conversion provide a consistent inaccuracy? As @atsekhan mentioned, if the measured error was different each time it may be do to some kind of issue like a rubbing bumper or perhaps a poorly greased pod maybe?
If you see it instantly then yes, however treads wear out over time (you could measure them after each match and give valuable data for everyone to find out exactly how many matches one set of treads last).
Yes! Can you suggest a process for a student to follow to dial in the rotation? we’ve lacked in that area in the past for sure!
Would it be to create a path that turns the bot 90deg and utilize PathPlanner telemetry to tune the pid found here
? Or do you have a more rigorous set of steps? Thank you!
Yep, I’ll work on that. Perhaps I can get a few more folks to chime in.
A lot of documentation just says “tune your pids”. As a less than intuitive person, it’s been a struggle for the last 7 years to figure out what to change where and when! I’m sure others stuggle with this as well. I’ve also noticed that if I struggle with it, I’m less likely to involve students and then they become disconnected from a large section of the build… the swerve drive!
That’s a great point Joe, we also struggled with the technical issues of getting the path working in code, which introduces other distractions in the process, so that could be a later step after the initial distance errors are smoothed out.
Colsons will also wear over the course of the season, at least to the point that it has an effect on odometry. Every widely-used wheel in FRC will.
It’s a good idea to manually move the robot with locked rotation (ideally with long blocks or similar making sure the modules are perfectly straight relative to each other) to sort out the distance errors in the first place. You don’t want any wheel slippage due to slightly rotated modules while calibrating your wheel sizes.
