Renamed "command_configuration" to "command" topic for lwr_controllers

[marcoesposito1988]

Next I would unify the API to accept a cartesian position as geometry_msgs::Pose. Is there any particular reason why some controllers take a PoseRPY?

Of course the multi-task algorithms should stay as they are since there is no standard algorithm.

[carlosjoserg]

Next I would unify the API to accept a cartesian position as geometry_msgs::Pose.

That would be the right thing to do, yes.

Is there any particular reason why some controllers take a PoseRPY?

I thought that's what you meant by switching to geometry_msgs::Pose

Of course the multi-task algorithms should stay as they are since there is no standard algorithm.

Yes, but still, the command description is not easy to understand, perhaps using something like

string[] link_name 
geometry_msgs::Pose[] tasks 

would be more intuitive.

[enricocorvaglia]

Hi guys! I see you are doing good. Regarding the input of controllers, I created a custom msg PoseRPY since in my experiments I needed to pass cartesian orientation in a "human readable" form, that's why I chose RPY instead of Quaternions representation (present in geometry_msgs::Pose). The same reason stands behind the multi-task msgs. Of course now you can switch to geometry_msgs::Pose if it fits better your needs.

Best Enrico