[RFC] ROS2 Gem - Modular Manipulation Components Architecture #54
Description
Summary
This RFC thus proposes the introduction of an intermediary lower-level manipulation API and Bus, separating the existing Manipulation logic into two different components:
- one responsible for the dynamics, and
- the other for the control of manipulators in O3DE.
What is the relevance of this feature?
To support the simulation of robotic manipulators within O3DE, o3de/o3de-extras#161 is introducing a high-level API for interfacing with the ROS2 / MoveIt ecosystem based on the design described in RobotecAI/o3de-ros2-gem#226 on the level of ROS2 JointTrajectoryMessages.
While this API is quite suitable for application-level (e.g. pick & place tasks) work, it does not allow for interfacing (and thus development and testing) of lower-level control methods and applications.
Introducing an intermediary abstraction layer would allow for manipulator control to be carried out in different ways and simplify the development and testing of future higher-level controllers/interfaces.
Feature design description
The current design exclusively exposes control of manipulators on the level of JointTrajectoryControl messages as illustrated in this graphic:
Implementing this RFC would introduce an abstraction layer for the low-level control of manipulators and other kinematic chains enabling effort/velocity-based control through an EventBus besides the currrently implemented high-level TrajectoryControl API. This a) enables the development and testing of low-level control methods in O3DE and b) make it easier to expose additional high-level controllers within O3DE for application developers by reusing the existing low-level API.
Technical design description
To realize this abstraction, the logic already employed by the Vehicle Dynamics & Control module should be adopted and adapted to manipulation.
Subsequently, two new components would be implemented inside the ROS2 Gem in order to provide useful interconnection with external ROS2 packages.
The ManipulatorControllerComponent would handle the Control and the ManipulatorModelComponent the Dynamics of manipulation.
Manipulator Controller Component
High Level Control
In order to differentiate between different inputs sent to the controller, the ManipulatorControllerComponent could have a switch between:
- a ROS2 Subscription handler for a unique target joints state (e.g. given by the JointJog ROS2 msg)
- a ROS2 Server handler for managing the execution of a trajectory (useful when dealing with some common ROS2 libraries as MoveIt
Low Level Control
In order to tackle different Control algorithm (e.g. PID, Feed-Forward, ...) the ManipulatorControllerComponent could offer different implementation of some base member functions to provide the command.
Manipulator Model Component
Physical properties
A ManipulatorModelComponent class could be the base Class for some specific Manipulator model designs such as:
- Robotic arms (Revolute Joints)
- Parallel manipulators (Prismatic joints)
Design
Moreover the Dynamics could be moved by different types of PhysX API requests (e.g. the Joint method, the RigidBody method and a potential articulation method.
How will this be work within the O3DE project?
- This new logic will work exactly as the one depicted here conceived for Vehicles simulation.
Development
My strategy consists of starting with the development of the ManipulatorModelComponent, providing a basic model for robotic arms with only Hinge Joints. From that I will keep on developing the ManipulatorControllerComponent on top of the existing one found in this PR.
Questions/Suggestions
Any comments or doubts about this draft are encouraged. Once agreed with the main structure, I would like to receive feedbacks especially on the the different Manipulators design concepts and if it makes sense building different models according to different joint types.