running forward command controller at 1000Hz

[xibeisiber]

Hi, I implemented a hardware interface for a real robot with interpolation period 1ms, and want to use a forward command controller so that my trajectory planning program can send points to /arm_forward_position_controller/commands via ros2 topic.

Since the robot is running at nterpolation period 1ms, I need to publish trajectory points data to the topic at 1000Hz. But it seems the subscriber in forward command controller will lose some point, causing over-velocity or over-acc alarm.

Will a RT system and realtime_tools/realtime_publisher help in this case and to which extent?

Probably some other controller instead of forward command controller will behave better, but my trajectory planning program sometimes need to plan online, such as a policy network in reinforcement learning which needs realtime robot states.

Thanks!

[christophfroehlich]

Are you sure that the issue doesn't come from the middleware and jitter in the topic update rate? 1kHz is rather high for ROS topics, and a RT system might not fix that. Have you tried other RMW implementations?

Is the joint_trajectory_controller not feasible for your project? So that you can send a set of trajectory points at once, and the controller does the interpolation?

[xibeisiber]

Hi, the reason may include the jitter in topic update rate and also the non-realtime of update() in controller.

I wrote a controller similar to joint trajectory controller to receive a trajectory snippet with n points every time. Such the trajectory planning program can send these snippets at a much lower frequency.

The controller and the hardware interface still run at 1000Hz. I tested on a RT ubuntu system, it's much stable.

But there are still risks, if the snippet msg is received in the controller even 50microsecond later than the update() is called, the controller will send the previous point to hardware_interface, causing over-acc error.