Trajectory Planner using Ruckig Lib

More
29 Nov 2023 20:48 #286815 by Joco
@Grotius - found this when reading documentation this morning:

The concept of a following error is strange when talking about stepper motors. Since they are an open loop system, there is no position feedback to let you know if you actually are out of range. LinuxCNC calculates if it can keep up with the motion called for, and if not, then it gives a following error. Following errors usually are the result of one of the following on stepper systems.

  • FERROR too small
  • MIN_FERROR too small
  • MAX_VELOCITY too fast
  • MAX_ACCELERATION too fast
  • BASE_PERIOD set too long
  • Backlash added to an axis
Any of the above can cause the real-time pulsing to not be able to keep up the requested step rate.


Any advice/idea on how the runners would be potentially driving requests for too high an acceleration/velocity?  Those being the ones most likely to be at issue?   The min/max follow error look to be looser than the sim and also work just fine with the standard TP.

Thanks - J.

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

More
30 Nov 2023 01:59 #286826 by smc.collins
You can use encoders for position feedback with Linuxcnc, there's a bunch of threads about it.

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

More
30 Nov 2023 03:10 #286835 by Joco

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.

I believe following error is calculated, tested and flagged within src/emc/motion/control.c from lines 462 to 489.  Extract post below:
    /* calculate following error */
    if ( IS_EXTRA_JOINT(joint_num) && get_homed(joint_num) ) {
        joint->ferror = 0; // not relevant for homed extrajoints
    } else {
        joint->ferror = joint->pos_cmd - joint->pos_fb;
    }
    abs_ferror = fabs(joint->ferror);
    /* update maximum ferror if needed */
    if (abs_ferror > joint->ferror_high_mark) {
        joint->ferror_high_mark = abs_ferror;
    }

    /* calculate following error limit */
    if (joint->vel_limit > 0.0) {
        joint->ferror_limit =
        joint->max_ferror * fabs(joint->vel_cmd) / joint->vel_limit;
    } else {
        joint->ferror_limit = 0;
    }
    if (joint->ferror_limit < joint->min_ferror) {
        joint->ferror_limit = joint->min_ferror;
    }
    /* update following error flag */
    if (abs_ferror > joint->ferror_limit) {
        SET_JOINT_FERROR_FLAG(joint, 1);
    } else {
        SET_JOINT_FERROR_FLAG(joint, 0);
    }


Thanks - J.

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

More
30 Nov 2023 03:55 #286836 by Joco
Updated the code on line around line 484 as follows to spit out the follow error info if it trips.
    /* update following error flag */
    if (abs_ferror > joint->ferror_limit) {
        rtapi_print("FERROR tripped on joint <%i> Error = <%f>\n",
                        joint_num, abs_ferror);
        SET_JOINT_FERROR_FLAG(joint, 1);
    } else {
        SET_JOINT_FERROR_FLAG(joint, 0);
    }

Attached is the log file from this run.
 

File Attachment:

File Name: run.log.txt
File Size:6 KB


Key info is the following error that was recorded on tripping the FERROR:
FERROR tripped on joint <0> Error = <624.997023>
FERROR tripped on joint <1> Error = <299.997023>
FERROR tripped on joint <2> Error = <299.997023>
FERROR tripped on joint <3> Error = <4.998571>
FERROR tripped on joint <0> Error = <624.997407>
FERROR tripped on joint <1> Error = <299.997408>
FERROR tripped on joint <2> Error = <299.997408>
FERROR tripped on joint <3> Error = <4.998756>
Attachments:

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

More
30 Nov 2023 04:34 #286837 by Joco
For clarity - this is the test file in use.

 

File Attachment:

File Name: gcode_test...1-29.ngc
File Size:35 KB


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.
Attachments:

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

More
30 Nov 2023 08:04 #286850 by rmu

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.

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

More
30 Nov 2023 09:15 #286852 by Grotius
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.

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

More
30 Nov 2023 10:14 #286857 by rmu

  •  

    • @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. 

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

More
30 Nov 2023 20:22 #286901 by Joco
@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.
 
The following user(s) said Thank You: Grotius

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

More
30 Nov 2023 20:27 #286902 by Grotius
@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.
Attachments:

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

Time to create page: 0.259 seconds
Powered by Kunena Forum