Mitsubishi RV-6SDL Robot

rodw wrote:

Roiki wrote:

And yes, tormach is a leech company who only takes open source software others have done and then packages it yo with visual basic-like UI. The least they could do is contribute something back.

I'm not sure I agree with that. They did contribute enhancements to the trajectory planner and their state tags branch finally made it to the core code in V 2.9 after being left out in the cold for over 5 years. I think thats why in the video they say they will contribute back what is accepted by the development teams of linuxcnc and machine kit.

I think Machinekit has separated out the GUI and other parts into a more modular design which might help Tormach work with multiple machines. eg a robot tending to a milling machine... where the machines work together.

If that's the case, good for them. Though I'd expect them to contribute back a lot more. Or maybe the fault is more in the lcnc maintainers, I'm not sure.

And yes machinekit has been split into two applications. Machinekit-HAL has the realtime hal environment only and EMCApplication had the path planner, gcode parser and gui elements. That way it's easier to use just the HAL for custom machines if you're not going to use the provided cnc parts of the program. It's a really nice way to do things in my view.

Linuxcnc is fundamentally a good realtime motion controller, while ros is by far the more superior path planning and kinematics framework. Making them work together is in my view the way forward.

I certainly agree with that but who is going to do the work? Machinekit has apparently done it but have not put the effort into documenting it. This is a fundamental problem of open source and community driven projects. Lot's of ideas and initially a lot of motivation until it sort of kind of works and then things start to get bogged down, nobody there to consolidate the code let alone document it and finally people move on with other things. Not even commercial software development is immune to that.

Lcnc maintainers have long resisted this and wanted to maintain their C lair and monolithic application. They're like the grumpy old uncle that refuses to get on with the times.

Let's be fair, some people have put a lot of hours into LinuxCNC for many years and they have maintained a product that works very well at what it is supposed to do. And while it may sometimes seem to hold back innovation, maintaining code is conservative business and while machinekit is a good example for innovation it is also a good example of how that can end in thin air.

[edit]
The other thing to keep in mind is that ROS is a framework. It would open possibilities, no doubt about that, but it will require a fair bit more to actually get a useful application out of it. Maybe it would be more economic to see if one could write a driver to connect RoboDK to LCNC?

He created the attached for me a while ago that is something close to Gcode. But he did mention that it will need adjusting.

I've adjusted the postprocessor so it spits out Gcode in the correct format for my setup. The main problem is now that the genserkins kinematic in LCNC is less powerful then the kinematics used in RoboDK and that some linear moves that work in RoboDK throw an error in LCNC: "Linear move on Line x fails kinematicsInverse".
So this brings us back to the need for more powerful kinematic libraries and the limitations to using an external software like roboDK tool to create GCode for LCNC.
If LCNC as the controller can't provide the needed kinematics power then the external software would need to spit out a large number of small moves in joint space. $
Clearly _some_ integration of KDL or other more capable kinematics is needed.

user Grotius has been working on integrating KDL into LCNC:
forum.linuxcnc.org/38-general-linuxcnc-q...-c-c?start=60#190602

Unfortunately I have struggled to get the necessary environment set up.

Aciera wrote:

Clearly _some_ integration of KDL or other more capable kinematics is needed.

user Grotius has been working on integrating KDL into LCNC:
forum.linuxcnc.org/38-general-linuxcnc-q...-c-c?start=60#190602

I have known for a while now that the kinematic module within LinuxCNC is not up to the task for six axis robots. I got really excited to see Grotius working on integrating the Orocos Kinematics and Dynamics Library. From my research in the past, ROS uses the same library.

wiki.ros.org/kdl_parser
wiki.ros.org/kdl

Aciera wrote:

Linuxcnc is fundamentally a good realtime motion controller, while ros is by far the more superior path planning and kinematics framework. Making them work together is in my view the way forward.

I certainly agree with that but who is going to do the work? Machinekit has apparently done it but have not put the effort into documenting it. This is a fundamental problem of open source and community driven projects. Lot's of ideas and initially a lot of motivation until it sort of kind of works and then things start to get bogged down, nobody there to consolidate the code let alone document it and finally people move on with other things. Not even commercial software development is immune to that.

Lcnc maintainers have long resisted this and wanted to maintain their C lair and monolithic application. They're like the grumpy old uncle that refuses to get on with the times.

