Skip to content
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

Franka robot state broadcaster frequently fails to update #94

Open
scastro-bdai opened this issue Jan 22, 2025 · 2 comments
Open

Franka robot state broadcaster frequently fails to update #94

scastro-bdai opened this issue Jan 22, 2025 · 2 comments
Assignees

Comments

@scastro-bdai
Copy link

We've been using franka_ros2 for a while -- in the most recent Humble release of ros2_control, ros-controls/ros2_control#1969 added some error logs when a controller fails to update.

[controller_manager]: The update call of the following controller returned an error: 'franka_robot_state_broadcaster'

This has exposed a potential issue in the franka_robot_state_broadcaster, since this is now spamming the new error log above to our console; however, the controller performance remains the same. It's likely that this issue has been around for a while, but it simply wasn't being logged before.

We've isolated the failure to this line:

if (realtime_franka_state_publisher && realtime_franka_state_publisher->trylock()) {

Any suggestions on what to look at, or ideas on what may be going on? Thanks!

@bjin-bdai
Copy link

bjin-bdai commented Jan 22, 2025

I'll add that the control flow logic after realtime_franka_state_publisher->trylock() seems slightly flawed. realtime_franka_state_publisher is a realtime_tools:RealtimePublisher object from the ros2 realtime tool box. The try_lock implementation is ultimately using std::mutex.try_lock() function, which is designed intentionally to fail spuriously sometimes for the purpose of runtime optimization (or it might actually be a valid failure because the publisher thread is owning the lock).

Ultimately I think this is a problem with ROS 2 realtime_toolbox, but knowing this is how it's implemented means that the franka_robot_state_broadcaster ideally has alternative logic when the try_lock() fails (i.e. add some kind of consecutive failure threshold before returning controller_interface::return_type::ERROR;), or just not use the realtime tools all together

Update: clarified mutex comment

@BarisYazici
Copy link
Collaborator

I noticed an issue with this when I was writing the unit-tests for the franka_robot_state_broadcaster. https://github.com/frankaemika/franka_ros2/blob/humble/franka_robot_state_broadcaster/test/test_franka_robot_state_broadcaster.cpp#L82
I kept the test as disabled.
Without looking in detail, this issues might be related.

@Smith-JackSmith Smith-JackSmith self-assigned this Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants