LinuxCNC S-Curve Accelerations

More
14 Jun 2021 12:16 #212023 by arvidb
Hehe, maybe I'm a bit of a perfectionist? ;) (Yes I am...)

But even if you did modify only the acc-cmd, how would you use it to control your machine? If I'm not mistaken, pretty much all configs use the motor-pos-cmd as the setpoint for the PID controller (that then outputs a velocity command to +/-10 V outputs, or to stepgens). So you really do need to have the pos-cmd itself change in a way that doesn't lead to infinite jerk.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 12:42 - 14 Jun 2021 12:54 #212025 by Grotius
Hi,

The problem of c coding or mathematical knowledge is solved.
Attached a component that uses a scurve header only library.
#include "scurve.h" to your component or c code or c++ code.

I think with this example users can retrieve all the info related to the scurve's acc, dcc, timestamp points, etc.
For interpolating on arc's just give the arclenght to the function. And then interpolate the result to the arc bow.
This can be done by % pathlenght interpolation.

The output is printed with rtapi into the terminal. This is done by setting the debug to 1.

The function call from the component, wich is a line (path) of 100mm :
scurve(5,  // velmax
               1,   // accmax
               0,   // vo
               0,   // ve
               0,   // xs 
               0,   // ys
               0,   // zs
               100, // xe
               0,   // ye
               0,   // ze
               1, // time output resolution in sec, for example 0.001 is a point every ms
               1);  // debug 0 or 1

Rtapi result :


Now you can imagine what to do. Just play around with the code.
It has jerk, initial velocity and end velocity implemented. It has also a sampler if max velocity can not be reached.

Attached code is a "c kernel style" derivate from my original work at : github.com/grotius-cnc/S-curve-motion-pl...g/releases/tag/1.0.1

test.c
Warning: Spoiler!


scurve.h
Warning: Spoiler!
Attachments:
Last edit: 14 Jun 2021 12:54 by Grotius.
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 13:51 #212027 by arvidb

            V = Jm*(t*t)/2;
            V+=tr.Vo;                               // Add initial velocity.
            A = Jm*t;
            Sa = 0*t + Jm*(t*t*t)/6;

You are ignoring initial velocity here, in the calculation for distance (Sa).

Sa = Jm*(t*t*t)/6 + tr.Vo*t.

This is probably the same bug that I reported here (and that you never replied to)? From the plots in that post you seem to have a similar problem with end velocity.
The following user(s) said Thank You: Grotius

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 15:33 - 14 Jun 2021 15:41 #212031 by Grotius
Hi Arvidb,

Thank you for your reply.
I think you have to look at "V+=Traject.initialVelocity"
The plotted graph's at github show everything is printed ok when using vo and ve parameters.
If they where not ok. I would have seen that.

I spotted and repaired a rtapi print output with empty value's when T1, T2, T3 are 0.
Now it print's only when T1>0 , T2>0, T3>0.

Initial velocity and end velocity are just working. It was printing a empty value at line 0 of the rtapi print output.
So it was looking like a bug.

Here a function input as :
scurve(5,  // velmax
               2,   // accmax
               5,   // vo
               2,   // ve
               0,   // xs
               0,   // ys
               0,   // zs
               100, // xe
               0,   // ye
               0,   // ze
               1, // time output resolution in sec, for example 0.001 is a point every ms
               1);  // debug 0 or 1


Mention the output resolution is quite low at a 1 sec interval.
Attachments:
Last edit: 14 Jun 2021 15:41 by Grotius.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 16:08 - 14 Jun 2021 16:10 #212034 by arvidb

The plotted graph's at github show everything is printed ok when using vo and ve parameters.

I can't see any problem with the velocity plots at your github, however the position plots are not consistent with the velocity plots. All your position plots start and end horizontally (slope = 0), which they shouldn't if there is initial (or end) velocity, since velocity is equivalent to slope of the position curve.

Also plots 2, 3, and 4 all have discontinuities in the slope of the position plots ("kinks"), which means there is a step change in velocity, corresponding to infinite acceleration at those points. The position plot should be completely smooth even with acceleration-limited motion.

I have run into similar issues while developing my code, and in my testing I now double-check for such issues by differentiating the position output in several stages to get approximate velocity, acceleration and jerk values derived directly from the successive position outputs. I then check that these derived values doesn't deviate too much from the calculated ones at each time step. This automated test has been very useful to find bugs, and I can really recommend it!
Last edit: 14 Jun 2021 16:10 by arvidb.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 17:23 #212039 by Grotius
Hi Arvidb,

