If you have why have you?
If you haven’t why not?
I’m working on a system that’ll have curved turning and if anyone has general warnings i’d love to hear them, then promptly ignore them
I did it once in Slapshot to maneuver between the blue and purple dispensers. We found that it was much less likely to hit something and faster. I would caution you that curved turning is a little harder, and can be more inaccurate.
1 Like
Last year, I did a kind of scuffed version of curved turning without PID (we used PID for non-arc movements though). While extremely inconsistent and heavily reliant upon drive friction, which we had a lot of last year, it made our autons considerably faster and more efficient, and I was able to make a really good (if you don’t count how inconsistent it was) 6-ball ball rush with it. I would definitely not recommend doing this unless you are hitting something that will stabilize your robot; e.g.: driving into a goal for over under.
A much better alternative (I learned this from advice I was given at worlds and I am planning to do it for this year) is to use a PID loop and scale the speeds of the left and right motors differently to create a turn. Depending on the desired result, you can use angle or position as an error metric. This is useful, but a big problem with this (and PID movements in general) is that when you chain them with other PID movements, the robot always slows down in between movements because of how PID works. To get rid of this unnecessary deceleration, you can make the PID “cutoff” at a certain error and set the target to more than you want to go. For example, if you want to go 10 inches but then do another PID movement right after that, if your PID starts to slow down around the last 5 inches*, then you would set your cutoff distance to 5 inches so that your PID stops when it is 5 inches from the target. Then you would set your target 5 inches ahead of where you actually want to stop, which is 15 inches in this example. When chaining PID movements like this, you shouldalways end the chain with a regular PID, so that your robot consistently ends up in the same place.
Without odometry, this is a good solution, but if you are using odometry, then it is probably better to use other methods of curved movement such as path following or a generic move-to-point function. Even if you are using odometry, this method is still a good backup and I would recommend implementing it.
*
I think it is better if the cutoff distance is proportional to the distance to the target, but I haven’t tested this yet so you can try that if a constant value doesn’t work.
4 Likes
I see, but the way i’m doing it is with bezier curves, theres a lot of math involved but i think it’ll be well worth it (and if it doesn’t work then i’ll do what you sugguested)
3 Likes
My team made an attempt to use curved turns for skills auton and it worked until we got to comp. So… it didn’t.
Match auton curved turns worked out for us though.
If you are using odometry, then I would recommend (based on what I have heard) path following (which I will try to do this year) over simple bezier curves. There are a few options for path following; the main ones that I know of are pure pursuit (note that there are multiple types of pure pursuit), RAMSETE (really advanced; I am trying to figure out the math behind it by reading the RAMSETE section of https://file.tavsys.net/control/controls-engineering-in-frc.pdf, but it is extremely complicated), and 2D motion profiling (open loop but still good). This is all just from what I have heard though, as I have never used odometry until this year (and I haven’t even tested it yet).
1 Like
I see… currently i’m waiting for the builder to fix some of the wheels so i can test my bezier curve approach, but if it doesn’t work out i’ll check that out, it seems really interesting (ramsete)
1 Like
Bezier curves might be a little too much. When we implemented it, we just set one side to 50% power and it did pretty well.
We use bezier curves with odometry along with a Stanley controller for curved turns. A Stanley controller is a pure feedback path follower based on the arctan of the cross track error divided by a scaling factor.
2 Likes
I’ve gotten the math down, its probably overkill but really easy to add on the way i have it set up, you input how far ahead it is and how left or right it is and how long you want it to take and how many steps, then it goes there. Complicated, yes. Modular, generally.
3 Likes