ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Hi,

sorry for the late response.

if you really have multiple in-place filters FilterChain is not your friend in this case. You could avoid this by using Ptr msgs.

f(const LaserScanPtr& in, LaserScanPtr& out)
{
   //allowed since you are modifying the data and not the ptr
   modify(in);
   //Just ptr copy
   out = in;
}

But note that since you get it from the callback and it is a const Ptr there, at least the input will be copied. once. All filters in the chain must support this type of course. Probably the designers did not want to rely on the filter plugins to check if they need to copy the input first because there are also a lot of non in-pace filters anyway (hence in is const to signal that).

So still why is in != out addresswise?

FilterChain has two internal buffers of datatype LaserScan in your case.

FilterChain length 1: call filter0.update(scan, scan) in your case. FilterChain length 2: calls filter0.update(scan, buffer0) and filter1.update(buffer0, scan).

For more filters it keeps toggling two input buffers (0, 1) until the final one.

Hi,

sorry for the late response.

if you really have multiple in-place filters FilterChain is not your friend in this case. You could avoid this by using Ptr msgs.msgs (or wrapped in another datatype).

f(const LaserScanPtr& in, LaserScanPtr& out)
{
   //allowed since you are modifying the data and not the ptr
   modify(in);
   //Just ptr copy
   out = in;
}

But note that since you get it from the callback and it is a const Ptr there, at least the input will be copied. once. All filters in the chain must support this type of course. Probably the designers did not want to rely on the filter plugins to check if they need to copy the input first because there are also a lot of non in-pace filters anyway (hence in is const to signal that).

So still why is in != out addresswise?

FilterChain has two internal buffers of datatype LaserScan in your case.

FilterChain length 1: call filter0.update(scan, scan) in your case. FilterChain length 2: calls filter0.update(scan, buffer0) and filter1.update(buffer0, scan).

For more filters it keeps toggling two input buffers (0, 1) until the final one.