Revision history [back]

Hi,

Thanks for your question. In the past, I addressed this issue using 3. approach. It provides you with most flexibility to control execution behavior. I implemented this approach for Force-Torque Sensors in ROS1 where the sensors are running at 800 Hz and the control loop at 200 Hz (because of robot). I don't guarantee that this implementation is real-time safe, but it can give you an idea about the architecture.

Maybe you would like to start with a minimal example? If so, RRbot from the ros2_control_demos package would be perfect to test the concept, especially when using an additional executor or internal thread.

For the real-time barrier, RealtimeBuffer from realtime_tools repo could be helpful.

Hi,

Thanks for your question. In the past, I addressed this issue using 3. approach. It provides you with most flexibility to control execution behavior. I implemented this approach for Force-Torque Sensors in ROS1 where the sensors are running at 800 Hz and the control loop at 200 Hz (because of robot). The problem with FTS is other way around, but the solution is the same. I don't guarantee that this implementation is real-time safe, but it can give you an idea about the architecture.

Nevertheless, you probably don't want to run your CM at faster rate than you can talk to your HW.

Maybe you would like to start with a minimal example? If so, RRbot from the ros2_control_demos package would be perfect to test the concept, especially when using an additional executor or internal thread.

For the real-time barrier, RealtimeBuffer from realtime_tools repo could be helpful. helpful.