Trajectory Planner using Ruckig Lib

forum.linuxcnc.org/38-general-linuxcnc-q...g-lib?start=0#282422

The stock linuxcnc TP goes to great pains to keep the feedrate constant-ish while ensuring that machine can always be brought to a safe stop within available path segments and obeying acceleration limits. I didn't look too closely at this code for a while, but things like "following error" caused by this code is maybe related to ignoring (or miscalculating with) individual joint acceleration limits.

Currently the TP is running in the realtime-part of linuxcnc in the main 1kHz (usually) thread, so you are quite limited with how much you can calculate / optimize. The approach with ruckig lib also isn't suitable for RTAI systems where the TP is running as a kernel module.

@dm17ry

For information, on OpenCN we are using Spline to interpolate GCode and be able to calculate jerk-limited path. This can be a solution for 3 axis motion.

Regarding potential 4+ axis motion, I can't tell since we still have trouble with it on "all axis interpolated motion".

The approach with ruckig lib also isn't suitable for RTAI systems where the TP is running as a kernel module.This is not correct.Currently the TP is running in the realtime-part of linuxcnc in the main 1kHz (usually) thread, so you are quite limited with how much you can calculate / optimize.This is correct.(i.e. all motion is following a single straight line in 3d. or a single circle)chamfers or arc fillets won't help. if they do - it's a bugThis isn't contributing anyting usefull.As dm17ry pointed out, isn't a pause expected at hard corners in the current implementation?Yes. And the current path rules will stop the motion at 90 degree corners.@Joco,As for your findings. The fillets below a certain value, become a path stop for the look ahead.I think i know why. It could be a numerical limit off the function where it calculates the angles between the segments.So if you know 0.25mm for example is working, we know that for now, and is ok for now.For the coming test we will only use 90 degree line-line cornes or working fillets. First test offline.Then when the tp moves at 100% speed trough the fillet corner, try to monitor the vel graph of x,y axis. You mustspot a velocity jump, following error. (Vertical line in the graph).Try to lower the speed, at wich speed the velocity jump is gone?Ok good luck.In the mean time, i am hard coding, you will find out soon ! 

>>The approach with ruckig lib also isn't suitable for RTAI systems where the TP is running as a kernel module.This is not correct.

What do you mean "this is not correct"? 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.

Not that this limitation matters much, RTAI will probably go away sooner or later.

@Ratchet

The opencn feedopt code looks intimidating. Just from a quick glance you split the TP into a realtime and a userspace part and the translated matlab code is running in userspace? So is not limited by 1ms deadline? Did you evaluate rt preempt as alternative to xenomai?

@rmu

Yes, the feedopt code is intimidating. To be honest, I would not try to take this code as it lake documentation and specification. Not to mention it's developed under Matlab which make it lose its open-source and free side of the project.

We develop under Matlab, generate the C++ code, integrate it on the userspace side, fill a buffer for the RT side, buffer is read by ocno_machining.c FSM (Realtime) and send to the EtherCAT frame in the end. To be clear, everything related to TP is done in userspace side. RT is only in charge of "transmitting the data".

Yes we are not limited to the 1ms deadline, since we do everything "offline" on the userspace side. So, we were able to run the RT/EtherCAT up to 10kHz on a 3 axis machine.
Xenomai<->RTPreempt : To my knowledge, it may have been evaluated at the very start of the project. I cannot give a clear answer, my pure guess is that Xenomai has been selected to have less jitter.

@Ratchet

Thanks. The paper doi.org/10.1016/j.cad.2019.102752 is quite readable, maybe i will play around with this stuff in sagemath or scipy. I don't want to "pollute" this thread any more. 

@Rmu,

I use extern c inside kernel modules, no problem for me.

Hi all,

In the mean time, i got a little exited. I am putting something together, and will show you tiny part of it now.
It has something todo with gremlin c++ and a lcnc gui, yes in c++.
But for now this video.

P.s it uses the lcnc interpreter to load the cad data. Yes, it works, but i say it is not easy to setup this code.

@grotius I have no experience with c++ kernel modules, but wrapping c++ in "extern C" interface definitely is not enough to make it work. exceptions are a problem, as is rtti, dynamic memory, global constructors/destructors etc... all won't work out of the box. There is no kernel-compatible standard library. Stack size.

Here is an older talk about what hoops a company had to go through to get their c++ hypervisor stuff loaded into linux kernel.

I would be interested how your approach to get c++ (and libruckig) into the kernel works.

I've been buried under the lab workload in the lab for the last 3 weeks so Grotius was carrying this coding ship all by himself (sorry man), I'm finally back to work on putting some Doxygen documentation into the code to make it easier for others to see the details.