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)
I wouldn't go so far as to call PID outdated. But there certainly is room for improvement. One way in which I have auto-tuned PID control loops is to use the Nelder-Mead method which is a form of hill climbing simplex algorithm. It has the benefit of being able to converge and reconverge on a target parameter that moves over time.
From this paper:
For example in our case of PID parameters tuning {KP,
KI, KD} a simplex is tetrahedron. Nelder–Mead
generates a new test position of simplex by extrapolating the behavior
of the objective function measured at each test point arranged as the
simplex. The algorithm then chooses to replace one of these test
points with the new test point and so the technique progresses.
My particular application was for motor control. We had two loops, a PID current control loop and a PI velocity control loop. We set our vertices to P, I, and D respectively and ran statistics on the output of the loop. We then ran the reflection, expansion, contraction, and reduction over and over again until the current or velocity control targets generated were within a few standard deviations.
With our product, the VP was very concerned with how the motor "sounded". And as it turned out, it "sounded" better when the current target bounced a bit more than was mathematically optimal. So, our tuning was done "live" in that we let the algorithm seek while the motor was running so that user's perception of the motor sound was also taken into account. After we found parameters that we liked, they were hard-coded and not changed.
This probably would not be ideal for you since you state, "putting the system in oscillation even as a part of auto-tuning is not acceptable to the users". Our system would most certainly oscillate and do other horrible things while it was auto-tuning.
However, you could run two copies of the PID controller. One that was "live" and actually controlling the process. And a second that was constantly being auto-tuned while being fed the same inputs as the "live" controller. When the output of the auto-tuned controller became "better" or more stable, you could swap the coefficients into the "live" controller. The controller would then perform corrections to the process until the desired performance was achieved. This would prevent oscillations that can be perceived by the user during auto-tuning. But if the inputs change drastically and the PID controller is no longer optimal, the auto-tuning can swap in new coefficients as they become available.
Best Answer
The right answer would be very comprehensive, so I will try to answer the basics.
You are right about using counters to determine position setpoint.
Yes, because digital data is being sent cyclicaly at detrministic time, while Step/Dir would require a FPGA/ASIC to calculate speed setpoint from frequency/period measurment of pulses, making the setpoint information non-deterministic which indeed is not a good thing for forwarding to the PID loop. There is a first order lag filter to bring the velocity setpoint more smooth.
Further, digital data can have both velocity and position setpoint, no need to derivate from pulses frequency.
This is incorrect. The setpoint has to have the implementation of motion profile, where acc/decc speed has taken into account. Things are not to be driven with a burst of pulses, rather a controled way of sending pulses with specific motion profile.
There are different drives/approaches:
1. Single axis, non synchronized: You can have a motion profile generator built in the drive, then you just send position setpoint, the drive does the rest with parameters jerk, acc, dec, speed.
2. Mutiaxis, sychronized move: The drive works like a velocity controller, the motion planning and position regulation loop is calculated in a host system. The digital data are: speed,...
EDIT:
Single Axis (built-in motion profile generator). Usually you send over serial comm. Target position and control bits:
- Servo on, Enable: applies power to the motor and disengages the brake (if equiped)
- /Stop: the drive coast to standstill with determined ramp, used for stopping the machine in a frindly way
- /StopE: the drive coasts to standstill with very high deceleration, to be used for emergency stop
- PosEnable - set this bit to enable positioning move, drive moves to target position
Then you have some status bits, for your app, maybe a bit that indicates position done is important. When drive reaches the target position it sets this bit, but due to the communication lag you never exactly know if this bit refers to the actual or to the previous movement. You should do some tricks to evaluate this bit according to actual position and target position and make a your own piece of code that will look this bit when the drive is in the tolerance window. Or another good way is to loopback the target position from the drive to the host, this is possible if you can set up a user defined communication telegram.
Drives I was working with (Siemens, Lenze, SEW, Indramat) allow the change of target position while positioning is active, new profile is calculated from actual position, speed,...I think this is a basic function of all drives with built-in profile generator.