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.

[christophfroehlich]

This is now rather application specific, but why you don't send a longer horizon than update period of the topic?
However, trajectory replacement in JTC is not fully implemented yet.

[xibeisiber]

rather application specific

Yes, the desired application scenario is that in the trajectory planning program there is a RL/IL control policy which needs the feedback of the robot, and outputs interpolated points.

but why you don't send a longer horizon than update period of the topic?

on one side, this will result in the accumulation of trajectory snippets in the controller. I can add a snippet buffer, but the number of accumulated snippets will increase as long as the trajectory planning program doesn't stop.

on the other side, I don't want to cause too much delay between the trajectory planning program and the actual robot state.

maybe one possible solution is in the controller to give a feedback of size of the snippets buffer or the interp points buffer. As long as the buffer size is low, let the trajectory planning program send faster, otherwise, slower.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.