Pass extra information to RAPID about abb HOT 10 CLOSED

Can we take a step back? What is it you're trying to communicate exactly, and for what purpose?

from abb.

First, thanks for the quick response.

Now. the idea is that i want to pass extra information to the controller (eg. weld data) and a boolean which will determine whether the aforementioned data should be used or not.

from abb.

This is is also something I am interested in, would be nice to send custom information to the robot controller.

I have had a quick glance through the simple_message package. Seems like your approach is right.

Create simple_message/messages/abb_simple_message.h/cpp in the abb-driver/src.
Assign the specific message type as in simple_message.h.

I do not think you need to create an own version of simple message as the main change/addition in simple message will be your custom message type, like you said. Unless you do not want a simple_message that differs from the official release. But, adding your own message type into the simple message is the goal of these standard message types. Correct me if i'm wrong.

Create a new custom message (eg. custom_msg_data.h/cpp & custom_msg_message.h/cpp) as a typed_message type.

This should do the job. The "custom_msg_message" inherits from typed_message. The implementation of typed_message should work fine. Note that "custom_msg_data" must have correct implementation of simple_serialize, mainly the load, unload and get size functions.

Create a custom_msg_downloader & custom_message_interface as the equivalents of the joint_trajectory

Yes, it is probably better and cleaner to create a new downloader. You can combine the interface and downloader as you won't be needing all the functionalities in the interface or the downloader. See send_to_robot, create_messages and the callback functions.

Will the SmplMsgConnection connection work with the new message as long as I am using the simple_message protocol?

After a quick glance, I don't see any links to the header or implementation of joint_trajectory.. This means that simple_message is enough to wrap your equivalent to joint_trajectory.

Am I missing something?

You should look into how to get your data in the downloader. Currently, its done with a subscriber and trajectory callbacks.

Lastly, where will this new downloader be instantiated?

from abb.

Ok, I have been working on it these days.

Thanks for the input.

So, I went with the implementation as explain before. Without going into details:

The implementation of typed_message should work fine.

That is indeed true. Inheriting from typed_message was enough.

Yes, it is probably better and cleaner to create a new downloader. You can combine the interface and downloader as you won't be needing all the functionalities in the interface or the downloader.

What I did was to create the following:

• abb_custom_msg_downloader_node
• custom_msg_downloader
• custom_msg_interface
• custom_message (inherits from typed_message)
• custom_msg_data(inherits from simple_serialize)
• along with a new type of msg & srv files (customData.msg, CmdCustomData.srv)

The interface connects and transmits the bytes through a newly assigned port.

From RAPID side I added another server, e.g customMessageServer.mod which listens to that port, along with some implementation for the callback and the new type of message (header,bool etc).

Lastly, where will this new downloader be instantiated?

Since I created a new node for transmitting the data, I just added the node in the robot_interface.launch. That way it starts together with the motion/state server and connects to the new port. There are of course other ways to achieve the same result without creating an extra downloader node, it is a design decision I guess.

This works for now. Maybe with a little bit more implementation it can become more generic so that it can be used with any kind of message type.

Although, I have to agree with gavanderhoorn's comment. It would be nice for new users, like me, if this procedure could be explained somewhere.

from abb.

This works for now

Very nice! Good to know.

Maybe with a little bit more implementation it can become more generic so that it can be used with any kind of message type.

This would be a nice addition for tools that arent controlled through a joint trajectory. Some kinda interface to make it easier to create a custom message would be nice. Though, there is more to it than creating an interface. Factors like enabling the msg generation for newly user defined message types seems to be challenging. Regardless, it seems possible.

from abb.

Closing as it seems the OP has figured things out.

from abb.

For future readers: it may be easier to use ros-industrial/abb_librws for this.

from abb.

Yes, that was some time ago and forgot to mention that it was concluded at the end, sorry about that. Indeed abb_librws is a good way to go, only drawback and the reason i did not go with it back then, was because, as far as my understanding goes, I would not be able to generalize my implementation and extend it into other robot brands apart from ABB. Maybe the situation is different now. Thanks for closing the issue.

from abb.

as far as my understanding goes, I would not be able to generalize my implementation and extend it into other robot brands apart from ABB

that would be correct. RWS is an ABB-specific protocol that only works with RW6 and up.

Seeing as you posted this on the ros-industrial/abb tracker and you asked how to "pass extra information to the ABB controller [..]" it would seem incompatibility with other brands was/is not an issue.

from abb.

Yes that is true at the level of my implementation. Although, my contribution was just a part of a bigger idea and the concept was to stay within the boundaries of what i found to have better support and similarities between different vendor packages. The abb-driver route, seemed to be a better fit at that moment of time :)

from abb.