Let's be fair, some people have put a lot of hours into LinuxCNC for many years and they have maintained a product that works very well at what it is supposed to do. And while it may sometimes seem to hold back innovation, maintaining code is conservative business and while machinekit is a good example for innovation it is also a good example of how that can end in thin air.

[edit]
The other thing to keep in mind is that ROS is a framework. It would open possibilities, no doubt about that, but it will require a fair bit more to actually get a useful application out of it. Maybe it would be more economic to see if one could write a driver to connect RoboDK to LCNC?

That's the tricky part. Particularly because Linuxcnc is so old and insists on using C, limiting the people capable of doing it conciderably. Though if you go over machinekit code. The ring buffer concept kind of already exists (to my understanding) in the undocumented c++ api into the Linuxcnc NML messaging. This part of lcnc is also undocumented.

Also linuxcnc is a fantastic at what it was designed to do(though I disagree with some design choices). It was just never designed for robotics. Square peg, round hole.

Also while ROS is a framework there's already projects such as moveit and ros-industrial that streamline the effort of getting things up and running. The biggest hurdle really is the gui since no one has published one before.

Also roboDK is cam software. Like any cam it doesn't control a machine directly, it simply translates the instructions into a readable code(like Gcode). The robot still needs a compatible parser, kinematics solver, path planner and hardware interface.

Also ROS2, which is under active development right now, has a roadmap target of building a realtime environment for real hardware control(which never made it into ROS1). Making Linuxcnc/machinekit etc redundant. There's also micro-ros which aims to implement ros2 compatible ros on microcontrollers(again, realtime hardware). These are still being worked on.

thefabricator03 wrote:

Aciera wrote:

Clearly _some_ integration of KDL or other more capable kinematics is needed.

user Grotius has been working on integrating KDL into LCNC:
forum.linuxcnc.org/38-general-linuxcnc-q...-c-c?start=60#190602

I have known for a while now that the kinematic module within LinuxCNC is not up to the task for six axis robots. I got really excited to see Grotius working on integrating the Orocos Kinematics and Dynamics Library. From my research in the past, ROS uses the same library.

wiki.ros.org/kdl_parser
wiki.ros.org/kdl

It's one of the possible solvers in ROS, not the only one. ROS has the nice feature that it can use multiple existing solvers or completely custom ones.

Personally I think it's a bit of a wasted effort to try to bring kdl into lcnc. Instead of developing a bespoke solution it would be a lot smarter to use that effort to integrate existing programs instead of writing something completely custom. This also runs into the maintenance trap that as soon as the person who made it doesn't maintain it anymore, it usually becomes unusable.

It's still nice to see people putting in the effort but I don't see the benefit of that approach over ros integration.

I think we are still along way from ROS2 having a proper low level hardware control that could compete with the features that LinuxCNC or Machinekit can offer. I think its a bit nieve to say they can do low level control as well as the we can currently do it with LinuxCNC.
And after thinking about it it goes both ways. ROS is pretty much the defacto standard for robot high level control and I think will be for the foreseeable future. It also has the backing of the big manufactures.

I really do think that combining ROS and LinuxCNC or Machinekit is the way forward for very cost effective six axis robot control. Back in 2017 I reached out to several companies about buying robot control systems for my old robots and pricing varied from $20k AUD up to $150K depending on my needs. Using this open source software is basically free, although the user needs to have an idea of how to install the software and the systems I was quoted were basically turn key.

I really cant wait to see how Tormach go with selling their robots.

I think we are still along way from ROS2 having a proper low level hardware control that could compete with the features that LinuxCNC or Machinekit can offer. I think its a bit nieve to say they can do low level control as well as the we can currently do it with LinuxCNC.

That is exactly how I see it. ROS may be a superior framework including kinematics and corresponding software development but I certainly have not seen anything in the way of an actual commercial grade hardware controller. Sure there are Arduino hacks and the odd home brew but while universities are often involved in software development they don't seem to be to eager to come out with a hardware solution that would need to handle all the safety interlocks needed for running a robot in a machine shop.
LCNC has reliable hardware solutions that are proven in commercial settings and that at very affordable price.
In my eyes LCNC, with all it's limitations in the respective kinematic, is a lot more useful to running an industrial robot than ROS is with its far more advanced kinematics but lack of hardware interfaces.

