Remove update loop filtering for publishing controller state

[jaron-l]

Background

Per the discussion in the working group meeting on Nov. 16th, all the controllers should not be filtering their update loops using a publisher period parameter. For example, the joint_trajectory_controller filers in the publish_state function using the associated parameter. Just remove the parameter and the check for it. Always publish the update when called.

Check the rest of the controllers and look for similar functionality to remove. It will always be in their update function or in a function called by the update function (like in the joint_trajectory_controller).

Instructions

Hi, this is a good-first-issue issue. This means we've worked to make it more legible to people who either haven't contributed to our codebase before, or even folks who haven't contributed to open source before.

We're interested in helping you take the first step, and can answer questions and help you out along the way. Note that we're especially interested in contributions from underrepresented groups!

We know that creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

If you have contributed before, consider leaving this PR for someone new, and looking through our general bug issues. Thanks!

🤔 What you will need to know.

Nothing. This issue is meant to welcome you to Open Source :) We are happy to walk you through the process.

📋 Step by Step

• [ ] 🙋 Claim this issue: Comment below. If someone else has claimed it, ask if they've opened a pull request already and if they're stuck -- maybe you can help them solve a problem or move it along!

• [ ] 🗄️ Create a local workspace for making your changes and testing following these instructions, for Step3 use "Download Source Code" section with these instructions.

• [ ] 🍴 Fork the repository using the handy button at the top of the repository page and clone it into ~/ws_ros2_control/src/ros-controls/ros2_controllers, here is a guide that you can follow (You will have to remove or empty the existing ros2_controllers folder before cloning your own fork)

• [ ] Checkout a new branch using git checkout -b <branch_name>

• [ ] 🤖 Apply pre-commit auto formatting, by running pip3 install pre-commit and running pre-commit install in the ros2_control repo.

• [ ] 💾 Commit and Push your changes

• [ ] 🔀 Start a Pull Request to request to merge your code into master. There are two ways that you can start a pull request:

1. If you are not familiar with GitHub or how to create a pull request, here is a guide you can follow on how GitHub works.

• [ ] 🏁 Done Ask in comments for a review :)

Is someone else already working on this?

🔗- We encourage contributors to link to the original issue in their pull request so all users can easily see if someone's already started on it.

👥- If someone seems stuck, offer them some help!

🤔❓ Questions?

Don’t hesitate to ask questions or to get help if you feel like you are getting stuck. For example leave a comment below! Furthermore, you find helpful resources here:

• ROS2 Control Contribution Guide
• ROS2 Tutorials
• ROS Answers

Good luck with your first issue!

[panxxhub]

now, like the 'joint_trajectory_controller', all the publish and trajectory sample/execution work are done at the update func ,which runs at a rt_thread, and shall we implement a new thread for the non-realtime staff?(a more complicate control node ,and a non-realtime scheduler, and add some func like update_nonrt in hardware_interface/controller_interface/resource_manager

[jaron-l]

now, like the 'joint_trajectory_controller', all the publish and trajectory sample/execution work are done at the update func ,which runs at a rt_thread, and shall we implement a new thread for the non-realtime staff?(a more complicate control node ,and a non-realtime scheduler, and add some func like update_nonrt in hardware_interface/controller_interface/resource_manager

I'm not sure I understand what you are asking. This won't require running a separate thread. This issue is just talking about removing one conditional branch from the update loop.

The update functions are not running on a RT thread, they run on non-realtime threads inside the executor that the controller was assigned to, just like most ROS2 nodes. The RT thread is run and handled by the realtime_tools package.

[tonynajjar]

Hi, could you explain the reason why we wouldn't want to publish some things at a different rate than the update() loop of the controller? I find it reasonable to want to publish some debugging state at a much lower frequency than the update() loop should run at. For example in the tricycle_controller, we publish the values sent to the hardware interface [here] purely for debugging purposes (https://github.com/ros-controls/ros2_controllers/blob/b72d0bbc97ea6cf4a1580c4bb734d7879350d2f2/tricycle_controller/src/tricycle_controller.cpp#L249); the publish rate of this publisher is currently not limited but I don't see a reason why it would not be. Maybe there is some insight that was discussed in the WG that I'm missing?

[jaron-l]

Hi, could you explain the reason why we wouldn't want to publish some things at a different rate than the update() loop of the controller? I find it reasonable to want to publish some debugging state at a much lower frequency than the update() loop should run at. For example in the tricycle_controller, we publish the values sent to the hardware interface [here] purely for debugging purposes (https://github.com/ros-controls/ros2_controllers/blob/b72d0bbc97ea6cf4a1580c4bb734d7879350d2f2/tricycle_controller/src/tricycle_controller.cpp#L249); the publish rate of this publisher is currently not limited but I don't see a reason why it would not be. Maybe there is some insight that was discussed in the WG that I'm missing?

This is issue is purely talking about removing a limit on the update loop itself. It is not affecting other things that are published.