ROS 2 support for in-place filter updates

[Maik13579]

Hi,

I am currently writing my own filter framework. The main differences are that my filters are lifecycle components, and data exchange is based on ROS2 type adapters. Each filter receives ownership of a C++ data type through std::unique_ptr, for example pcl::PointCLoud or grid_map::GridMap.

I also added a compatibility node that can run existing filters::FilterChain chains.

While doing that, I noticed that ROS2 filters still use:

bool update(const T & data_in, T & data_out)

For large types like point clouds or grid maps, this can cause full data copies inside filters.

I found this older issue about in-place updates (#27)

In that discussion, in-place support was considered reasonable, and it looks like ROS 1 Noetic later had related work in #38

Are there plans to support in-place updates in ROS 2?

Something like this would be useful:

bool update(T & data)

or another API that lets filters declare whether they support in-place operations, so FilterChain<T>can avoid unnecessary intermediate copies when possible.

Thanks.

[jonbinney]

Hi @Maik13579 - your implementation sounds like a big improvement! This filters package was a pretty direct port from ROS1, and at the time I thought it would just be a stopgap until something better was written for ROS2. We've had some discussion here about what that might look like: #91 and I think your design with lifecycle components is a good way to go. I've been mostly reviewing and merging bugfix PRs on this repo, but don't have much time to implement new features. I'd be willing to review a PR implementing in-place updates though.

[Maik13579]

Hey @jonbinney, thanks for the quick response.

I think that even if a more modern solution is developed for ROS 2, this work can still be very useful. In some cases, having limited filters that perform one specific task is much better than using an overcomplicated system. That is the main reason why I decided to support this work in my implementation.

I will try to open a PR for that feature over the weekend.

[Maik13579]

My current idea is to keep the existing FilterBase<T> API fully intact and add in-place support as an optional capability instead of changing the existing base interface directly.

The main reason is compatibility. Existing filters and pluginlib plugins should continue to build and behave exactly as before. If possible, I would also like to avoid changing the ABI of FilterBase<T>, so adding another virtual function directly to that base class may not be the best first step.

A possible design would be a small optional interface, for example:

template<typename T>
class InPlaceFilter
{
public:
  virtual ~InPlaceFilter() = default;

  virtual bool update(T & data) = 0;
};

A filter that supports in-place processing could then opt in explicitly:

class MyFilter
  : public filters::FilterBase<MyType>,
    public filters::InPlaceFilter<MyType>
{
public:
  bool update(const MyType & data_in, MyType & data_out) override;
  bool update(MyType & data) override;
};

FilterChain<T> could detect the optional capability with dynamic_cast:

auto * in_place_filter =
  dynamic_cast<filters::InPlaceFilter<T> *>(filter.get());

Then the chain could expose something like:

bool can_update_fully_in_place() const;
bool update(T & data);

The intended behavior would be:

• Existing update(const T &, T &) remains part of the public API.
• Existing filters do not need to be modified.
• Filters that can safely operate in-place can opt in.
• FilterChain<T>::update(T &) can use the same object as chain input and output.
• FilterChain<T>::update(T &) can still support old filters by using internal buffers where needed.
• can_update_fully_in_place() lets users check whether every filter in the chain supports the optional in-place interface.

For the existing two-argument API:

bool update(const T & data_in, T & data_out);

the chain could also use the in-place capability internally. The API would stay the same, but the implementation could avoid intermediate buffers where possible.

One important limitation is the first filter. Since data_in is passed as const T &, the first filter cannot be run in-place on the input object. The chain must first produce a mutable object, either by calling the first filter through the existing two-argument API or by copying data_in into data_out/a buffer before applying an in-place filter.

After that point, the chain can apply in-place-capable filters directly to the currently active mutable data object. A copy buffer would only be needed when the chain reaches a filter that only supports the existing:

bool update(const T & data_in, T & data_out);

interface.

So the chain execution could become something like:

• The first step must create mutable output because data_in is const.
• Consecutive in-place-capable filters can then modify the currently active mutable object directly.
• buffer0_ / buffer1_ are only needed when an old-style filter requires separate input and output objects.
• The chain tracks which object currently contains the latest result.
• At the end, it copies into data_out only if the final result is not already there.

This means existing users of update(const T &, T &) could benefit automatically, without changing their call site, while the public API remains compatible.

The explicit FilterChain<T>::update(T &) API could also support old filters. In that case, T & data means that the chain input and output object are the same from the caller's perspective. Internally, the chain may still use buffers for filters that only implement the existing update(const T &, T &) interface.

So update(T &) would be usable for any configured chain, while filters that implement the optional InPlaceFilter<T> interface allow the chain to avoid buffers for those specific steps. If every filter supports the optional interface, the chain can run fully in-place.

Since FilterChain<T> is a header-only template, extending the implementation should be much less problematic from an ABI perspective than changing FilterBase<T>. The important part is that the existing public API and behavior stay compatible.

This behavior could be controlled by a chain-level ROS parameter, for example:

in_place: false

with the default being false. This avoids changing behavior without user consent, so users have to explicitly opt in to the new execution path.

If disabled, the chain behaves exactly as it does today. If enabled, the existing update(const T &, T &) implementation may use in-place-capable filters internally to reduce copies. The explicit update(T &) API could also use this optimized execution path, while falling back to internal buffers for old-style filters when needed.

[jonbinney]

I like this direction! A few thoughts:

1. Instead of having each in place filter inherit from both FilterBase and InPlaceFilter, you could have InPlaceFilter inherit from FilterBase and have in place filter classes only inherit from InPlaceFilter. This would avoid multiple inheritance and keep the class graph simpler.
2. InPlaceFilter could implement a generic update(const T & data_in, T & data_out) that copies data_in to data_out, and then calls the child's in-place update function on data_out. Saves the filter implementer from needing to implement an extra function.
3. Adding the extra in_place ROS parameter seems unnecessary; this change shouldn't affect the functionality of a filter chain - just the performance.