Add jerk to the robot model

[AndyZe]

Now that we have some MoveIt capabilities that can process jerk limits, I think we should add jerk limits to the robot model. This simply adds the jerk parameters to joint_limits.yaml and adds the parsing code to robot_model_loader.cpp.

Fixes #574

[nbbrooks]

lgtm

[JafarAbdi]

I think we should also update computeVariableBoundsMsg and operator<<(std::ostream& out, const VariableBounds& b) to include the new fields

I released moveit_msgs an hour ago but we need to add it to the .repos file until it gets synced to the Debians

[henningkayser]

Changes look good to me. Let's hold off on merging this until the MoveIt release is done.

[henningkayser]

Could you add jerk to the RobotTrajectory::print() function (#715) right below efforts? LGTM after that

[codecov]

Codecov Report

Merging #683 (f7289dd) into main (6141e3a) will decrease coverage by 3.78%.
The diff coverage is 25.00%.

❗ Current head f7289dd differs from pull request most recent head 65b2dad. Consider uploading reports for the commit 65b2dad to get more accurate results

@@            Coverage Diff             @@
##             main     #683      +/-   ##
==========================================
- Coverage   57.92%   54.15%   -3.77%     
==========================================
  Files         310      195     -115     
  Lines       26091    20343    -5748     
==========================================
- Hits        15111    11015    -4096     
+ Misses      10980     9328    -1652     

Impacted Files	Coverage Δ
moveit_core/robot_state/src/robot_state.cpp	32.72% <0.00%> (-14.65%)	⬇️
...eit_core/robot_trajectory/src/robot_trajectory.cpp	23.16% <20.00%> (-41.29%)	⬇️
moveit_core/robot_model/src/joint_model.cpp	51.24% <36.37%> (-7.58%)	⬇️
...bot_state/include/moveit/robot_state/robot_state.h	89.12% <50.00%> (-1.15%)	⬇️
...ning/robot_model_loader/src/robot_model_loader.cpp	75.00% <50.00%> (-5.62%)	⬇️
...bot_model/include/moveit/robot_model/joint_model.h	82.86% <100.00%> (+0.92%)	⬆️
...rajectory_processing/src/ruckig_traj_smoothing.cpp	0.00% <0.00%> (-80.61%)	⬇️
...ace/include/moveit/ompl_interface/ompl_interface.h	0.00% <0.00%> (-66.66%)	⬇️
.../planning_scene_monitor/src/trajectory_monitor.cpp	0.00% <0.00%> (-66.07%)	⬇️
...or/src/occupancy_map_monitor_middleware_handle.cpp	0.00% <0.00%> (-48.97%)	⬇️
... and 268 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6141e3a...65b2dad. Read the comment docs.

[v4hn]

- acceleration_[robot_model_->getVariableIndex(it.first)] = it.second; + effort_[robot_model_->getVariableIndex(it.first)] = it.second; A bonus bug fix!

Nice. Luckily not an actual bug because until now the two pointers are assigned to the same value. :)

[AndyZe]

I see that has_acceleration_ and has_effort_ were mutually exclusive before. I'm not sure why -- I guess it was a hacky way to ensure joints were only controlled in one mode at a time. (torque directly causes acceleration)

I'll plan to leave it as it was.

[v4hn]

I see that `has_acceleration_` and `has_effort_` were mutually exclusive before. I'm not sure why

I don't know for sure, but I believe this was done to reduce the memory footprint of the class. I'm not convinced it's an issue these days, but then again manipulation piplines such as MTC instantiates a lot of instances. Allocating effort and jerk by default for [a bimanual shadow hand setup](https://www.youtube.com/watch?v=rEoq7DMgaEc) would add `(6+23)*2 * 2 * 8 = 928` bytes for each instance. As long as the memory is not accessed you might rely on virtual memory to not waste RAM, but then again I still think it's bad design. Also I've never seen anyone use the effort fields myself, so it might be quite some deadweight. Planning a geometric trajectory for effort control ahead of time is probably quite meaningless in practice anyway. I would expect it to be most useful for *recordings* of actual executions, but then I would not want to give up acceleration in a recording either. Jerk will also remain a special case for some time I guess. I'm wondering whether it would be better to reallocate memory if effort or jerk are used or maybe allocate these fields separately from the rest of the values as needed. This needs thorough profiling though, possibly in an MTC setup or some other complex pipeline ***@***.*** might be pretty interested as he also maintains a big parallel planning system - in ROS though).

[AndyZe]

@v4hn thanks for a critical review that looks at the bigger picture.

I only modified the RobotState so I could add jerk to RobotTrajectory::print() that Henning asked for. Well, that seems like not a very good reason to add so much overhead, like you said. I'll go ahead and revert the commit that modified RobotState.

[mergify]

This pull request is in conflict. Could you fix it @AndyZe?

[mergify]

This pull request is in conflict. Could you fix it @AndyZe?