I have a flywheel with a somewhat simple PID loop and I’m wondering if I could get some advice in tuning it. I’m able to graph data from it, and it gets to the correct speed over time more easily, but on short notices, like during firing, it won’t get to the correct speed. I’ve attached the graphs of the first few tests and the final two which i got to get. The accuracy of my flywheel is still only 50% or less even with this code. The PID loop works like this:
Tgain = .033;
Igain = .025;
Error = setRPM - actual(Quad encoder RPM);//calculate error
Tunedpower = Tgain * setRPM;// power to get in the general range of the RPM
Ipower += Igain* error;// Integrator to change speeds over time.
motor_power = Tpower + Ipower;
if (abs(motor_power - Tunedpower) >15)//if not within the safe range to set speed quickly, slew to that range.
slewmotors(motor_power);//slew rate on spin up and spin down to keep from stalling
motor flywheel1] = speed;
I came up with this Idea for speed control after listening to how some flywheels run at a competition, and it seems to be working, but I can’t get it tuned right. Should I just have an P(not cumulative adding) instead of I gain(cumulative error over time) with the adjustment power? Any Advice?
Also, should I be using the Integrated Encoder RPM or the Quadrature Encoder RPM? The Integrated is at the bottom of a 1:35 single flywheel, while the quad encoder is geared down directly from the flywheel 4:1. The Quad encoder seems to read higher than the integrated, but the integrated is more erratic. They are both averaged with 2 previous values every 50msec.
All the graphs with these phenomena are included in the data, which are firing tests of 24-32 balls automatically whenever error is between -10 or +85 of the set value.
With The code form competition (manual pulsing to regain speed) about 1 ball every 1.5-3 seconds. With this, it fires about 1 ball every .8 seconds, but is extremely inaccurate (55% in the goal).
P.S. This code I included in the original post is grossly oversimplified of what actually goes on in the loop.
Always just under (like hitting the bar and bouncing out). The code seems to compensate better when we load in rapid succession, but it’s just because it is constantly increasing power then decreasing while the ball is in the air.
That is opposite of what we see… using the TBH controller as we increase load speed we start consistently overshooting. I am hoping with the new velocity calculations that have been posted by James Pearman we will be able to get our shot speeds up with either TBH or PID control due to more accurate velocity readings. What motor power range are you in for your full court shots? We need about 70 power to achieve our target velocity for full court. Maybe altering gearing or lowering compression would allow the use of a higher power setting would improve our results… I am interested to hear your power requirements.
On a Full main battery (8.4V) we get full court at around 70, and on dead batteries about 80 (we mostly run half-dead batteries because we don’t change them out often). We with new batteries overshoot with current code. You wouldn’t believe the number of teams mad at us because we complained of over voltage (we only used 4 batteries for a whole competition).
We are a new team and are going to try to tune our fly wheel this week. My question is how do you graph the numbers to check for error? Do you just copy them into excel? I am really confused on how to do this if some one could explain it I would really appreciate it.
So then when I run the code, it would then output something like this into the RobotC debug stream (the first number on each line is the time in milliseconds, second number is speed in encoder ticks per cycle):
I then paste that into a .txt file. Then in Excel, I go to the “Data” tab, click “From text”, then import that .txt file with commas and delimiters. This makes two columns, one with the time and the other with the speed. Then I create a chart in Excel using the data.
But for tuning, you don’t actually need to graph the output every time you run the PID loop, you can just use the raw debug stream output to determine the recovery time. Graphing it definitely helps though.