Also plots 2, 3, and 4 all have discontinuities in the slope of the position plots ("kinks"),

This are no position plots ! ( Grey lines ).
It are scurve rendement curves.
A horizontal grey curve is no progress or travel, no rendement in travel.
With a max slope (steep curve) the rendement of the scurve implementation is at is best.
A kink in the plot show's a transition to a different scurve rendement. This is nothing special or to worry about.
The grey line is scaled at y axis : scale=0.15 to fit the plot.

curveup (// Be aware graphicsview is inverted on y-axis.)

concave period : ellipse = scene->addEllipse(T, scale*(Sa*-1), 0.1, 0.1, GreyPen);
convex period : ellipse = scene->addEllipse(T, scale*((Sa+Sb)*-1), 0.1, 0.1, GreyPen);
curvesteady
ellipse = scene->addEllipse(T, scale*(S*-1), 0.1, 0.1, GreyPen);
curvedown
convec period : ellipse = scene->addEllipse(T, scale*(Sb*-1), 0.1, 0.1, GreyPen);
concave period: ellipse = scene->addEllipse(T, scale*((Sb+Sa)*-1), 0.1, 0.1, GreyPen);

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 17:54 #212041 by arvidb
Rendement? I don't know what that means. (Is it french? "Yield" or "Output"? I still don't know what that means in this context.)

You write on your github page: "Grey = Travelled in time". And you write in an earlier post in this thread that "Grey is S (distance) versus T (time)." I would call this (relative) position?

If you have a "kink" in "distance travelled versus time", that means you have a discontinuity in velocity and thus infinite acceleration at that point. And "distance travelled versus time" should always have a slope equal (or proportional, with scaling) to the velocity, or something is wrong with the calculation of either velocity or (relative) position.

If I'm misunderstanding what the grey curve is, can you add a plot of (relative & scaled) position to your graphs? That is the most important output from a motion planner after all.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 19:39 - 14 Jun 2021 19:50 #212052 by Grotius
Hi Arvidb,

Rendement is like "the effectiveness".

I made a short video about the scurve graph.
user-images.githubusercontent.com/448801...7d6-c7dcf68d7db7.mp4

The grey line is now showing time versus displacement for point in x direction, to simplify it.
Point x is from x0 to ~x100mm in the video.

(ellipse = scene->addEllipse(T, p.x*-1*scale, 0.1, 0.1, GreyPen);
scale=0.15;

This is how it should look like :


In a normal situation we see a displacement as in above graph.
When doing exotic's we can end up with so called "kink" in the displacement curve.

Arvidb, In your point of view this "kink" is a bad thing? I don't have something like it's a bad thing.
Attachments:
Last edit: 14 Jun 2021 19:50 by Grotius.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 21:30 - 14 Jun 2021 21:47 #212059 by arvidb
Yes, Grotius, in my view the kink is a bad thing. To the left of the kink you are moving at one velocity, to the right of the kink you are moving at another velocity == step change in velocity == infinite acceleration == possible damage to CNC machine (and a very surprised operator) == bad thing. ;)

Velocity is change in displacement over time, right? That is, v = Δs/Δt = the derivate of displacement.

You can approximate the true velocity of something moving along your grey displacement curve by differentiation:
true_vel = (S - S_prev)/timeresolution;
S_prev = S;

Add a plot of true_vel to your graphs and you'll see what I mean.
Last edit: 14 Jun 2021 21:47 by arvidb.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 22:09 - 14 Jun 2021 22:33 #212061 by Grotius
Hi Arvidb,

Do you have an idea how the lecture dealing with this "kink" in the curve, you would expect researchers have dealed with this
before?

It's quite hard to imagine when the velocity curve looks ok and the acceleration curve looks ok.
There could be a kink in the displacement curve in some "exotic" cases.
[edit] After some experimenting it occur's when intitial and or end velocity is not zero.

And that this "kink" is in fact a infinite acceleration stage. When using a 20Kw servo it could result in a machine shock. :pinch:

Is it a idea to avoid this "kink" with a algoritme?

Are you able to implement your example in the qt code?
Last edit: 14 Jun 2021 22:33 by Grotius.

Please Log in or Create an account to join the conversation.

Time to create page: 0.273 seconds
Powered by Kunena Forum