ROS LinuxCNC Link

This is the way that ROS will be controller from a low level,

github.com/PickNikRobotics/ros_control_boilerplate

wiki.ros.org/ros_control_boilerplate

I am looking into doing similar with ROS and LCNC. I will have four 5-axis mills that will operate on the same parts at the same time, just on different areas of the same part. LCNC will still run a separate program on a separate controllers, one controller for each mill. I'm considering using ROS to control the position of each mill as each mill is on a conveyor that can move each mill around the edge of the parts. ROS will also control when each mill starts and stops and prevent collisions between mills.

Hi Bari,

Ambiguous project. Four 5 axis mill's off dmg mori would be a million's project.

Today i am starting to create a Linux embedded version. Just because i am interested in it. I have no goals.

Will take a bootstrap, a kernel and a qt program to run within a x window manager maybe sddm.

So no dekstop environment is loaded normally. It can be done by starting it manually as sys admin.

It should just boot up a qt program that display's a cnc program. For example it could display a robot teach pendant.
Let's find out. Have a nice day !

Hi,

After some reading, trail and error the principle works.

What we have is a embedded linux os starting a qt application. For the rest it does nothing at the moment.

To be clear, there is no desktop environment.

It's only one app that run's at the moment. Just like a apple phone. Everything is closed source. :woohoo:
It seem's closed source company's make big money.

Spec's :
1. It's booting into the qt app without login window. ( I bypassed this for now, login for user level can be activated. )
2. It's not using any window-manager like sddm etc. ( It uses a Xorg package and a libqt5widgets5 package from sid )
3. It uses systemd. Nothing is demolished after the debootstrap. So i coded in today's standard's.
4. Kernel : Linux debian10 5.10.0-6-rt-amd64 #1 SMP PREEMPT_RT Debian
5. Process documentation is hosted at : github.com/grotius-cnc/Linux-Embedded/releases/tag/1.0.0 -> howto.txt
6. First preview attached :

Wow... fckng hell.


7. Iso runtest ok.

I got a lot of idea's now.
Ok, next thing is to get some kind of hal layer working. Maybe strip down lcnc?
Maybe begin a lcnc module format. For the Ros we only need hal at the moment.

We need some kind of graphical artist.
If someone can build the teach pendant layout's in qt creator. That would be nice.
Only the layout with button's, labels, etc. is good. The signal and slot's will come later on.
Naming the buttons and labels following a coding style is important. I leave always the orginal name at the
beginning of the widget. A button begin's with "button-stop" for example. A label is "label-dro-xmax" for example.
Keep low letters to stay uniform. Use mid stripes to stay uniform. etc. Use color-template's for machine's.
We could add different types of pendant's. I suppose a mill is different then a robot.

Ok i have no goal. We will see how it goes. If there are helper's we can make progress.

Here is the iso to test out the software, just grab a old hard-drive and put it on. Check if your left over data usb's are removed for sure.
github.com/grotius-cnc/Linux-Embedded/re...0/Linux-Embedded.iso
The "normal install" is a auto installer. You don't have to do anything. It's using a preceeding technique.
After install it does a power down.

When you press the power button. The pc will boot straight into the embedded robot program. Ok have fun !!

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.