LinuxCNC S-Curve Accelerations

Hi,

This is the front end interface in progress.

It sets up a scurve motion program, user can input the nr. of joints.
The ammount of joints is dynamicly loaded at startup.
User can set parameters for each joint by id.

Then to update the values, user can select a Joint id "j1, j2 etc.".
It's now limited up to 16 joints.

How would you program a linear move involving more than one joint?

Hi,

Good question.

The code below is tested today. The logged peak is ms : 0.283687 ms in userland.
The input is more or less the same as the ruckig motion planner.

1. Set the nr. of joints.
2. Set the "a" acceleration and "dv" delta velocity.
The delta velocity value gives the "jm" value.
More precicely, Dv is from 0 acc to as and back to 0 acc. Where "as" is 2*a, this is at the scurve inflection point.
Sorry for the confustion.
3. Set the current joint values and target values.
4. Then in the servo cycle, the motion is updated every 1ms.
5. A new input will process a new motion.

motion->nr_of_joints(3);

motion->set(sc_motion_joint_id::id_J0,
            ui->doubleSpinBox_a->value(),
            ui->doubleSpinBox_dv->value());

motion->set(sc_motion_joint_id::id_J1,
            ui->doubleSpinBox_a->value(),
            ui->doubleSpinBox_dv->value());

motion->set(sc_motion_joint_id::id_J2,
            ui->doubleSpinBox_a->value(),
            ui->doubleSpinBox_dv->value());

in_J0.curacc=2
in_J0.curpos=0;
in_J0.curvel=22
in_J0.endacc=2
in_J0.endpos=1000
in_J0.endvel=5
in_J0.maxvel=50;

in_J1.curacc=0;
in_J1.curpos=0;
in_J1.curvel=2;
in_J1.endacc=0;
in_J1.endpos=150;
in_J1.endvel=0;
in_J1.maxvel=10;

in_J2.curacc=0;
in_J2.curpos=0;
in_J2.curvel=1;
in_J2.endacc=0;
in_J2.endpos=150;
in_J2.endvel=0;
in_J2.maxvel=12;
    
And in the servo cycle this is then updated every 1ms.

status=motion->update(0.001,sc_motion_joint_id::id_J0,in_J0,out_J0);
in_J0.curvel=out_J0.newvel;
in_J0.curpos=out_J0.newpos;
in_J0.curacc=out_J0.newacc;

status=motion->update(0.001,sc_motion_joint_id::id_J1,in_J1,out_J1);
in_J1.curvel=out_J1.newvel;
in_J1.curpos=out_J1.newpos;
in_J1.curacc=out_J1.newacc;

status=motion->update(0.001,sc_motion_joint_id::id_J2,in_J2,out_J2);
in_J2.curvel=out_J2.newvel;
in_J2.curpos=out_J2.newpos;
in_J2.curacc=out_J2.newacc;
 

So you are doing a move from (0/0/0) to (1000/150/150).

Maybe I'm missing something, but given that initial and terminal conditions for joints are wildly differing those joints will experience different accelerations for different amounts of time and resulting move will not be a straight line but something like a "curveball".

Hi,

That's correct. Nice spot.

In the example no xyz interpolation and or synchronisation is done.
I have not coded that part yet.

A little update.

For a 9 axis machine i now reach 0.4 ms when curve needs to be sampled. (cpu intensive part).
When the curve is a normal curve, the time is about 0.02 ms for a 9 axis machine.
I think this is acceptable.

I tested it with this : curve

The planning is now finish the lib. I think a few day's from now, hopely without any problems.


 

Hi,

A little update.
Made some progress today. The live mode is working. Perfomance is ok.
Vm interupts are working. You see in the picture multiple keyboard interrupts ca 8x.
After some testing, i found some things to improve. But concept is working now.

You can see in red the velocity curve. It has linear acceleration stage in the scurve profile. t2.
And curve acc-dcc steepness is constant.
This all makes the machine move's more predictible then using a cubic spline scurve.

It's almost time to test some waypoints.
This is interesting because of the acc & dcc end values, where a new move has to start.

Performance for one axis:
peak time only at start of curve : 0.014069 ms.
 avarage cycle time : ~0.002 ms

Link to scurve video

Link to source code

I am excitedly following this topic.
For the multiaxis synchronized move, if the line/arc/curve can be paramaterized on distance travelled along the curve and represent it as "s", the same theory used for single axis planner is valid.
At everytime step, we can compute the multiaxis positions using the direction cosines of the line or other parameterized formula from the curve for the individual axes.
The part to take care of would be during setting the max acceleration "a" and max velocity "vm". Here we would have to take into account the limits of each individual axis involved in the move and pro-rate the values of max acceleration and velocity (again using direction cosines for a line) .
-automata

automata wrote:

I am excitedly following this topic.
For the multiaxis synchronized move, if the line/arc/curve can be paramaterized on distance travelled along the curve and represent it as "s", the same theory used for single axis planner is valid.
At everytime step, we can compute the multiaxis positions using the direction cosines of the line or other parameterized formula from the curve for the individual axes.
The part to take care of would be during setting the max acceleration "a" and max velocity "vm". Here we would have to take into account the limits of each individual axis involved in the move and pro-rate the values of max acceleration and velocity (again using direction cosines for a line) .
-automata
 

jerk-limiting in "parameter-space" doesn't lead to jerk-limited joint movements, just consider tangential "blend" between straight line and circular arc, at the point the arc starts, centripetal acceleration appears as a step in acceleration perpendicular to the line pointing to center of arc. step in acceleration = infinite jerk. 

Isn't that where look ahead should come into play? You can calculate the centripetal velocity limit based on radius and machine accelaration so the look ahead might determine how far back along the line deceleration should commence to hit the target velocity when the tool arrives at the arc..

@rmu
That is exactly correct.
As I have alluded to earlier in this thread that this method can only take care of jerk which is tangential to the path. Jerk component normal to the path will still be unlimited.
forum.linuxcnc.org/38-general-linuxcnc-q...ons?start=240#216588

Do you have any ideas to deal with jerk limitation for both normal and tangential directions simultaneously?
Maybe as rowd suggested, using look ahead, we should be able to optimize the max jerk value allowd per axis.

In grotius' approach, the jerk is specified as a "dv" value which decides the change in velocity during which the jerk limitation is applied. It does not specify the jerk value directly. If you ask me, finite jerk (even if it not limited to a particular value) is way better than infinite jerk.

For paths that are continuously changing direction like circles or nurbs OR any machine with non-trivial kinematics, the only viable method to limit the jerk on joints would be to sample the path at some small length and check for velocity acceleration and jerk constraints at those points.
-automata