...would frequently windup when the
car didn't respond fast enough.
Sounds like your loop gains are outta wack (technically speaking).
PID loops are bound by the frequency response of the system they are driving.
I would think the throttle response is violently faster than the GPS velocity information...making high frequency hunting a given.
Start with a small Kp and all other loop gains at zero. Work Kp up until you get a response that is slow and smooth...so you are following an offset of the curve of the set-point. Only when you have something "under-damped" can you start bringing gains up and closing the error.
If the GPS is really slow, some interpolation of the velocity data between updates will allow the loop rate to be increased. A rate limit loop around the output would also help.
A PID loop is a model of a system....the system you have....not the system you want :)
First, since steppers are great at positioning (there is no need for a position feedback), you should certainly limit their movement as you've said yourself. I am not sure how the motor shaft is engineered right now, but if it was fixed to the motor, letting it continue spinning would risk damaging the equipment.
Next, 200ms transport delay in your sensor will probably be too slow, otherwise you will need to slow things down a lot in order to slow down the ball itself. Similar to what Rocket Surgeon said, you should simplify the image processing algorithm to calculate the path only once, and then quickly calculate only the position of the ball in each frame. If you want to skip this step quickly, find a red ball instead of this one, and then check only the red component in your RGB picture, until you've found a better algorithm.
For the PID control, start with the fact that you actually need two separate PID controllers, one for the east-west motor, the other one for the north-south one. If you have two exact motors, their parameters must be equal.
For a PID controller to act, it needs to know the error: difference between the desired position, and the actual position of the ball. X and Y components of this offset will be the inputs for two PID controllers (one for each motor). To get the error, you need to have the desired position on your path first: a trajectory.
To get the trajectory, you need to process the image and get the path, as well as its starting and ending point. I am not sure if your algorithm is capable of distinguishing the path from the rest of the board right now, but if not, note that this is an algorithm of its own to handle before continuing. Again, you can skip this part by manually entering the junction points, if you are eager to see some results quickly. In any case, you should be able to define the setpoint speed, and have your software move the desired coordinate position over the path, from start towards the end. Obviously, you will start with a low desired speed.
So, before starting with control, you should go through the following checklist first:
- Simplify your image processing algorithm to get faster response
- Create an algorithm which creates a trajectory over your path using a predefined speed
- In each frame:
- Calculate the difference between the trajectory and the ball position
- Pass the delta-X component to the east-west PID, pass the delta-Y to the north-south PID
It may turn out that it is better to create the trajectory one segment at a time, and continue with the next segment when that ball ends the previous one. Otherwise, you will need to take care that the ball doesn't overshoot the desired trajectory (which may be hard to accomplish)
Best Answer
You said yourself that depending on what part of the charging process you are in, you keep the current constant or try to maintain that voltage. That's going to require some kind of controller, though not necessarily PID or some subset thereof.
The characteristics of a charging battery change very slowly relative to what even a slow microcontroller can measure and react to. Batteries also don't exhibit second order effects like inertia, like motor speed as a function of current does. Both these together allow very simple control schemes to work well.
Probably about the simplest control scheme for a switching power supply is pulse on demand. It is always stable and robust, although results in more ripple than a more finely tuned control scheme can accomplish.
When the output is below the regulation threshold, you do a pulse, else you don't. To avoid inductor saturation, you may always not do a pulse at the next slot immediately after a previos one, but that's a detail.
I've done pulse on demand switching power supplies with the PIC 10F204 a bunch of times. The code spins in a loop checking the comparator output as long as it is indicating the output is above the regulation threshold. When the output falls below the threshold, the code following the loop is executed, which produces a pulse. The instruction cycles to jump back to the top of the loop and do the next comparator check usually take enough time so that it's OK to do the next pulse righ away if the comparator indicates the output is still below the threshold.
Sometimes this can go meta-stable by producing two pulses in a row before the feedback catches up to the output having gone higher, but in all cases it remains stable as long as the maximum load isn't exceeded.
This sort of system is fine for battery charging, except that you have two thresholds, one for voltage and one for current. You only do a pulse if the output is below both. The higher level logic can adjust the limits as the battery progresses thru the charging procedure.