High CPU load due to joint state broadcaster

[firesurfer]

Describe the bug

I am currently looking into the issue why our ros2control node is consuming 100% cpu load.
For testing purposes I disabled all loaded controllers one by one. As expected the cpu drops a bit for each controller. But for the joint state broadcaster this was rather extreme. I see a change in cpu load for node of ~15-20%.
This is not the case for other controllers that publish messages at the same rate of 500Hz.

We have a rather large amount of joints in our system: 34.

Expected behavior

I would expect that such a simple controller shouldn't consume that much cpu power.

Environment (please complete the following information):

• OS: ubuntu 24.04
• Version Jazzy - 4.16.0

Additional context

When taking a look at the code I would guess at the moment three places that could result in a higher cpu load:

1. there are rather many operations on the map_interface_to_joint_state_ -> but unordered_map should be fast enough
2. mutex operation in the RT publisher
3. Reading the values from the state interfaces -> Not sure if there is any synchronization happening ?

[christophfroehlich]

Strange. To narrow that down, I'd comment the different publishers in the update() method and see if the publishers or the state_interface.get_value() is causing this behavior..

[saikishor]

I highly doubt that it is caused due to the handles. In a synchronous system, mutexes shouldn't do anything. So, as @christophfroehlich suggested try to check with the publishers and see.

[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.

[firesurfer]

Sorry for my very late feedback.
I just spent some additional thoughts on this issue and I think in our case it is due to the existing feedback loops in the system that kind of starve/stop when I stop publishing joint states - which explains why the system load drops that much.

I will therefore close this issue.

[jordan-palacios]

We are currently having issues with this broadcaster too. In our case I think simple due to the sheer amount of state interfaces our setup has: ~550.

After a brief look, the broadcaster could use some optimization. There a lot of map lookups on the update() function that could be cached. I'll prepare a PR.

[saikishor]

We are currently having issues with this broadcaster too. In our case I think simple due to the sheer amount of state interfaces our setup has: ~550.

After a brief look, the broadcaster could use some optimization. There a lot of map lookups on the update() function that could be cached. I'll prepare a PR.

Thank you @jordan-palacios