-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commanding rate issue #62
Comments
I guess this depends on what is being launched. If the hardware interface is launched, then the control rate is set by the controller manager, e.g. https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/d1e70a7a1160ea2d3f29203b6ab83e2919292c29/lbr_bringup/config/lbr_controllers.yml#L3 Could you do a minimal bringup, ie launch
and report back the control rate? Think all these issues will be resolved once the bringup is being re-written. |
I use the following.
The admittance node is publishing on |
indeed solves the issue. Reminder to update the readme https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/tree/foxy/lbr_examples#admittance-control, once bringup was re-written |
I have noticed some strange issues with publishing commands on the real robot. I am running the admittance controller example (I have tested with both the current Kinpy implementation and optas implementation in #53 in order to verify the issue is not with optas - I see the same behaviour with both versions).
When I run the example and check the hz of
/lbr_command
, i seeHowever, I have verified in the admittance controller node script: (i) 100. commanding rate is being passed as the parameter, and the timer callback is running at 100hz (just by taking the time stamps between each successive call to the callback method.
The example isn't that clean anyway and I wonder if this has something to do with that.
@mhubii do you have any thoughts?
The text was updated successfully, but these errors were encountered: