ROS LinuxCNC Link

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.