integral and derivative control based on distance rather than time

[RSW 0]

I'm working on a steering control system for a piece of heavy equipment, and would like to use a PIDE enhanced PID controller function block in RSlogix 5000. The equipment can move at varying speed, and the dynamics of the system are a function of distance travelled rather than time elapsed. So, for the integral part of the control I want:

k_i ∫e dx      rather than     k_i ∫e dt

Similarly, for the derivative part, I want:

k_d de/dx      rather than       k_d de/dt.

where x is the distance travelled.

The reason for this is that the optimum gain settings will be the same regardless of speed at which the equipment travels.

I can place the PIDE inside a task that is triggered on the basis of distance travelled, but after reading the manual, it's not clear to me whether that will do what I want because it appears to me that regardless of which timing mode I choose (periodic, oversampled, or real time) the function block is always going to calculate the true time between executions and then correct back to a time based control. Is there any setting that will ignore the true elapsed time, and just assume a fixed value?

 

[Michael Lloyd 85]

I don't get to do as much control loop design as I used to but perhaps you should consider adjusting the Gain, Integral, and Derivative (I'd be surprised if you even needed derivative) as a function of distance travelled. Since speed varies maybe consider using a Rate of Change routine to tweak the tuning parameters. I wouldn't "continuously" tweak them. Use a Periodic task (or timer) to adjust the parameters. Maybe use the rate of change result to adjust the timing for how often they are adjusted.

I made the attached Rate of Change AOI a few years ago. It's in service and it works. It runs in a periodic task and the routine uses that setting so you don't have to hard code a time. I added a MAVE to the routine to smooth it out. It should be unlocked, if not let me know and I'll send one that isn't locked

I think you are trying to change the function of the PID loop when you should be looking at ways to adjust the tuning parameters with the info that you have

Rc.L5X

Edited 19 Nov 2016 by Michael Lloyd

[RSW 0]

Hi Michael,

Thanks for your comments and the AOI. I'll check it out.

Adjusting the gain settings based on speed is my alternative plan. However, since nothing in the steering process directly depends on time, I would rather leave time out of the control if at all possible. There is no need for integral control, and if derivative control could be eliminated then there would be no problem, because neither time nor distance travelled would enter into the controls. However, the steering process is inherently integrating. The existing controller is proportional only and is unstable, operating in a limit cycle. I believe that there will have to be significant derivative control in addition to proportional. It's definitely a different kind of project than what I'm used to.

[Michael Lloyd 85]

Well... integral control is derived from integrating the ERROR in the system. That's why it's time based. I realize I just wrote something that you know but I think it is important for future readers. The error in a steering control mechanism, to me anyway, is a function of time. I could just be "stuck" but this looks like a time / speed / distance problem with the integration of the error as the centerpiece. I can't help but wonder if it is an IF/THEN/ELSE problem too but doubt if it is that simple.

I honestly have no experience with this kind of problem and I am jealous of your opportunity. But... I might just as well be in the loony bin by the time the project was over if it were mine :)

Perhaps a search for an Arduino program for controlling a radio controlled aircraft / car/ truck / helicopter would help?
 

Edited 20 Nov 2016 by Michael Lloyd

[RSW 0]

Using a regular automobile as an example, if you adjust the steering so that the front wheels point away from the center of the road, then error will accumulate, but only if the vehicle is moving. If it is sitting stationary, then no error accumulates regardless of how much time elapses. If the vehicle is moving, then the rate at which the error accumulates is proportional to the vehicle's speed, but the total accumulated error is really a function only of the distance travelled. After the vehicle has moved 20 feet there is 'E' amount of error accumulated; it makes no difference how long it took for the vehicle to move that distance, which is why I'm arguing that time does not directly enter into it. Of course there's a direct relationship between time, distance and speed, but the fundamental variable in this case is really distance travelled rather than time, unlike most control problems. I suppose that if I have no other choice than to use a time based PID then it's straightforward to linearly adjust all of the gains according to speed. If the speed goes to zero, then so do the gains.

As for searching for Arduino based steering algorithms, that is one of the first things I did when I began this project. There are all kinds of projects for line following robots, and I've reviewed as many as I could find. All of the ones I've found are extremely simple and are essentially the same as our existing control. I'm convinced that they are all oscillatory, but probably correct themselves quickly enough that it isn't noticeable for that application. We have actually considered building a small line following robot to test our control algorithm. It would be a lot safer than testing with heavy equipment, and a lot more fun too.

[Michael Lloyd 85]

I'm just "thinking out loud" vs arguing...

I assumed that there would be some kind of GPS, accelerometer, and speed sensor feedback mechanism. If you know speed you have the basis for adaptive gain and adaptive reset.  I've used the FGEN function block for Air/Fuel ratio and surge margin for high speed rotating equipment (expanders and turbines). It seems like a good fit for adaptive gain and integral based on speed but that would require a speed input. If you haven't used the FGEN block it's worth looking at. It's basically Y=mX+b in a block. The number of data points is set by the size of the tags. I always have a hard time finding it. A function block routine has to be open and it's under Process.

If speed goes to zero then Gain and Integral would go to initial values (assuming the FGEN block was calculating the value) rather than 0 otherwise there might be too much lag when the truck begins to move again. Error is only accumulated if it's moving. I see this as a control response problem (speed related, which in my mind is just a form of time problem) and a position correction problem, which had a time element to it (how fast can I change the direction of a large mass without causing damage to something). Two different but related problems. 

I didn't find any code but I did find references to PID algorithms for drones that are controlled by an AVR and a multitude of sensors. Unfortunately the designers aren't giving away their code (I can understand that). These guys say they are open source but I didn't look for code: https://wiki.bitcraze.io/ Their little quad copter is fun to fly (or crash) around the house.

It's an interesting problem with a lot of facets. Good stuff...