Using Struckig to do path tracking

[LotfiZ]

Hi all,

First, @stefanbesler you did such a great work here !

Regarding the title of this topic, i was wondering if it was possible to use this library to perform some signal tracking in real time. I'll give a quick example :
We have an AGV that follows a magnetic line by computing the offset between a magnetic sensor and a magnetic wire on the floor. Our PLC is using Codesys, i installed the library and it seems to work well so far ! Actually, the tracking of the line is performed by a simple PID that tries to compensate the offset depending on velocity from the encoders readings but this approach could be limiting in terms of jerk and acceleration. I was wondering if it was possible to compensate the offset with the struckig ? so the TargetState will be the offset and instead of using the newOutputState as InputcurrentState, we use the actual reading from the encoders as InputcurrentState at each cycle and doing the propagation "manually" but disabling the EnableAutoPropagate parameter. I know that Ruckig is more suitable for stationary applications but im wondering if it can be used in mobile applications.

I'm still playing around the library on Codesys so if i find something interesting, i'll share it with great pleasure. Thank you !

[stefanbesler]

The lib is meant for dynamic applications as well, Struckig can definitely support you in tracking, but I think to get good results you will have to implement a tracking algorithm to “feed” predicted target states into the trajectory generator instead of actual readings.

If you use the actual readings of the encoder, the trajectory will take time to catch up and lag behind a bit. Tracking algorithm overcome this hurdle. This is achieved by predicting ahead a target state, which can then be passed to Struckig.Otg . I did something similar once in an image processing application with opencv and used the optical flow algorithm for tracking a signal. There I could simply use an opencv implementation, but I don’t think it is so hard to implement this in Codesys.

Struckig is a port of the open source version of “ruckig”, which actually implements such an algorithm in its Pro version.

[LotfiZ]

Thank you for the quick reply Stefan but i'm afraid that i did not catch the subtlety here even with the explanation of the original library about the tracking interface.
I did a little simulation in Codesys to try to track a SINUS signal and i found that its tracking is very good without the famous prediction, so i think that im doing something wrong. I dont really understand why we need to predict the target whereas we obtain it with the reading of the sensor and we try to reach it with the trajectory generator at each cycle time. Here the example to illustrate my words :

Codesys Code that pass a sinus signal to targetposition for struckig :

T := SIN(0.4*step);
otgtest.TargetPosition[0] := T;
otgtest();
otgtest.CurrentVelocity[0] := otgtest.NewVelocity[0];
otgtest.CurrentPosition[0] := otgtest.NewPosition[0];
otgtest.CurrentAcceleration[0] := otgtest.NewAcceleration[0];

step := step + 0.01;

Plot the TargetPosition(green) within the NewPosition(blue) :

we see here that the NewPosition reach the TargetPosition during time. Obvisouly that we assume here that the NewPosition is the Current one, which in reality its not really the case...

[stefanbesler]

Looks nice, it is not that you have to do it, but the result might be better if you do

[stefanbesler]

I think that the reason why you don't see any lag is because you are updating the trajectory every single cycle and you trajectory is smooth enough that it can be followed with the given jerk limit.
When tracking, as far as I know, you usually update every few 100ms, but I never actually implemented an application that needs tracking besides the image processing stuff I talked about above

[LotfiZ]

Hi, i was playing around the lib and i dig more about the tracking algorithm (constant velocity motion model and constant acceleration motion model), i think that Ruckig use the second one The tracking interface solves this problem by predicting ahead (e.g. with constant acceleration by default) but i still dont get the nuance behind using a prediction for tracking purpose in ruckig. However i did a simple test that i'll state here :

1- I have a sensor that read an offset in position of an moving object (in 1D).
2- My goal is to compensate this offset (TargetPose = zero ) over the time.
3- At init, the sensor read for example (5 m) so the object has to reach zero after a while.
4- i launched OTG and let it do the job (generation of new pose, new vel, new acc...etc), there is the result :

Position computed by the lib (in blue), Target position (in green), Velocity computed by the lib (in red).

My question here is that in this case the lib uses the new position as current position and so on, but its an estimation, how about using the reading of my sensor as current position at each time instead of using the estimation ! and then maybe using some weighting to have the best guess of the current position (balance between new position computed by the lib and the reading of the sensor).