Increased firing rate

I was reading through a different velocity control thread.
Someone said that velocity control increases your flywheel recovery rate even more than just having it at the maximum value.
Can someone explain how this works?

For example, my flywheel (which you saw in competition yesterday) coasts at about 60 power for full court shots. When a ball gets fired, the PID control on my flywheel speeds up the motors to about 90 power, before dropping back down to 60 after a few seconds if no more balls are fired in that time. When the flywheel is at a constant 90 power without the PID engaged, the flywheel overshoots the court by about 6 feet(or the equivalent of almost 2 balls per second but isn’t consistent at shooting). What the PID (or any other velocity controller) does is temporarily increase the speed of the flywheel to increase the recovery time before dropping back down.

If you put the motors at a constant power, which you currently have on your robot, the recovery for shooting is dictated by how fast the motors can regain their speed without any boost. If you pay attention to motor recovery times on a flywheel because of the load, the speed up of the flywheel is not linear. When the flywheel is first starting to turn, it increases in speed really quickly, but then levels off, and takes about 2-3 seconds to get from almost the target velocity to the target velocity.

On a velocity control however, the startup speed of the motors relates to a higher potential velocity if unchanged. But after the actual target is reached, the power drops of to the intended speed that you want the motors to turn. What this does is eliminates that 2-3 second time that the motors are turning about 9/10th of the speed you want them to before finally increasing up to the intended speed. This is because the motors are trying to get to a higher speed so the exponential increase of speed is lengthened to surpass the target you are trying to reach.

Hope this helps!

Thank you.
That does help.

Having PID versus full 127 does not increase revocery rate.
If PID is tuned so that it goes fullpower the moment a ball is launched, it’s still 127, which is the same as full out 127.

PID is only an advantage if the robot shoots at a motor power below 127, and then velcocity control minimizes recovery time by breifly powering back up to 127 and then a lower motor power to maintain launcher rpm.

@Stanley Shi(2R) is correct that PID will not help you increase fire rate.

However, if instead of counting launched balls, we start counting scored balls then software PID (or its mechanical equivalent) will be very important.

With motors running at 100% power (more than you need for full-court shots) and balls fed at unpredictable rate you will not have good accuracy. You will need to control either flywheel power or ball feeding rate (or both), whichever is simpler to do in your specific case.

Ok, thats what I thought.

Has anyone tried a program that goes 127 for the perfect amount of time then stops and hold the speed with the perfect amount of power? I would think that it would give the perfect fire rate but what do you guys think?

You are asking some challenging questions, which is very good. :slight_smile:

As have been mentioning above the “perfect time” is to turn power to 127 and leave it there while controlling the flow of the balls to match inflow and outflow of the energy in the system. But you are not asking about that.

So yes, for the last couple of months we have been doing (trying) that and, I believe, many other teams have been doing similar research as well. The catch is in the word “perfect”, because VEX sensors and hardware are not perfect.

Anyone who read these threads (motors take time to update, ports 1 and 10 are fast, modelling motors accurately is tough, PID could get complex, PID tuning is tricky) understands that it is not trivial to get PID right.

The main reason are the delays between commanding a new motor power and your algorithm reliably sensing resulting velocity change. Take a look at this graph from the moving average thread:

Without doing anything special you are either getting very noisy measurements, which prevents you to make a perfect decision, or are getting measurements delayed by tens of milliseconds. This is also making your life hard because, unless you have a very heavy flywheel, the acceleration rate will be steep and you could easily overshoot if you miss your timing by just a little bit.

Second difficulty is that exponential shape of the flywheel velocity curve has varying gradients and picking a single set of PID coefficients that works everywhere may be next to impossible if you want your flywheel be both aggressive and accurate.

There are several ways to resolve those conflicts.

First one is to find some balance point where you sacrifice some aggressiveness in re-accelerating flywheel. This will let you reduce measurement noise to the point that you get less overshoot and enough consistency in scoring the balls. If you change your metric from number of launched balls to the number of scored balls per second it will be very easy to find such point.

Also, flywheel’s moment of inertia should be large enough to limit the steepness of the acceleration curve but small enough such that ball launch event is easily distinguishable from the the noise on the acceleration curve (see blue series on the graph above). Once you have detected ball launch event you may switch to a different set of PID coefficients.

The code here is an example of finding such balance point if you want to keep your math on the level that could be easily understood and implemented by a smart seven-grader. I am sure it is still far from perfect and could be fine tuned in the coming weeks. Now it is doing a ball in 0.8-0.9 sec with two turbo motors driving a single flywheel.

For example, the noise seems to be on the order of +/- 5 RPM, but the algorithm switches from the aggressive acceleration mode when the first high outlier touches targetRPM-5 boundary. I am sure we could tighten some tolerances and get to 0.75 sec per ball without sacrificing too much accuracy.

However, if anyone has a nerve to hold the pedal to the metal until the last millisecond, there is a way to estimate velocity and acceleration much more accurately and with much smaller delay using (Kalman) Filter. Of course to do that you must not be afraid to do some advanced math like predicting flywheel velocity.

If anyone is interested, just let me know, and I will gladly spill all the details. :slight_smile:

That might only work if you had a rock solid battery voltage for the entire match. Remember 127 is just sending “max power” to the motor and has no relation to how fast the motor is actually going. If that doesn’t make sense, set up a timing track and do a run with a fully charged at “full speed ahead” (which should be sending 127 to your drive motors). Then do it again with a battery that isn’t fully charged. You will be still sending 127 to the motors, but you will see the bot is significantly faster with a fresh battery. So, a power setting of 127 will not give a constant motor as the battery voltage will change over the course of a match. The voltage on a good battery shouldn’t change much over 2 minutes, but we have seen very small changes in motor velocity have big impact on full court shots because there is very little room for error. Close up shots are not so sensitive to velocity changes.

@pietrofesar I think a good place to start is here:

I started the aforementioned thread because I wanted a more in-depth understanding of velocity control. A lot great information is there as well as a lot of code. Hope that helps!