Trajectory Planner using Ruckig Lib

For clarity - this is the test file in use.

 

I would have edited the original message but unfortunately the forum editor is so broken I was going to have to re-edit and fix the formating munging that was induced.  Ok - rant over for the time being until the next time it annoys me beyond belief.

Joco wrote:

smc.collins wrote:

You can use encoders for position feedback with Linuxcnc, there's a bunch of threads about it.
 
Yes I understand that. I have that on my mill.  However that is not the issue.  The problem is that for some reason the addition of the ruckig runner instances has somehow/somewhere generated a following error condition within in open stepper system.  So we need to unpick where/why/how that is happening.  As where things stand the code is great in the sim and dead in the water on physical kit, well specifically my phyiscal kit.  Unless someone has tested this latest code line on physical kit and has it working.  If so I REALLY want to see what their config setup is.


 

It seems the code is running one ruckig per axis. Those are independent, so different axis progress with different speeds, leading to more or less arbitrary path derivations. Large enough path derivation trips the following error. This approach simply can't work even in principle.

Hi Joco,

• MIN_FERROR = 0.010 - This is the value in machine units by which the joint is permitted to deviate from commanded position at very low speeds. If MIN_FERROR is smaller than FERROR, the two produce a ramp of error trip points. You could think of this as a graph where one dimension is speed and the other is permitted following error. As speed increases the amount of following error also increases toward the FERROR value.
• FERROR = 1.0 - FERROR is the maximum allowable following error, in machine units. If the difference between commanded and sensed position exceeds this amount, the controller disables servo calculations, sets all the outputs to 0.0, and disables the amplifiers. If MIN_FERROR is present in the .ini file, velocity-proportional following errors are used. Here, the maximum allowable following error is proportional to the speed, with FERROR applying to the rapid rate set by [TRAJ]MAX_VELOCITY, and proportionally smaller following errors for slower speeds. The maximum allowable following error will always be greater than MIN_FERROR. This prevents small following errors for stationary axes from inadvertently aborting motion. Small following errors will always be present due to vibration, etc.

Maybe try to add FERROR for each joint in the [JOINT] section of the ini file.
I can be, this solves the following error.

If this is not solving anything, please let me know.

Good luck.

@Rmu,
The planner Joco is tested, is the original planner written by Rob Ellenberg. Integrated are 3 ruckig runners.
The trajectory planner updates next position by a trapezium vel profile. The velocity profile of the ruckig runners is of type
scurve. So there is a difference. But the difference is tiny because of the 1ms cycle. This approach works in simulation and there is even published a video proof of it.

This approach simply can't work even in principle.
I don't agree with your statement. It's proved working.

in RTAI, realtime stuff is running as kernel module, and C++ is not possible in kernel modules. Nor can you link shared libraries. Hiding the C++ stuff behind extern "C" is not enough.
I also disagree with this statement you made here.
Using c++ in kernel modules is almost my daily task.

Grotius wrote:

•  
  • 
    @Rmu,
    The planner Joco is tested, is the original planner written by Rob Ellenberg. Integrated are 3 ruckig runners.
    The trajectory planner updates next position by a trapezium vel profile. The velocity profile of the ruckig runners is of type
    scurve. So there is a difference. But the difference is tiny because of the 1ms cycle. This approach works in simulation and there is even published a video proof of it.
    
    This approach simply can't work even in principle.
    I don't agree with your statement. It's proved working.
    
    in RTAI, realtime stuff is running as kernel module, and C++ is not possible in kernel modules. Nor can you link shared libraries. Hiding the C++ stuff behind extern "C" is not enough.
    I also disagree with this statement you made here.
    Using c++ in kernel modules is almost my daily task.

The TP from Rob Ellenberg uses trapezoidal velocity profile, but updating position isn't the only thing that happens there that assumes constant acceleration, i.e. path blending is optimized, that optimization doesn't apply if you change speed profile.

Additionally, what you are doing here, is you run 3 ruckigs, one per axis. Those three ruckig "runners" are not synchronized so movement of axis is not synchronized. E.g. runner one could decide it needs a segment of constant jerk to accelerate and a segment of constant jerk to decelerate to reach the target point whereas runner 2 would need constant jerk, constant acceleration, constant velocity and same sequence in reverse to reach target state. That won't ever run in sync.

Realtime stuff in linuxcnc on preempt-rt kernels is not running in kernel mode. If you are running C++ modules in kernel mode "daily" as you say, please give some hint to how you do it, because even coming up with compiler arguments or get something to link as a .ko is not trivial, and you lost no word on how you deal with C++ runtime system (exceptions, dynamic memory). I looked in your repository and found no hint of anything kernel module related.

So either you are running C++ in kernel mode, in that case it would be nice if you could give some explanation on how you make that possible, or you don't, then you wouldn't need all that extern "C" stuff and those hacks regarding std::vector and could write C++ in your TP. 

@Grotius - those values are already in place per ini files posted in forum.linuxcnc.org/38-general-linuxcnc-q...lib?start=190#286754

Values in use being:
FERROR = 10.0
MIN_FERROR = 1.0

Of cource when looking at the absoute ferror recorded in my previous post which I presume are in machine units, there is something more fundamentally at issue.  As there is no way a following error setting in excess of 600mm makes any kind of sense.

Thanks - J.
 

@Rmu,

 

I looked in your repository and found no hint of anything kernel module related.
Search for "module" and you will find ton's off it.

If you are running C++ modules in kernel mode "daily" as you say, please give some hint to how you do it,
Hint : the modules are loaded by "insmod".

And then your story about the ruckig runners, i am oke with your vision about it. We are testing a component
because of curiosity and to learn from it. I hope you understand that.