Hello, my club is currently working on a Velocity P.I.D. for our flywheel since we are only running a single motor. We were using PROS with okapi and were getting somewhere, but we stalled out and could not find ways to accomplish what we wanted. We have access to the new shaft encoders and tried using them to no avail. Does anyone have any pointers for what to do possibly? Sadly, I don’t have code to share at the moment because I am not the one working on it, but I may be able to get it in the future. (Yes, we are aware of the direct drive flywheels at 3600 rpm, and plan to possibly use one.)
Is there any more information on the issue? You said it stalled out; did you mean that the motor didn’t have enough power to spin the flywheel fast enough, or is the code not behaving as you expected?
If it is a mechanical issue, then a change of sensors isn’t going to help much for the problem. Overall, more details on what your are trying to accomplish would help with diagnosing and fixing problems.
By satlled out I meamt that we couldnt think of any more ideas. We did get it to where the code would make it so the motor would send more voltage to it if it detected a drop in rpms. We just need help making it into a P.I.D controller.
Just make a PID. PIDs are easy once you understand them. The point of a pid is to have no logic, only operations that turn sensor information into motor output values.
[Sensor] → [PID] → [Motor output]
In this case you want the RPM as your sensor. Feel free to use the RPMs of the motor.
The usual format of a pid is as follows, inside of a while loop, with variables declared and set earlier in the code:
err=target-sensor;
deriv=err-lasterr; lasterr=err
sum+=err;
PIDout=err*kp+deriv*kd+sum*ki;
motor.spin(forward, PIDout, volts);
wait (50, msec);
In this case your target is selected by another bit of logic or inputs and is your desired RPM.
Your sensor is your current motor RPMs.
You will need to tune your kp, kd, and ki using standard tuning algorithms:
- Plan out a reasonable target value that you can actually reach. If your motor cannot spin fast enough, do not attempt to reach it, as you never will.
- Plan out a reasonable kp such that you apply full power halfway to your target value, so kp=12 V / 1600 RPM = .006
- Double the kp until you get small oscillations around your desired value.
- introduce kd as a fraction of kp, and increase it till the oscillations go away.
- reduce kp, and introduce ki as kp/100. Increase until you get a good behavior.
Thats a rough and dirty method. Feel free to learn a good tuning method.
We will try that. thank you
One note: Make sure that you reset your sum to 0 every time you issue a new command, and also look up feed forward. It applies a bias constant voltage as long as your PID is active to make up for the fact that it will always have a frictional force acting in the same direction… attempting to slow it down. This way when you need to “lower” your speed, it doesn’t result in asymmetrical behavior. You don’t want different tunings for when you try to speed up to a desired value vs when you try to slow down to a desired value.
just add a term to your PIDout that is your Sensor value times some FF constant, kf
…+Target*kf
To tune this, Spin up your flywheel using the brain and look at the Voltage when its spinning at 50% speed. Your kf should be somewhere around the Voltage/RPMs for that steady state.
This is because we know it will run at … lets say 4 Volts when at full speed. Why make the pid stabilize on that value when we KNOW it spins at that value anyways. Also, we know that its going to require a different voltage at higher speeds because more drag.
GL;HF
There’s another side to this. Do you want the motor using battery power to slow down if you go over speed? You can heat up and even potentially over temp motors if you have an oscillation and you keep applying power in both directions. IIRC, turning point robots used ratchets to avoid this issue. If you’re directly coupled to a motor, you might be wasting tons of energy – this especially with a poorly tuned loop.
Also, everyone talks about PID. Are you using a PID controller or a PI? Understanding the issues your control system sees really matters in implementing in the real world. A flywheel is a big heavy thing. Are you spinning up so fast that you actually need a D term to correct? How is your integrator written. If it takes a while to spin up is your I actually saturated and then you have to go over speed long enough to clear out I? Solving engineering problems by using “good code” and not understanding the issues that code is meant to solve vs. the problems you actually have can lead to a lot of frustration. Responses here have asked “what are your actual problems” and that’s a great way to look at it. “Not working” isn’t enough detail for you to solve it or ask for help.
This is smart. I didn’t even think about how each term plays in this specific type of system. I went total man-with-a-hammer about it. I will add this into my recommendations in the future.
There’s also the classic https://xyproblem.info/ . You want to improve your flywheel’s performance. There are other solutions to motor control than just PID (especially for velocity control):
- PID with Feed Forward
- Bang Bang
- Take Back Half
Etc.
Really getting down to the core concept of “what am I trying to fix” is a good way to approach every engineering problem. As Mentor_355v says, there are other systems of control. I’ll pose a question to interested students in this thread. This requires a good working understanding of PID as a concept.
Let’s say you build a robot with an arm that has some weight, but your motors do a decent job moving it around. Your coder has a shiny new PID library, and tunes the loops as AperatureLabs suggests (a good way to do it). The arm is at the bottom of stroke, resting on the base. You want the arm to move up, to horizontal, so the code just sets the set point to move that far and stay there. You set the desired location and let the PID handle the motion. How will the arm move to get there? If you can explain this logically with the 3 terms, you have a good understanding of PID. There’s also a totally predictable weird behavior that every arm coded this way will have. Do you know what it is?
To tie this back to the OP, a flywheel is also kind of a strange thing. Friction only goes one way. Putting a pure PID that starts from 0 might cause some unhappy behavior. It is also possible that pure PID with good loop tuning will work great. Who knows?
I like the asking of questions, but is there is quite a range of outcomes from pid based on tuning the constants. Comedic oscillation and uncanny speed and stick on the target are both possible.
Let’s assume that the loop is tuned perfectly. Given pure PID control, there is still one behavior that is forced due to gravity.