So I’ve been playing with my flywheel test setup and some closed loop velocity control. I have some preliminary results that I will share in this post and hopefully update the thread as I refine the control code.
I created this with the following constraints for my design.
Capable of using 1 through 4 motors.
Motors do not share an axle, I really don’t like designs that have a motor at each end of an axle the needs to be cut to a precise length to work and is hard to assemble.
Motors set to 160 rpm speed gearing, first stage external gearing at 5:1. This gives me a shaft that has a theoretical free speed of 800 rpm that becomes the input to further stages of gearing able to spin my flywheel
When I run this and measure the free speed of the output from the first stage gears, it’s essentially the free speed of the motors, slightly over 800 rpm.
For the velocity tests my flywheel is connected using chain and two sprockets, a 30 tooth on the drive shaft and 12 tooth on the flywheel. The final design may use a 6 tooth but I wanted to keep speed down for this round. I like to use chain as it allows flexibility on where to place the flywheel.
My original plan was to compare PID and TBH, the newly discovered (for vex forum at least) “take back half” algorithm. I’m writing the control code using the ConVEX library, this gives me a bit more control when streaming real time data, I will port back to ROBOTC later. Anyway, as many of you have found, tuning PID is hard and after playing with the PID constants for a while and not meeting my requirements I pretty much decided to stop pursuing it. The TBH controller was really easy to setup, it’s really just a P controller with what I would call a “fiddle factor”, that is, it uses some of the knowledge we have about the ballistics of the flywheel system to simplify getting to our end goal, that is, the flywheel running at a constant velocity.
To analyze the system I stream several of the variables in the control code to the real time graphing program I created last year. The following graph shows the most simple version of the TBH algorithm, the intermediate “tbh” variable is not initialized and starts at 0.
I’m showing five variables on this graph, from the bottom;
actual velocity - this is my attempt to measure velocity at the motor using an IME
set velocity - the required velocity at the motor to achieve the flywheel speed I want
current - this is the estimated current for a single motor calculated using the algorithm from my smart motor library.
TBH - this is the “take back half” (for want of a better name) variable that is used each time the error between set and actual velocity changes sign.
Motor drive - this is the control command sent to the motor.
Unfortunately as all of these variables have a very different range of values there is no easy way of showing the Y scale on the graph.
The TBH algorithm has only one variable that needs to be chosen, this is the gain of the P controller section of the code. A small value of gain will cause the motor to accelerate slowly, a large value will cause fast acceleration. I chose a value to keep the motor current reasonable during startup, the maximum measured current was about 1.8A with an average current of about 1A for the first second of operation. This is well within the capabilities of the motor PTC so no PTC problems during flywheel spin up.
As the TBH variable is initially set to 0, you can see how motor control speed is dropped to half when the error in velocity first becomes zero. The flywheel reaches the desired velocity and equilibrium after about 6 seconds.
The first improvement to make is a better estimate of the initial value of the TBH variable. We know approximately what the required drive for the motor is from the results of this first test and can use this information. Let say that we know the motor will receive a control value of 90 to achieve the desired flywheel speed. At the first zero crossing the motor drive is calculated as follows.
motor drive = 0.5 * (motor drive + tbh)
we know we want the result of this calculation to be 90, lets assume just before this calculation we have been sending the maximum value of 127 to the motor
90 = 0.5 * (127 + tbh)
so tbh would need to be 53.
This graph shows the result of using a predicted motor drive at the first zero crossing and pre calculated value of tbh (which is calculated just before it is used and does not show in the graph).
The time for stable operation is reduced from 6 seconds to about 1.5 so quite an improvement.
(hit the image limit so continued in the next post)