Delay in Velocity Commands Using ROS2_control

[osama-z-salah]

System Setup:

Framework: ROS2_control Motors: Industrial-grade wheel motors Update Rate: 100 Hz Relevant Topics: Commanded velocities: /Nanos100_3/cmd_vel_nav/linear/x Actual velocities: /Nanos100_3/diffbot_base_controller/odom/twist/twist/linear/x Observed Delay:

The attached plot shows the commanded and actual velocities over time. average delay of 1 seconds

Expected Performance:

Given the industrial-grade motors and high update rate, the delay is expected to be minimal. Is the observed delay within acceptable limits for similar systems? Are there any suggestions for improving the performance?

[christophfroehlich]

I can't imagine that the reason is the ros2_control stack. how do you interface the motor drivers? of which type are they? what sensor do you use? any other possibilities to test the motor controller (without ROS?).

[osama-z-salah]

@christophfroehlich thanks for your reply, the motor drivers use the CANopen protocol, so I have created a custom hardware interface. Since this is my first attempt, I don't have a benchmark to compare against. Is this level of delay typical for an industrial-grade robot, or is there room for improvement? If so, where could the improvements be made? I am currently using a standard Ubuntu kernel. I have not tried the real-time kernel—will it significantly improve performance, or will the improvement be minor, suggesting I should look for other solutions?

[saikishor]

Hello!

Can you compile your code with the Release flag and then try it again. The default compilation of the colcon build is sometimes not that good. Once this is done, please take the stats and let us know. In our case, we have seen an improvement in our Hardware Component by 10x.

Thank you!

[christophfroehlich]

For communication only, this "delay" is too large. Why are you so sure that this lies on the communication? This just can be the closed-loop dynamics of your motor controller + motor + inertia of the wheel (you haven't disclosed the type of motor + sensor + motor control strategy), or even the result of the velocity estimation from your sensor. I'd suggest to create a setup without any comm overlay, maybe you can use a simple CAN shield or if you want to invest a bit, use something like this one. Then you can compare the delay/dynamics directly on the CAN interface to be sure that this is not related to the communication stack.

[osama-z-salah]

@christophfroehlich here is the Key Specifications: Motor and Driver: Integrated servo motor and wheel design. Built-in 17-bit absolute encoder. Rated voltage: 24V. Rated output power: 300W. Rated torque: 15 Nm. Peak torque: 23 Nm. Rated speed: 100 rpm. Maximum speed: 250 rpm. Encoder type: 17-bit absolute magnetic encoder. Communication protocol: CANopen.

Control and Feedback: High response speed and high positioning accuracy. Built-in temperature sensor and various protection mechanisms. Low-speed stability (down to 0.1 rpm).

[christophfroehlich]

Looks promising, but this is still mostly marketing speech :grinning:

[osama-z-salah]

@christophfroehlich, thank you for your help. To close this issue, could you please suggest where I should look for improvements in general?

[saikishor]

@christophfroehlich, thank you for your help. To close this issue, could you please suggest where I should look for improvements in general?

@osama-z-salah can you try the compilation with Release and let us know the stats? Other thing that would help is the period you are receiving in the HW interface, this way you can check if something is taking longer or not.

Thank you.