Quote:
Originally Posted by Doron_Sivan
Thanks first for your comments.
Kevin, I would really like if you'd post the code. I've never used F and I'm not familiar with it. It would be nice if you'll explain more how it affects the stablizing.
xmaams - even that you don't use it in the matches - did your formula for finding distance worked? And can you post an explanation / the roborealm code for that (if you want to..)
Also, because we used also RR - have you experienced laggs on the robot when running code + RR at the same time?
|
I've attached a zip of our testing codebase. This one is currently set up for tuning the PID for the shooter tilting, but it's easy to switch it over for tuning the shooter wheels.
F term is feedforward. It's not based on feedback or error, simply on your commanded setpoint. So the output is the tradition PID Output + kF * setpoint. This is pretty much required for using a traditional PID to control a velocity. The idea is that if you know the speed controller command it takes to reach a specific speed, you can build that into your controller.
Example: Through open-loop testing, you know it takes a command of 0.75 to reach 7500 RPM. So you set kF = 0.75/7500 = 0.0001. Now, when you give a command of 7500, the output is going to be the usual PID output + 0.75. Your P and I terms only have to compensate for pulling you up to speed and any error in the kF predicted open loop command. It makes things react faster and stabilize better since you don't need P and I to build up large enough to create the 0.75 you need to be at 7500 RPM.
You'll see in there that I'm using my own custom AdvPIDController. It doing integral anti-windup slightly differently. It pre-calculates the PID output, and if the output is saturated and in the same direction as the error, it doesn't integrate the error for that cycle. Doing it that way really reduces your overshoot, as you're not adding integral action at the beginning of a step move when the output typically instantly saturates.