Request for Feedback: New High Level API

MoveIt
1

A number of us have been debating and prototyping what a new high level API for MoveIt would look like. Our primary motivation is improved performance and fewer layers of abstraction.

This new high level interface, which we are code naming moveit_cpp, would be a unified C++ API that does not require the use of ROS Actions, Services, and Messages to access the core MoveIt functionality.

This new API would be an alternative (not a full replacement) for the existing MoveGroup API.

Proposed Design Goals:

  • No ROS abstraction (messages, services, actions) from the actual planners and IK solvers
  • Support for advanced tasks via access to lower levels of pipeline
  • Faster software development time for industrial, non-academic projects
  • Possibility to support high performance planning
  • Maintain multi-arm / multi-group support, do not over-optimize for single arm case

Have any feedback, suggestions, or concerns? Please share!

4 Likes
2

Our primary motivation is improved performance and fewer layers of abstraction.

I like the idea of fewer layers. I personally found it confusing to have multiple ways of interfacing with the MoveGroup object and understand which approach to use when I was first starting to use MoveIt.

This new high level interface, which we are code naming moveit_cpp , would be a unified C++ API that does not require the use of ROS Actions, Services, and Messages to access the core MoveIt functionality.

Would this effectively be the same as removing the Actions and Services available in the current MoveGroup implementation? Do these Action/Service servers take a large amount of overhead on the host? Are there other downsides to having these ROS interfaces available?

  • No ROS abstraction (messages, services, actions) from the actual planners and IK solvers

I assume the new API will still rely on plugins to support customization? Will this new interface have ROS completely removed? What would you replace the ROS message objects with? What is the downside of using ROS message objects here?

  • Support for advanced tasks via access to lower levels of pipeline

Do you have any use case examples? What portion of the lower levels can we not access via MoveGroup?

  • Faster software development time for industrial, non-academic projects

How would removing the ROS interface make the development faster?

3

Thanks for the many questions, @Marq_Razz

Would this effectively be the same as removing the Actions and Services available in the current MoveGroup implementation?

Yes, but we want to keep the current implementation as an option, also.

Do these Action/Service servers take a large amount of overhead on the host?

They add latency that is very problematic for any level of realtime control. Of course, this issue may go away on its own with ROS 2’s realtime support, but that is still questionable.

Are there other downsides to having these ROS interfaces available?

Again, we want to maintain those interfaces also, for those who desire it.

I assume the new API will still rely on plugins to support customization?

No, we’re moving away from the capabilities / plugins approach. MoveIt already has tons of lower level plugins for each component, I don’t see a need to wrap plugins with more plugins.

Will this new interface have ROS completely removed?

No, it will still have dependencies on ROS

What would you replace the ROS message objects with?

This is undecided and under debate. For now we’re thinking keeping a very similar API that heavily relies on moveit_msgs / etc. But those message types won’t ever be published.

Long term, we might just want to use lower level types like Eigen::Isometry3d and moveit_core::RobotState.

What is the downside of using ROS message objects here?

I’m not 100% sure what their overhead is… I don’t think serialization is happening until they are published.

Do you have any use case examples?

Anything involving closed loop control

What portion of the lower levels can we not access via MoveGroup?

Basically all of it. You are currently constrained to the data flow through moveit_msgs

How would removing the ROS interface make the development faster?

Less layers to poke through whenever you want to work on new features or improvements.

Whew, that was a lot.

1 Like
4

Whew, that was a lot.

Thanks for entertaining all of my questions @davetcoleman!! I know I don’t have a complete understanding of how MoveIt is connected together and I appreciate you engaging the community and letting us have a say in the direction it is going.

I guess the only other question I have is how much work do you think this new interface would take? Would it delay the timeline of getting a fully functioning MoveIt2 interface?