Repository Summary
Checkout URI | https://github.com/fkie/message_filters.git |
VCS Type | git |
VCS Version | ros2 |
Last Updated | 2025-06-03 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
fkie_message_filters | 3.2.1 |
README
FKIE Message Filters
Summary
The fkie_message_filters
library is a replacement for the ROS
message_filters
package. It is written in modern C++ and more type-safe than
the original version.
The data flow is modeled with a pipeline metaphor, where data always flows from a source to a sink. A filter is both source and sink for data, possibly with different data types. For integration with ROS, the library provides a number of subscribers and publishers which act as sources or sinks of the data flow.
Requirements
The fkie_message_filters
library requires C++17 or newer. Some filters depend
on image_transport
or tf2_ros
.
Design
The filters are written to be as data agnostic as possible. Therefore, many filters can process arbitrary data types and are not restricted to ROS messages. A few filters need access to ROS header information, such as time stamp or TF frame identifier.
Sources and sinks are strongly typed, i.e., each source will only pass on data of a particular type, and each sink will only accept data of a particular type. The compiler will error out if you try to connect incompatible filters. As the strong typing relies on the C++ template mechanism, the error messages can be quite verbose and difficult to parse sometimes (looking at you, GCC).
The library filters support arbitrary arities, i.e., the grouping of multiple
data types, where items of different types are combined and passed on as a unit.
This is particularly useful to process messages from distinct topics which
belong together conceptually, e.g., the sensor_msgs::msg::Image
and
sensor_msgs::msg::CameraInfo
messages from a calibrated camera.
Getting Started
While you are free to derive your own filters from the basic source and sink classes, it is most likely better to integrate the application logic with custom callback functions.
The SimpleUserFilter works almost like a regular ROS callback, but it expects a boolean return value that determines if the data is passed on to subsequent filters in the pipeline (if any), or if processing terminates. You can use this type of filter to consume data at the end of the pipeline, or if you want to remove invalid inputs before further processing occurs.
The UserFilter is more generic and can be used if your filter outputs differ from its inputs. You can implement pretty much any kind of transforming filter.
The UserSource is a simple data source which behaves like a function wrapper and can be used as callback in third-party code.
As a simple “Hello World” example, consider:
#include <fkie_message_filters/fkie_message_filters.h>
#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>
namespace mf = fkie_message_filters;
using StringSubscriber = mf::Subscriber<std_msgs::msg::String, mf::RosMessage>;
using StringPublisher = mf::Publisher<std_msgs::msg::String, mf::RosMessage>;
using GreetingFilter = mf::UserFilter<StringSubscriber::Output, StringPublisher::Input>;
int main(int argc, char** argv)
{
rclcpp::init(argc, argv);
rclcpp::Node::SharedPtr node = std::make_shared<rclcpp::Node>("hello");
StringSubscriber sub(node, "name");
StringPublisher pub(node, "greeting");
GreetingFilter flt;
flt.set_processing_function(
[](const std_msgs::msg::String& input, const GreetingFilter::CallbackFunction& output)
{
std_msgs::msg::String greeting;
greeting.data = "Hello, " + input.data + "!";
output(greeting);
});
mf::chain(sub, flt, pub);
rclcpp::spin(node);
return 0;
}
The user-defined filter accepts a std_msgs::msg::String
message with a name as
input and composes a new std_msgs::msg::String
message with a personalized
greeting as output. Note that each source can have arbitrarily many sinks
connected to it, and vice versa, so the simplicity of the three-link chain in
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/fkie/message_filters.git |
VCS Type | git |
VCS Version | ros2 |
Last Updated | 2025-06-03 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
fkie_message_filters | 3.2.1 |
README
FKIE Message Filters
Summary
The fkie_message_filters
library is a replacement for the ROS
message_filters
package. It is written in modern C++ and more type-safe than
the original version.
The data flow is modeled with a pipeline metaphor, where data always flows from a source to a sink. A filter is both source and sink for data, possibly with different data types. For integration with ROS, the library provides a number of subscribers and publishers which act as sources or sinks of the data flow.
Requirements
The fkie_message_filters
library requires C++17 or newer. Some filters depend
on image_transport
or tf2_ros
.
Design
The filters are written to be as data agnostic as possible. Therefore, many filters can process arbitrary data types and are not restricted to ROS messages. A few filters need access to ROS header information, such as time stamp or TF frame identifier.
Sources and sinks are strongly typed, i.e., each source will only pass on data of a particular type, and each sink will only accept data of a particular type. The compiler will error out if you try to connect incompatible filters. As the strong typing relies on the C++ template mechanism, the error messages can be quite verbose and difficult to parse sometimes (looking at you, GCC).
The library filters support arbitrary arities, i.e., the grouping of multiple
data types, where items of different types are combined and passed on as a unit.
This is particularly useful to process messages from distinct topics which
belong together conceptually, e.g., the sensor_msgs::msg::Image
and
sensor_msgs::msg::CameraInfo
messages from a calibrated camera.
Getting Started
While you are free to derive your own filters from the basic source and sink classes, it is most likely better to integrate the application logic with custom callback functions.
The SimpleUserFilter works almost like a regular ROS callback, but it expects a boolean return value that determines if the data is passed on to subsequent filters in the pipeline (if any), or if processing terminates. You can use this type of filter to consume data at the end of the pipeline, or if you want to remove invalid inputs before further processing occurs.
The UserFilter is more generic and can be used if your filter outputs differ from its inputs. You can implement pretty much any kind of transforming filter.
The UserSource is a simple data source which behaves like a function wrapper and can be used as callback in third-party code.
As a simple “Hello World” example, consider:
#include <fkie_message_filters/fkie_message_filters.h>
#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>
namespace mf = fkie_message_filters;
using StringSubscriber = mf::Subscriber<std_msgs::msg::String, mf::RosMessage>;
using StringPublisher = mf::Publisher<std_msgs::msg::String, mf::RosMessage>;
using GreetingFilter = mf::UserFilter<StringSubscriber::Output, StringPublisher::Input>;
int main(int argc, char** argv)
{
rclcpp::init(argc, argv);
rclcpp::Node::SharedPtr node = std::make_shared<rclcpp::Node>("hello");
StringSubscriber sub(node, "name");
StringPublisher pub(node, "greeting");
GreetingFilter flt;
flt.set_processing_function(
[](const std_msgs::msg::String& input, const GreetingFilter::CallbackFunction& output)
{
std_msgs::msg::String greeting;
greeting.data = "Hello, " + input.data + "!";
output(greeting);
});
mf::chain(sub, flt, pub);
rclcpp::spin(node);
return 0;
}
The user-defined filter accepts a std_msgs::msg::String
message with a name as
input and composes a new std_msgs::msg::String
message with a personalized
greeting as output. Note that each source can have arbitrarily many sinks
connected to it, and vice versa, so the simplicity of the three-link chain in
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/fkie/message_filters.git |
VCS Type | git |
VCS Version | ros2 |
Last Updated | 2025-06-03 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
fkie_message_filters | 3.2.1 |
README
FKIE Message Filters
Summary
The fkie_message_filters
library is a replacement for the ROS
message_filters
package. It is written in modern C++ and more type-safe than
the original version.
The data flow is modeled with a pipeline metaphor, where data always flows from a source to a sink. A filter is both source and sink for data, possibly with different data types. For integration with ROS, the library provides a number of subscribers and publishers which act as sources or sinks of the data flow.
Requirements
The fkie_message_filters
library requires C++17 or newer. Some filters depend
on image_transport
or tf2_ros
.
Design
The filters are written to be as data agnostic as possible. Therefore, many filters can process arbitrary data types and are not restricted to ROS messages. A few filters need access to ROS header information, such as time stamp or TF frame identifier.
Sources and sinks are strongly typed, i.e., each source will only pass on data of a particular type, and each sink will only accept data of a particular type. The compiler will error out if you try to connect incompatible filters. As the strong typing relies on the C++ template mechanism, the error messages can be quite verbose and difficult to parse sometimes (looking at you, GCC).
The library filters support arbitrary arities, i.e., the grouping of multiple
data types, where items of different types are combined and passed on as a unit.
This is particularly useful to process messages from distinct topics which
belong together conceptually, e.g., the sensor_msgs::msg::Image
and
sensor_msgs::msg::CameraInfo
messages from a calibrated camera.
Getting Started
While you are free to derive your own filters from the basic source and sink classes, it is most likely better to integrate the application logic with custom callback functions.
The SimpleUserFilter works almost like a regular ROS callback, but it expects a boolean return value that determines if the data is passed on to subsequent filters in the pipeline (if any), or if processing terminates. You can use this type of filter to consume data at the end of the pipeline, or if you want to remove invalid inputs before further processing occurs.
The UserFilter is more generic and can be used if your filter outputs differ from its inputs. You can implement pretty much any kind of transforming filter.
The UserSource is a simple data source which behaves like a function wrapper and can be used as callback in third-party code.
As a simple “Hello World” example, consider:
#include <fkie_message_filters/fkie_message_filters.h>
#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>
namespace mf = fkie_message_filters;
using StringSubscriber = mf::Subscriber<std_msgs::msg::String, mf::RosMessage>;
using StringPublisher = mf::Publisher<std_msgs::msg::String, mf::RosMessage>;
using GreetingFilter = mf::UserFilter<StringSubscriber::Output, StringPublisher::Input>;
int main(int argc, char** argv)
{
rclcpp::init(argc, argv);
rclcpp::Node::SharedPtr node = std::make_shared<rclcpp::Node>("hello");
StringSubscriber sub(node, "name");
StringPublisher pub(node, "greeting");
GreetingFilter flt;
flt.set_processing_function(
[](const std_msgs::msg::String& input, const GreetingFilter::CallbackFunction& output)
{
std_msgs::msg::String greeting;
greeting.data = "Hello, " + input.data + "!";
output(greeting);
});
mf::chain(sub, flt, pub);
rclcpp::spin(node);
return 0;
}
The user-defined filter accepts a std_msgs::msg::String
message with a name as
input and composes a new std_msgs::msg::String
message with a personalized
greeting as output. Note that each source can have arbitrarily many sinks
connected to it, and vice versa, so the simplicity of the three-link chain in
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/fkie/message_filters.git |
VCS Type | git |
VCS Version | ros2 |
Last Updated | 2025-06-03 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
fkie_message_filters | 3.2.1 |
README
FKIE Message Filters
Summary
The fkie_message_filters
library is a replacement for the ROS
message_filters
package. It is written in modern C++ and more type-safe than
the original version.
The data flow is modeled with a pipeline metaphor, where data always flows from a source to a sink. A filter is both source and sink for data, possibly with different data types. For integration with ROS, the library provides a number of subscribers and publishers which act as sources or sinks of the data flow.
Requirements
The fkie_message_filters
library requires C++17 or newer. Some filters depend
on image_transport
or tf2_ros
.
Design
The filters are written to be as data agnostic as possible. Therefore, many filters can process arbitrary data types and are not restricted to ROS messages. A few filters need access to ROS header information, such as time stamp or TF frame identifier.
Sources and sinks are strongly typed, i.e., each source will only pass on data of a particular type, and each sink will only accept data of a particular type. The compiler will error out if you try to connect incompatible filters. As the strong typing relies on the C++ template mechanism, the error messages can be quite verbose and difficult to parse sometimes (looking at you, GCC).
The library filters support arbitrary arities, i.e., the grouping of multiple
data types, where items of different types are combined and passed on as a unit.
This is particularly useful to process messages from distinct topics which
belong together conceptually, e.g., the sensor_msgs::msg::Image
and
sensor_msgs::msg::CameraInfo
messages from a calibrated camera.
Getting Started
While you are free to derive your own filters from the basic source and sink classes, it is most likely better to integrate the application logic with custom callback functions.
The SimpleUserFilter works almost like a regular ROS callback, but it expects a boolean return value that determines if the data is passed on to subsequent filters in the pipeline (if any), or if processing terminates. You can use this type of filter to consume data at the end of the pipeline, or if you want to remove invalid inputs before further processing occurs.
The UserFilter is more generic and can be used if your filter outputs differ from its inputs. You can implement pretty much any kind of transforming filter.
The UserSource is a simple data source which behaves like a function wrapper and can be used as callback in third-party code.
As a simple “Hello World” example, consider:
#include <fkie_message_filters/fkie_message_filters.h>
#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>
namespace mf = fkie_message_filters;
using StringSubscriber = mf::Subscriber<std_msgs::msg::String, mf::RosMessage>;
using StringPublisher = mf::Publisher<std_msgs::msg::String, mf::RosMessage>;
using GreetingFilter = mf::UserFilter<StringSubscriber::Output, StringPublisher::Input>;
int main(int argc, char** argv)
{
rclcpp::init(argc, argv);
rclcpp::Node::SharedPtr node = std::make_shared<rclcpp::Node>("hello");
StringSubscriber sub(node, "name");
StringPublisher pub(node, "greeting");
GreetingFilter flt;
flt.set_processing_function(
[](const std_msgs::msg::String& input, const GreetingFilter::CallbackFunction& output)
{
std_msgs::msg::String greeting;
greeting.data = "Hello, " + input.data + "!";
output(greeting);
});
mf::chain(sub, flt, pub);
rclcpp::spin(node);
return 0;
}
The user-defined filter accepts a std_msgs::msg::String
message with a name as
input and composes a new std_msgs::msg::String
message with a personalized
greeting as output. Note that each source can have arbitrarily many sinks
connected to it, and vice versa, so the simplicity of the three-link chain in
File truncated at 100 lines see the full file