Message Filters dysfunctional for PointCloud2 sensor messages
I understand the title is vague, but then so is the documentation for message filters. I should say the documentation is clear on method signatures, but at compile time, those signatures are not recognized. Here is a snippet of code:
#include <ros/ros.h>
#include <pcl_ros/point_cloud.h>
#include <pcl/point_types.h>
#include <pcl_conversions/pcl_conversions.h>
#include <pcl_ros/transforms.h>
#include <sensor_msgs/PointCloud2.h>
#include <opencv2/opencv.hpp>
#include <geometry_msgs/PointStamped.h>
#include <tf2_ros/transform_listener.h>
#include <tf2_ros/message_filter.h>
#include <message_filters/subscriber.h>
#include <tf2_geometry_msgs/tf2_geometry_msgs.h>
using namespace std;
using namespace sensor_msgs;
tf2_ros::TransformListener tf2_listener;
ros::NodeHandle nh;
message_filters::Subscriber<sensor_msgs::PointCloud2> cloud2_sub(nh, "lidar/points", 100);
tf2_ros::MessageFilter<sensor_msgs::PointCloud2> tf2_filter(cloud2_sub, tf2_listener, "camera_odom_frame", 100);
I have tried declaring and initializing the Subscriber and MessageFilter types separately, but the error is consistently:
175:70: error: ‘nh’ is not a type
message_filters::Subscriber<sensor_msgs::PointCloud2> cloud2_sub(nh, "/lidar/points", 100);
^~
175:74: error: expected identifier before string constant
message_filters::Subscriber<sensor_msgs::PointCloud2> cloud2_sub(nh, "/lidar/points", 100);
^~~~~~~~~~~~~
175:74: error: expected ‘,’ or ‘...’ before string constant
176:65: error: ‘cloud2_sub’ is not a type
tf2_ros::MessageFilter<sensor_msgs::PointCloud2> tf2_filter(cloud2_sub, tf2_listener, "camera_odom_frame", 100);
^~~~~~~~~~
176:77: error: ‘tf2_listener’ is not a type
tf2_ros::MessageFilter<sensor_msgs::PointCloud2> tf2_filter(cloud2_sub, tf2_listener, "camera_odom_frame", 100);
^~~~~~~~~~~~
176:91: error: expected identifier before string constant
tf2_ros::MessageFilter<sensor_msgs::PointCloud2> tf2_filter(cloud2_sub, tf2_listener, "camera_odom_frame", 100)
I have been looking over the WIki documentation for days and scouring code. Literally everywhere, you can find these very same code snippets and signatures --- but clearly, something has changed in Noetic, and neither the documentation nor other references are accurately reflecting the source code.
Why might it not be possible to use sensor messages with TF2 message filters? What has changed in Noetic that makes the above code invalid? Even the error messages make no sense --- "expected identifier before string constant" and then pointing to the topic. And "nh is not a type"? It's defined as Nodehandle type and pulling from the ros.h header. What could be more obvious to the compiler than that? Honestly, this is borderline ridiculous. Such code worked perfectly fine in Melodic.
ENVIRONMENT:
Ubuntu 20.04 ROS Noetic
What documentation are you using? Can you please update with a link to it?
Is the ROS Wiki not the right resource for information? There are also the Noetic docs, but they are no more helpful.
We've tabled message filters for now and are looking into simply subscribing to a PointCloud2 message stream with a callback, but it zeroes out all the transforms from the external IMU without rhyme or reason, so ultimately, I am wondering if ROS may be used at all for synchronization of LiDAR and external IMU. I haven't seen any solid examples of anyone doing it.
I was just trying to know which docs you're referring to
I get you're getting frustrated, and I sympathise, but honestly, if you're looking for help, such comments don't actually help.
Additionally: this is a C++ compiler, which, while they've become much smarter over the years, will still try to "plod on" after encountering a first error, often resulting in it trying to make sense of whatever is left of your file after that error.
You should basically ignore everything ...(more)
Could you clarify whether #q377356 is only related, or a differently worded duplicate ?
Finally: could you show a mwe which exhibits the problem?
The errors you show are on line 175. The code you show clearly doesn't have 175 lines, and many more headers than I'd expect.