Added vel and acc scaling to GetCartesianPath.srv on Humble

[liamcarlos]

I'm adding these to match a pull request on moveit/moveit2 to add velocity and acceleration control to cartesian path planning on the Humble branch.

I found this portion on the Iron branch here but couldn't find references to them in moveit/moveit2 so I just left them out if anybody's wondering.

# Maximum cartesian speed for the given link.
# If max_cartesian_speed <= 0 the trajectory is not modified. string cartesian_speed_limited_link
float64 max_cartesian_speed # m/s

[liamcarlos]

Hey @rhaschke can we merge this to the humble branch so humble users can use the velocity and acceleration scaling options for cartesian path planning? This coincides with this pr #3051, but merging this one wouldn't break anything if done first right?

[rhaschke]

I just comment on ROS2 and leave merging to other maintainers: @sjahr, @sea-bass.
Having said this, I'm not sure they accept message changes in Humble as that breaks existing API.

[liamcarlos]

@rhaschke These changes wouldn't break the current API since these new variables aren't being used at all on the Humble branch for Cartesian Planning. If the pull request I put up here (#3051) got merged first, then things would break. Regardless, Iron has all of these changes I'm suggesting and has already passed its EOL, so I don't understand why these changes can't be made for Humble which has 2 more years until EOL. Shouldn't the Humble branch still be maintained?

[sea-bass]

Maintained as in bug fixes? Yes.

But modifying function interfaces and message types generally is not done on non-Rolling branches

[liamcarlos]

@sea-bass This is a bug. Set scaled velocity and acceleration would work if they were added to this srv file and implemented in cartesian_path_service_capability.cpp and move_group_interface.cpp Otherwise, Humble users have no control over the speed and acceleration of their arms using cartesian planning.. Is there any good reason for omitting this control?

[mikeferguson]

Changing message definitions also changes the checksum on them - so if a sender and receiver are not both on the exact same set of messages, they can't actually communicate (and so the effect is very similar to API/ABI changes).

MoveIt has an official policy on API/ABI stability that was adopted after quite a bit of discussion at developer meetings - you can find it here: https://moveit.ai/moveit%202/ros/2023/05/31/balancing-stability-and-development.html - it also has some details about how to use the main branch on older distributions.

[liamcarlos]

Hey @mikeferguson I've tried using the main branch with humble as suggested here but I'm getting an error about an undefined reference in the libmoveit_warehouse library when I try to build my move group action server. Have you guys seen this issue before?

/usr/bin/ld: /opt/ros/humble/lib/libmoveit_warehouse.so.2.7.4: undefined reference to `warehouse_ros::DatabaseLoader::~DatabaseLoader()'

[mikeferguson]

/usr/bin/ld: /opt/ros/humble/lib/libmoveit_warehouse.so.2.7.4: undefined reference to `warehouse_ros::DatabaseLoader::~DatabaseLoader()'

warehouse_ros is a separate package - I'm guessing you need to update your installed Debian (you shouldn't need to build the package from source, because it's not listed in our moveit2.repos file, and our CI successfully building the main branch on humble with only the moveit2.repos built from source)

[mikeferguson]

Also, because this does change API, it can't be merged to humble - so I'm going to close it

[liamcarlos]

@mikeferguson Hey Mike, I'm still having this problem with libmoveit_warehouse.so.2.7.4 including an undefined reference to `warehouse_ros::DatabaseLoader::~DatabaseLoader()' Could this be that warehouse_ros has added this reference in version later than Humble?