Unable to configure filters

[OscarMrZ]

Describe the bug
I'm trying to load the GravityCompensation compensation filter into my code. I'm able to load the plugin correctly, both using the FilterChain and standalone (calling getUniqueInstance directly), and it seems all the parameters are correctly set. When I try to configure (either the chain or the filter directly), I get a segmentation fault.

void configure_filter_directly()
{
   pluginlib::UniquePtr<filters::FilterBase<geometry_msgs::msg::WrenchStamped>> loaded_filter;

   loaded_filter->configure(
      "sensor_filter_chain.filter1", "gravity_compensation",
      this->get_node_logging_interface(), this->get_node_parameters_interface());
}

Debugging the code with gdb, it seems the issue is coming from filter_base.hpp:105. I wrapped it into two silly prints just to be sure and it seems to be the case:

std::cout << "Calling specific configuring" << std::endl;
configured_ = configure();
std::cout << "called specific configuring" << std::endl;

It never gets to the second print.

This is the stacktrace from gdb

─── Stack ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[0] from 0x0000000000000000
[1] from 0x00005555555634ce in filters::FilterBase<geometry_msgs::msg::WrenchStamped_<std::allocator<void> > >::configure(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<rclcpp::node_interfaces::NodeLoggingInterface> const&, std::shared_ptr<rclcpp::node_interfaces::NodeParametersInterface> const&)+734 at /home/user/exchange/ws/ft_calibration/src/filters/include/filters/filter_base.hpp:106
[2] from 0x000055555556d953 in DummyFilterLoader::configure_filter_directly()+867 at /home/user/exchange/ws/ft_calibration/src/dummy_filter_loader/src/filter_loader.cpp:45
[3] from 0x000055555555f36c in main(int, char**)+188 at /home/user/exchange/ws/ft_calibration/src/dummy_filter_loader/src/filter_loader.cpp:60

I also checked with the control_filters/LowPassFilterDouble and the issue is <the same.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://github.com/OscarMrZ/dummy_filter_loader/tree/main
2. Clone into a workspace
3. Compile normally with colcon
4. ros2 run dummy_filter_loader dummy_filter_loader --ros-args --params-file src/dummy_filter_loader/params/params.yaml
5. See the error

GravityCompensation constructor called, this=0x5d492f566280
Calling specific configuring
Stack trace (most recent call last):
#3    Object "", at 0, in
#2    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7582f298c51f, in
#1    Object "/opt/pal/alum/lib/libbackward.so", at 0x7582f3044372, in backward::SignalHandling::sig_handler(int, siginfo_t*, void*)
#0    Object "/opt/pal/alum/lib/libbackward.so", at 0x7582f3043d11, in
Segmentation fault (Address not mapped to object [(nil)])
[ros2run]: Segmentation fault

Expected behavior
The filter is initialized with its parameters and it's ready to use (aka update can be called on it with data)

Environment (please complete the following information):

• OS: Ubuntu 22.04
• Version Humble/Rolling
• I'm using Humble but all the ROS 2 control packages are targeting the rolling version. This is also the case for control_toolbox, so technically I'm using rolling.

Additional context
I'm exploring this to enable the gravity filter in the force torque sensor, continuing this PR

[christophfroehlich]

This is strange, as we have tests for the configure

control_toolbox/control_toolbox/test/control_filters/test_gravity_compensation.cpp

Lines 97 to 99 in 0336ef4

	ASSERT_TRUE(filter_->configure(
	"", "TestGravityCompensation", node_->get_node_logging_interface(),
	node_->get_node_parameters_interface()));

I think that your code for loading the filter is not correct, better try

control_toolbox/control_toolbox/test/control_filters/test_load_gravity_compensation.cpp

