I would like to hear some feedback from the community regarding a long lasting debate we have internally.
We develop electronics for robotics (motor driver, sensors, etc) for which we also develop the firmware, which then we interface to ROS for high-level logic. We are now finally moving to ROS2 and micro-ROS.
Being hardware developer, we like to embed the most we can, having hardware which natively supports ROS (indeed, we developed uROS-node back in 2013, which I think was the first ROS1 client running on microcontrollers).
While this to me seems by far the best approach for sensors for an easier integration (i.e., an IMU that publishes sensor_msgs/Imu messages), we are still not sure which is the best solution to interface with actuators.
Thinking of a mobile robot, I see different approaches:
- the robot hardware natively speaks ROS at robot level, subscribing /cmd_vel and publishing /odom, with the kinematics running on the hardware itself (like the kobuki robot)
- the robot hardware relies on a simplier, pheraps more efficient, protocol consuming joint velocity setpoints and producing joint status, using ros2_control for the hardware interface and ros2_controllers for the kinematics (like, I think, most robot platforms)
- the robot hardware natively speaks ROS at joint level, subscribing joint setpoints and publishing joint states, still using ros2_controllers for the kinematics
Approach 1. seems more efficient and real-time (control loops run on the MCU with an RTOS), but the embedded kinematics is much simpler than the one from ros2_controllers, without many nice to have features. We also need a software node on the PC subscribing /odom and publishing /tf.
Approach 2. seems very common, but what we don’t have the native ROS interface fostered by micro-ROS, which we love.
Approach 3. is a compromise between the two, with native ROS interface and advanced kinematics. In this case we can have both simple embedded kinematics (let’s say for teleop only) and advanced kinematics for autonomous navigation. But in the ros2_control hardware interface we need to publish and subscribe ROS topics, which seems uncommon and probably not the most efficient solution.
In the past we followed approach 1, while now we are following approach 3, but perhaps approach 2 is the right one, being the most common.
What do you think would be the best one, as micro-ROS users / developers?