Trajectory Planner using Ruckig Lib

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.