industrial_core
industrial_core copied to clipboard
simple_message: add serial smpl_msg_connection implementation
For robots that lack ethernet (TCP/IP) networking support.
Especially older robots often don't support socket comms, even if they have a network interface. Using serial ports can then be a good alternative.
It shouldn't be too hard to get this to work. Potential issue could be the lower bandwidth of serial connections: most older controllers don't go above 19k2 or even 9k6 baud. Typical robot_state
traffic (at ~40 Hz) is something like 4 to 5 KB/sec.
Hey, this might be a pretty old topic. But im facing the same issues now. Is there any answer on how to establish serial communication to an old abb. I have a IRB4400 with an S4 controller.
Nothing has changed here. AFAIK there is no serial transport available.
Is there any answer on how to establish serial communication to an old abb. I have a IRB4400 with an S4 controller.
a serial transport would probably be the way to go.
If you'd like to see whether you can avoid changes on the industrial_robot_client
side, perhaps a serial-to-TCP/IP bridge could be used on the ROS side, with some suitable edits on the RAPID side to use a serial port instead of a socket.
netcat
should be able to do that. Perhaps even something like an RPi could be used.
Thank you for the fast answer. I want to refer to the following post: How do I visualize an ABB robot's movements in Rviz I'm a beginner in this topic but as i understand your answer you are talking about that kind of bridge, where he used his ESP8266 as the mentioned bridge. For publishing his states he used the "open_abb_serial_logger" which unfortunately seems not to be available anymore. Another way might be to buy the DSQC336 ethernet card and connect to it.
Are there any other requirements to establish a connection from the robot to the serial port. When i look into my SysPar i can see that i have SIOs but im not sure how to make the first step to get a connection.
Unfortunately I have no experience with anything older than IRC5.
If your controller has serial ports available and those can be used in RAPID programs, you should be able to change the RAPID code in abb_driver
to use them instead of the regular TCP sockets.
Connect your controller to your ROS PC using serial cables (you'd need two: one for state, the other for trajectories).
At that point, you could run netcat
on your ROS PC, have it relay the serial ports to the required TCP sockets (11000
and 11002
) and make the abb_driver
ROS nodes connect to the TCP sockets opened by netcat
.
netcat
should relay the serial data to TCP, and perhaps abb_driver
is able to communicate with your S4 that way.
But no guarantees.
When i look into my SysPar i can see that i have SIOs but im not sure how to make the first step to get a connection.
That would probably require some reading of the RAPID manuals and/or finding examples. What's important is to be able to send and receive binary data over those serial ports.
Thank you so far. I will do the following steps
- How can i send and receive data with RAPID over my SIOs
- (IF 1. is possible): Connecting the serial Ports to my ROS PC (at the beginning id use my normal PC)
- Sending Simple Data to the ROS PC and trying to read them with netcat
- Using netcat to send serial data to TCP
- Using abb driver ROS nodes to connect to the lets say virtual netcat TCP port
- See what happends
- If 1. Doesnt work, i might need some help from abb to transeive data from my robot (by some kind of addon or maybe direct connection with an DSQC336)
This can take some time, but i will keep you informed.
btw. Do you have any information about the open_abb_serial_logger. Maybe a copy of the repository which i could use.
This can take some time, but i will keep you informed.
thanks. I'd be interested to hear whether this works.
Do you have any information about the open_abb_serial_logger. Maybe a copy of the repository which i could use.
no. I never used the package, nor cloned it.
@muesgit: did you get socat
to work in the end?
@gavanderhoorn Good morning. I am still working on the connector for the serial port cause mine was a little bit faulty. But I hope soon I can give u more information.
@gavanderhoorn Hi, I have a short feedback today for you. I managed to use com2 to print a RAPID Programm to the HyperTerminal via print command from the roboter terminal. The bad thing is that it seems that I need "Extended Functions" to even use the commands "open, close etc." for sending serial sending and receiving serial Information.
Ah, so you can't use your serial port(s) for any data transfer from/in RAPID programs?
That's going to be a requirement in order to be able to use something like abb_driver
I'm afraid.
Ah, so you can't use your serial port(s) for any data transfer from/in RAPID programs?
That's going to be a requirement in order to be able to use something like
abb_driver
I'm afraid.
Well in principle it is working, since we could use the print button from the s4 to send data to the hyper terminal, but i think for "real" communication i need to order these so called extended functions from abb. I contacted them and lets see if they provide me the disk.
i think for "real" communication i need to order these so called extended functions from abb
yes, that's what I was referring to.
The HW works, but you can't write to it nor read from it without some additional RAPID infrastructure.
@gavanderhoorn I have a positive short feedback. With the help of ABB Technical Support I was able to find out that i already had the optional disk in my bootdisks. I was now able to send a message through my 3 serial ports. :)))
Nice. Good to hear.
I'd suggest though we now move the discussion to abb_driver as I believe you're going to use the work-around I described in https://github.com/ros-industrial/industrial_core/issues/107#issuecomment-857689295. That's different from implementing a proper serial transport for simple_message
.
I wonder why not using rosserial. Should be possoble to install rosserial_python on a raspi and communicate via a rosserial enabled pc instead of using netcat to translate the protocoll to tcp?
I'm not sure I understand what you're suggesting.
SimpleMessage does not use the rosserial
protocol. Nor is rosserial
compatible with SimpleMessage.
The purpose of netcat
is to change the medium used, as the protocol would still be SimpleMessage. It would just be SimpleMessage-over-serial coming out of your ABB controller. The standard nodes in industrial_robot_client
are only capable of accepting SimpleMessage-over-TCP. That's what netcat
will do for us: change serial<->tcp.
I understand... I was suggesting this option as an alternative to send serial information from the pc to the robot and back. But how you say this might not be a smart way, since i would loose compatibility to the robot driver.
Just to clarify: rosserial
comes with a custom protocol. It's not a generic serial port interfacing library. Code running on "the other side" (ie: not ROS nodes) must "speak" the rosserial
protocol. That doesn't help with abb_driver
, as it doesn't do that.
You could of course write a version of abb_driver
which does use the rosserial
protocol, and then you could use one of the rosserial
servers to connect it.
As to your suggestion to use another PC: you could definitely use an RPi and run netcat
on that. Connect the serial port(s) to your RPi, put the RPi in the same network as your ROS PC and run netcat
on the RPi. Make netcat
listen on the appropriate ports (ie: 11000
and 11002
).
Now "pretend" the RPi is in fact the ABB controller and configure abb_driver
to use the IP address of the RPi.
If things work, the industrial_robot_client
nodes would not notice the difference.
@muesgit: have you been able to get things to work?
@muesgit: have you been able to get things to work?
Hey, actually not but up to now i was able a to establish a simple connection between the S4 controller and my pc from RS232 to TCP and vice versa via Arduino as a middleman (Arduino + Ethernet Shield + RS232/TTL Board).
On the PC side i use netcat
how you suggested. On the S4 Side i wrote a simple Write And Read .PRG
I can send and receive messages. The next step would be to test the simple_message
with ROS.
Note that you'd still need to update abb_driver
's RAPID to not use sockets, but serial ports.
Ive checked the Rapid Codes from the abb_driver
and i seems like i have to rewrite some functions.
The following statements do not exist in RobotWare 2.1 (I put some of my thoughts in brackets on how to redefine them):
rawbytes (is there another way to pack data, for example in a buffer? maybe an array of data) IPers (if pers var != 'original definition'.... then...) WaitTestAndSet (if bool var == FALSE .... then instruction = TRUE) ExitCycle (Use standard EXIT) IsStopMoveAct (set the output of a motion task e.g. DI1=1 if its finished or DI1=0 if it is still running) ClearPath (set size of trajectory to 0) SkipWarn (can be deleted without big issues --> the log will be bigger) UNDO (not sure how to redefine it)
and ofcourse all the socket functions which shouldnt be necessary after redefining to use serial
I also have to check if i have the possiblity to get the Multitasking option for our old robot. Otherwise i think the provided driver is not usable for me.
Its pretty hard to get the Multitasking option atm as it also takes too much time. I think the easier way for me would be to use rosserial and to simply transmit a trajectory from ROS to the S4 Controller. Is there a way to publish the trajectory from ROS by using the ABB driver to my Arduino node? From there i would redirect it to the S4 controller to load and execute the points in a loop. At the end of the execution i would like to send the final position of the robot back to ROS.
With that workaround i could at least do some kind of offline pathplanning without using the floppy harddrive to transmit the code.
This starts to get off-topic too much for this issue.
I'm willing to discuss alternative approaches, but please use a more appropriate venue for it. Seeing as you're working with ABBs, I'd suggest the issue tracker of ros-industrial/abb_driver
.
Thats true, sorry for that. I will open a new topic there and describe the problem.
The new topic is here now: ABB_Serial