Lines 28 to 41 in 0336ef4

	pluginlib::ClassLoader<filters::FilterBase<geometry_msgs::msg::WrenchStamped>> filter_loader(
	"filters", "filters::FilterBase<geometry_msgs::msg::WrenchStamped>");
	std::shared_ptr<filters::FilterBase<geometry_msgs::msg::WrenchStamped>> filter;
	auto available_classes = filter_loader.getDeclaredClasses();
	std::stringstream sstr;
	sstr << "available filters:" << std::endl;
	for (const auto & available_class : available_classes)
	{
	sstr << " " << available_class << std::endl;
	}
	std::string filter_type = "control_filters/GravityCompensationWrench";
	ASSERT_TRUE(filter_loader.isClassAvailable(filter_type)) << sstr.str();
	ASSERT_NO_THROW(filter = filter_loader.createSharedInstance(filter_type));

Btw https://github.com/OscarMrZ/dummy_filter_loader/tree/main is an empty repo ;)

[OscarMrZ]

Hello @christophfroehlich!

Thanks a lot for your response! Sorry for the empty repo, I was checking how to reproduce the issue and it took me longer that I expected. The code should be uploaded now.

I still experience the issue, but it seems more nuanced than I previously thought:

1. The uploaded code should crash when you run it with ros2 run dummy_filter_loader dummy_filter_loader --ros-args --params-file src/dummy_filter_loader/params/params.yaml, as the override in the derived class of the virtual function cannot be found in the loaded shared instance.
2. If you uncomment the configure_filter_directly function from my class, and you call it (so it doesn't get optimized out), it should work (I discovered this completely by chance when trying to load the filter directly). This is because I am effectively directly linking against the header #include "control_toolbox/control_filters/gravity_compensation.hpp" (ament_auto takes care of it), and somehow this makes the vtable accessible in the shared instance when previously it was not. In this case, the derived configure() call executes properly.

I checked the test you mentioned, and I guess it works because you are also linking against the gravity compensation lib. However, afaik, this wouldn't be the case on a controller, which aligns with the behavior I'm seeing in my experiments with the FT broadcaster.

It looks like the issue may have something to do with the visibility of the vtable of template abstract classes when using plugins.

Looking forward to hear if you can reproduce the issue.

Thanks a lot!

[OscarMrZ]

Hello @christophfroehlich,

I was able to narrow down the issue; it happens in two situations, one of them very specific to my environment:

1. If the ros-humble-filters package is installed, after recompiling the control-toolbox, I'll get the aforementioned runtime error. This happens even when the filters package with the latest version is deployed in my workspace. Sorry for this, I failed to notice before, as this package was being installed as a dependency of the simulation.
2. When I compile with debug symbols, using the following command: colcon build --symlink-install --parallel-workers 8 --mixin compile-commands --cmake-args -DCMAKE_BUILD_TYPE=RelWithDebInfo.

As this are quite specific for my setup, I would close the issue if it's okey with you.

Thanks a lot!

[christophfroehlich]

ad 1: I can't imagine now what is the issue here, if there was no API break (very unlikely).
as 2: I cannot reproduce your issue on Ubuntu noble, rolling, compiled filters from source:

$ (cd src && git clone https://github.com/OscarMrZ/dummy_filter_loader.git)
$ colcon build --symlink-install --parallel-workers 8 --mixin compile-commands --cmake-args -DCMAKE_BUILD_TYPE=RelWithDebInfo --packages-select dummy_filter_loader
$ source install/setup.bash
$ ros2 run dummy_filter_loader dummy_filter_loader --ros-args --params-file src/dummy_filter_loader/params/params.yaml
Configuring filter chain
Configuring filter directly as a plugin (shared ptr)
available filters:
  control_filters/GravityCompensationWrench
  control_filters/LowPassFilterWrench
Configuring filter directly as a plugin (unique ptr)

I see that your code is not compatible with the humble version of control_toolbox, which combination did you use then? Rolling version compiled from source on jammy+humble also works for me

So it seems that this is really specific to your environment, and I close this issue. If you have more information, keep us updated