0
$\begingroup$

Rosanswers logo

Hi

I have started the research process for getting ROS to send trajectory data to a control box for a 6DOF robot arm, built around 6 STM32 based servo drives. Between the drives / motion control board and the PC is a Mesa Electronics Ethernet Anything I/O card. At present there is a CNC program that talks to the i/O card over ethernet, and encodes its trajectory data, generated from gcode, via UDP packets.

However the UDP protocol the mesa cards uses is proprietary, called LBP16, for which I have a detailed breakdown that I am yet to understand. Wireshark cannot understand it out of the box, so I am guessing that most operating systems would also not be able to use it without a specific module or library. I do not want to use the CNC program, but rather to have ROS linked directly to the controllers.

As the I/O card is using a proprietary UDP protocol, is it going to be necessary to code this into the ROS driver? Or would I need some separate program that translates the trajectory data into the correct UDP protocol?

Apologies if this seems vague, I am at the stage of beginning to understand the problem, and also to get some sense of how big an undertaking it will be. Certainly industrial ROS drivers such as the one for motoman seem to be extremely weighty programs.

I am using kinetic on Ubuntu 16.04 but am not tied to that combination.


Originally posted by Wireline on ROS Answers with karma: 48 on 2019-07-14

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Seeing as you're using Mesa hardware and have "a CNC program talking to the card" (LinuxCNC?) you might want to take a look at the work done in Machinekit towards integration with ROS.

Some links:


Originally posted by gvdhoorn with karma: 86574 on 2019-07-15

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by Wireline on 2019-07-15:
Thank you for the suggestion. I should have mentioned that I have already looked into MK and want to avoid using it. It operates by using the HAL ringbuffer within MK (which LCNC does not possess), and whilst it does work, I want to look into writing a driver that completely eliminates CNC programs and allows ROS to talk to the robot directly.

MK has the same implementation of LBP16 as LinuxCNC, so I would still like to know if it will be necessary to write a separate implementation of LBP16 if just using a standalone driver. Also same question as before, will writing a driver for an arm controller be a considerable undertaking?

Thanks!

Comment by gvdhoorn on 2019-07-15:\

I should have mentioned that I have already looked into MK

yes, you should have.

and want to avoid using it.

can you provide some rationale as to why you want to avoid it?

You're going to need a real-time execution environment, trajectory generation and execution, real-time (re)sampling and state reporting. You could write all of that yourself, or re-use something that already exists.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.