Personally I think it's a bit of a wasted effort to try to bring kdl into lcnc. Instead of developing a bespoke solution it would be a lot smarter to use that effort to integrate existing programs instead of writing something completely custom. This also runs into the maintenance trap that as soon as the person who made it doesn't maintain it anymore, it usually becomes unusable

There is certainly truth in that. As long as such an integration is just pursued by one individual programmer and not embraced by a larger development group it's more likely to quietly disappear in a few months than not. The problem is finding somebody who has enough time, motivation and skill to actually come up with the code necessary to get the job done and I think it might be difficult to find such a person even if you were willing to pay for their services. Hence my interest in the possibility of integrating KDL into LCNC. If it could be done in a way that requires only limited changes to the LCNC source code then it will be more likely accepted into the master.
I doubt that robot control will ever draw enough interest in the user base to warrant fundamental changes to the source code of LCNC. I even doubt that ROS integration is going to make it onto the list of priorities.
There has been some effort as recently as July to rebase machinekit on LCNC master but as far as I'm aware it has not succeed.

Aciera wrote:

I think we are still along way from ROS2 having a proper low level hardware control that could compete with the features that LinuxCNC or Machinekit can offer. I think its a bit nieve to say they can do low level control as well as the we can currently do it with LinuxCNC.

That is exactly how I see it. ROS may be a superior framework including kinematics and corresponding software development but I certainly have not seen anything in the way of an actual commercial grade hardware controller. Sure there are Arduino hacks and the odd home brew but while universities are often involved in software development they don't seem to be to eager to come out with a hardware solution that would need to handle all the safety interlocks needed for running a robot in a machine shop.
LCNC has reliable hardware solutions that are proven in commercial settings and that at very affordable price.
In my eyes LCNC, with all it's limitations in the respective kinematic, is a lot more useful to running an industrial robot than ROS is with its far more advanced kinematics but lack of hardware interfaces.

Yes, ROS2 having realtime tools is still a ways off and I don't like to depend on future promises. But they are coming eventually.

Also:
www.adlinktech.com/en/ROS2-Solution.aspx

They aren't common yet or cheap but they do exist. There's a whole lot of industrial uses of ros outside of robot arms. You just don't see it advertised. The fact is that Linuxcnc doesn't run any industrial robot in any industry, has never been offered or concidered for that. Ros has and is running on real industrial robots today. We all love Linuxcnc but ros is the one that's used by actual industries and companies, not linuxcnc. Even tormach seems to go for machinekit for their robot. You can't make a useful robot arm out of a linuxcnc. Period. With ROS you certainly can.

Also if you have a company, rosin project offers EU grant money for developing the ros industrial framework.

Personally I think it's a bit of a wasted effort to try to bring kdl into lcnc. Instead of developing a bespoke solution it would be a lot smarter to use that effort to integrate existing programs instead of writing something completely custom. This also runs into the maintenance trap that as soon as the person who made it doesn't maintain it anymore, it usually becomes unusable

There is certainly truth in that. As long as such an integration is just pursued by one individual programmer and not embraced by a larger development group it's more likely to quietly disappear in a few months than not. The problem is finding somebody who has enough time, motivation and skill to actually come up with the code necessary to get the job done and I think it might be difficult to find such a person even if you were willing to pay for their services. Hence my interest in the possibility of integrating KDL into LCNC. If it could be done in a way that requires only limited changes to the LCNC source code then it will be more likely accepted into the master.
I doubt that robot control will ever draw enough interest in the user base to warrant fundamental changes to the source code of LCNC. I even doubt that ROS integration is going to make it onto the list of priorities.
There has been some effort as recently as July to rebase machinekit on LCNC master but as far as I'm aware it has not succeed.

Hopelly tormach can blow some air into the machinekit project.

But that's usually how it goes with open source projects. They only live as long as there are developers interested in developing them forward. Active community certainly helps but even that is not always a guarantee. And I don't think it would take much of a code change(if any) to integrate a realtime ring buffer component to linuxcnc. I'm under the impression the mechanisms already exist but the documentation doesn't since large parts of lcnc are also undocumented. I guess the guy who made it for machinekit could answer that.