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.