ROS LinuxCNC Link

Hi

I have stripped down lcnc's source code for the robot project.

What's left is a Hal layer and a working halcompiler with rt component's in the rtlib.
In the /bin directory, halmeter etc, works.
Removing more from the source code is possible, but takes more time. Some parts are left like nml.

Archive non-compiled only 7.8 Mib:
github.com/grotius-cnc/Linux-Embedded/re...nux-hal-clean.tar.gz

Archive compiled only 11.1 Mib
github.com/grotius-cnc/Linux-Embedded/re...-hal-compiled.tar.gz

In order to get ros to work you need an interface to pass commands from user space to rt space. This does not currently exist except for gcode.

There exists a fifo implementation in the rtapi but it's badly documented. It's used in the streamer and streamer_usr components to stream hal data from files to hal pins. Then you can take the simple_tp component or modify the source and use coarse_pos pins for the normal trajectory planner and you have your realtime motion pipeline. This is by far the hardest part thats been tripping me for the past two years.

I've been working now and then in modifying the streamer component to add a zmq+protobuf interface but I suck at C so its slow.

After you've done the motion buffer you can use the normal python api to build whatever gui or integration on top fairly easily.

Hi Roiki,

In order to get ros to work you need an interface to pass commands from user space to rt space. This does not currently exist except for gcode.
This exist's. We have already the c++ rtapi interface running. It works very well. You can take a
look in this archive , file halio.cpp is the most interesting one.

Then you can take the simple_tp component or modify the source and use coarse_pos pins for the normal trajectory planner and you have your realtime motion pipeline
That can be done that way. But i see a tiny problem.

Today i started with finishing a motion planner with s-curve implementation.
I started the project
some time ago, but never finished it to higher level.

What lcnc misses in the motion planner is calculating 3d arc path lenghts for s-curve motion planning.

In fact it's missing
a 3d G02 / G03 command like :

G02 [xs,ys,zs] [xe,ye,ze] [xc,yc,zc]
where xs=x start, xe=x end, xc =x circle center

For robot's and other machines, 3d motion command's are quite normal. With today's gcode intepreter you cannot give 3d Gcode motion commands, except a G1 (lineair) one.

Calculating an arc-lenght from g1 segment's is cpu intensive. Especially for a look ahead implementation where you have to look when to do a dcc to stop exactly at target point.

I hope i can code something together that will work. But i have to load in my brains into it. This kind of project can be boring to code.

After you've done the motion buffer you can use the normal python api to build whatever gui or integration on top fairly easily.[/i]
Yes yes, off course !!

I meant in linuxcnc it doesn't exist. Except the rtap fifos but no one has built one yett.

Also you don't need the 3d arcs if you use ros since all the motion planning is done in there. You only need simple per joint trajectory planners that can follow provided setpoints. If you intend to build kinematics into linuxcnc then yes, you need a better trajectory planner. But that makes ros redundant.

All I'm really interested is buffering non realtime motion commads from ros to the realtime hal. Everything else can be done with ros that has all the trajectory planning and path generation. Then you can build a simple code parser for a robot language in python. Or use pure python directly.

Hi,

All I'm really interested is buffering non realtime motion commads from ros to the realtime hal.
Me too. I hope tomorrow i can code parts of the buffer.

I have thought already of different way's. Mostly during coding i get the solution.
If you ask me a buffer in ms look interesting. For example a 3000ms buffer is a std::vector of 3000 waypoints. A buffer of 10 look ahead gcode lines is useless.

We can use the gcode to preprocess the acc and dcc start points.

Working with std::vector buffering has up and downsides.

Everything else can be done with ros
I didn't look, but can it load gcode?

The size of the buffer isnt really an issue. All that matters is that the setpoint generation is faster. The fifos in RTAPI can be used, the modifying the streamer components userspace part is likely the easiest since it already has everything needed. just need to add the parts that make the external interface. The fifos can be used to stream any data that hal pins support so its really flexible.

i dont really see the need for any processing. The setpoints you get from ros arent gcode. So either you want to run code directly on linuxcnc, which needs its own kinematics and makes ros redundant. Or you generate the trajectories in ros and just stream the raw trajectory points to the linuxcnc motion controller. It doesnt need to understand anything since it doesnt need to be aware of multiple joints.

ros has no code processors. youd need to make them, which isnt very hard with python. Though you'd be better off in using something that mimics the code used by kuka or fanuc. not gcode. tormach uses just pure python for their robots. UR uses urscript which is a fairly simple text language with real words. easy to read, unlike gcode.

Hi,

Maybe i can install Ros tomorrow and take a look. Then try to connect it to hal. Then the topic question is hopely more or less solved.

For my personal view, i am quite close to a solution without Ros.
Maybe my opinion changes when i have played around a bit with Ros. I will take a look over there and report back.

i dont really see the need for any processing.
If you want to make nice moves, you will need to do processing, but that's my view on the story.

If you want to make nice moves, you will need to do processing, but that's my view on the story.

Yes and you do this processing with ROS. Linuxcnc doesn't need to be aware of any of it.

Hi,

Here is my report :

I compiled Ros from source for debian 11. Everything went ok.
Attached my howto install documentation.

After compiling (time consuming) it would not start Ros. Somehow it will not run.
The bash script's where set executable etc. Nothing happens.

In the meantime i studied several Ros examples, including the c++ code examples.

Ok. I have a conclusion. For me it's a non-productive software solution.

The experience i have beside Ros has much more power and speed to become very productive and professional.
So for me i leave Ros as it is, with respect for the developper team and Ros users. It has a reprository with many star's.

Hi,

A tiny update.

I did some work in the meantime.

1. Created a embedded linux install version for robots.
2. Created a advanched s-curve motion planner. We need this for nice moves.
3. Created a realtime path planner wich behaves like a video player with 1000 frames a second. This is really a big thing.
4. Created a c++ halviewer. We have now full control.
5. Now creating the different robot, cnc machine teach in functions for 3d usage.

This is how the robot path will be when doing a rapid move, green = "teach in points". The path is of type spline.


One thing i really would like to have is a 3d arc motion path. I was working on this for many hours, but no succes so far.
My math level for this 3d arc is too tiny at the moment, and i found no usefull examples.
The arc teach in, contains from 3 points.

At the moment when using a G2 or G3 you can do this only in one plane at a time.
A G2-3d or a G3-3d does not have to be related to a plane or matrix. It can be a free motion performed from any machine angle.
It could be used by 3d milling operations.

[Edit]

After some research i could get the 3d arc waypoints.


The arc waypoints are retrieved from a function in the opencascade library.
The complete function as in the picture for the yellow cones :

At this stage, we know everything to get a robot teach in program running.