Integrate / migrate to ros-industrial/majorana msgs/srvs?

[gavanderhoorn]

Just seeing whether there would be any interest to migrate to the messages and services defined in the ROS-Industrial Majorana project.

The message set is intended to try and bring some uniformity to the interfaces to impedance / force-control supporting (robot) controllers with a ROS interface out there. There has been some initial work to get ahundt/grl working with it, and it would seem this driver could benefit from it as well.

[SalvoVirga]

In short: yes, we would be interested but we are not sure it is the right moment.

Long version:
We (me and @marcoesposito1988 ) were aware of that project (as we know the author) and we discussed a bit about integrate it in our package. In general, we are always more than happy to use what is (or what is considered) the "standard" and appreciate the effort of defining what could be a standard for impedance/force messages.
We are just not sure that project is in a stable/final stage, nor that the community discussed too much about it (I saw quite some discussion in the first PR, but not much in the second one). We just want to avoid to adapt our code to something that might change soon.

One thing about that project (which should actually be a plus for us) is that it is shaped on the IIWA and its interface. It would be good to have feedback from users of other robots that have an impedance interface (to me unknown tbh).
On the other hand, we understand that having already some packages (like ours or grl) using those messages and service might help them to become the actual standard and improve.

Those are more or less our thoughts on that, @marcoesposito1988 can add more if he feels like.
Sorry for the late reply btw, holidays and work duties drained our time.

What is your opinion?

[gavanderhoorn]

You've basically described the exact two reasons why I thought it might be nice to use the msgs in this driver:

1. there has been some discussion about the design of the msgs and services, but definitely not enough, and also mostly by non-users. While anyone can contribute to such discussions / designs, in my experience only those who are exposed to the reality of an implementation and have to work with an implementation really get a feeling for where things could be improved or should be done differently.
2. it's not a standard / there are not enough packages using this: for sure. But that is essentially the chicken-and-egg problem we're trying to solve here :).

We are just not sure that project is in a stable/final stage, nor that the community discussed too much about it (I saw quite some discussion in the first PR, but not much in the second one). We just want to avoid to adapt our code to something that might change soon.

That is always difficult, especially with new attempts at standardisation like this one. I cannot guarantee things won't need to change, but at least the changes will be (partly) driven by the experiences of using the set with this driver. That could potentially mean that any work-arounds / adaptations you make would essentially become a de facto standard, reducing the chance you'd have to change again.

One thing about that project (which should actually be a plus for us) is that it is shaped on the IIWA and its interface. It would be good to have feedback from users of other robots that have an impedance interface (to me unknown tbh).

yes, the heavy "IIWA-ness" of the msgs bother(s)(ed) me as well, see ros-industrial-attic/majorana#1 (comment) and ros-industrial-attic/majorana#1 (comment) fi.

But I do feel we should not let that get in the way of test-driving the set with different drivers, even if those all currently target the same hardware. Abstracting drivers behind a msg set is exactly one of the reasons the project exists, so that in itself already provides valuable information.

[marcoesposito1988]

Yes, you definitely have a couple of points there.

What about we start playing with it in a branch? We don't have necessarily to merge it into master right away, so we have the time to refine it without breaking the API too often.

[SalvoVirga]

I was already working on a refactoring of that service, so I wanted to wait to be done with that. We could definetly have an experimental branch that uses the messages in Majorana, probably after deadlines :P