search

ros-controls / ros2_control

Generic and simple controls framework for ROS 2
https://control.ros.org
Apache License 2.0
515 stars 305 forks source link

How to implement complex, realtime updated filters as intermediary information streams between sensors and controllers #1796

Open lcbw opened 1 month ago

lcbw commented 1 month ago

Is your feature request related to a problem? Please describe. In ROS1, when my team needed to use a noisy sensor like the default UR e-series FT sensor, we'd filter the sensor data through a simple node that published to some topic '/filtered_wrench' which we could use for our force-based-controller inputs. Force-based controllers were initialized with some '/force_sensor_wrench' topic to then listen to, which we could remap to our '/filtered_wrench'.

This topic-based approach also enabled us to impose offsets on sensor data. We are looking to impose an offset on FT sensor data used for admittance control in ROS2, in the new native ROS2 control structure.

Describe the solution you'd like We believe this should be possible currently through the capability to expose and share hardware and state interfaces between broadcasters and controllers inheriting from the chained controllers class. If a simpler solution is available, all the better.

Describe alternatives you've considered We've tried utilizing the exponential filter present in the ros2_controllers admittance controller to process the FT noise but this does not meet our need to be able to impose an offset on the force torque data.

Additional context This request is based in work on the following platforms and software versions:

ROS2 | Humble | Ubuntu 22.04 | UR10e | Polyscope 5.11

bmagyar commented 1 month ago

On first read it sounds like you are looking for https://github.com/ros-controls/ros2_controllers/pull/1215

lcbw commented 1 month ago

On first read it sounds like you are looking for ros-controls/ros2_controllers#1215 Thank you.

Does the review team intend on merging this PR? If so, is there a timeline on the review, fixes, and merge?

This PR is close to what I'm looking for, and will do the trick for now once I get it building in humble, which it currently is not. An ideal solution would enable me to read both offset and non-offset sensor data in separate streams.

saikishor commented 1 month ago

@lcbw with that you can start one broadcast let with offsets and another one without any offsets, so you have two data streams as you wanted ;)