Closed 4DimK closed 5 years ago
Can we take a step back? What is it you're trying to communicate exactly, and for what purpose?
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.
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?
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) 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.
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.
Closing as it seems the OP has figured things out.
For future readers: it may be easier to use ros-industrial/abb_librws for this.
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.
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.
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 :)
Hi people,
I am trying to achieve the following: Pass extra information to the ABB controller (boolean, int, maybe a list). I was searching for something like a step-by-step guide to achieve this. The closest thread I find is this and issue #178 which I try to follow the advice and combine the information from the provided docs.
Some background: I have a working setup of an ABB IRB1660ID with ROS-I while using the Moveit Python Interface for controlling the arm. Move in Joint space is working. Linear movements working as well with the help of the cartesian path computation Moveit provides.
To create the custom_message in a somehow clean way, I have the following generic understanding:
simple_message/messages/abb_simple_message.h/cpp
in theabb-driver/src
.simple_message.h
.custom_msg_data.h/cpp
&custom_msg_message.h/cpp
) as atyped_message
type.custom_msg_downloader
&custom_message_interface
as the equivalents of the joint_trajectory ones, since I think it makes more sense to separate it from the trajectory one? For the ROS-I side.ROS_messages.sys
, for the RAPID side.Will the SmplMsgConnection connection work with the new message as long as I am using the simple_message protocol?
Am I missing something? I want to make sure that I am not spending effort in doing work that is already there as well as check if the concept is actually correct.
Thanks in advance!