compile error using wavemap 2.0 with LIVOX_AVAILABLE

[YoungCapta1n]

Question
Thanks for updating wavemap. I've tested wavemap 1.6.3 with livox mid360, it works very well.
When I try a native installation with wavemap 2.0, it cannot build successfully. The compile error is shown as follows,

Images

• CPU: [Intel i9-9900K]
• GPU: [Nvidia RTX 2080Ti] # Only for visualization-related issues
• RAM: [32GB]
• OS: [Ubuntu 20.04]
• Wavemap
  • install: [Native (ROS noetic with catkin); ]
  • version: [e.g., v2.0.0]

[victorreijgwart]

Thanks a lot for reporting this @YoungCapta1n. Something must have gone wrong when refactoring, and it slipped through our tests. I'll dig into it and get back to you this afternoon.

[YoungCapta1n]

Thanks a lot for reporting this @YoungCapta1n. Something must have gone wrong when refactoring, and it slipped through our tests. I'll dig into it and get back to you this afternoon.

I try to modify the code as follows, All 7 packages succeeded!

src/wavemap/interfaces/ros1/wavemap_ros/include/wavemap_ros/inputs/impl/pointcloud_topic_input_impl.h

src/wavemap/interfaces/ros1/wavemap_ros/src/inputs/pointcloud_topic_input.cc

[YoungCapta1n]

I have another issue when using wavemap 2.0.
The crop operation has been added to the config file.

It gives an error when using lookupTransform() function.

[victorreijgwart]

Thanks for the suggested fix! It also solves the issue on my machine. I'll open a PR for this patch.

Regarding the crop_map operation, you need to set its body_frame param to the name of a ROS TF frame to will be used as the cropping operation's center point. For a robot, you could, for example, take its center of mass. If you don't have such a frame in your TF tree, or if you're not using a robot, you could set it to the TF frame of your sensor. If you're still using the same setup as in this reply, you could set body_frame: "livox_frame". Let me know if this solves the issue.

[YoungCapta1n]

body_frame

Thanks for your reply!. body_frame: "livox_frame" gives the same warning. I've tried the crop operation on wavemap branch feature/plugin_system, it works well!

[victorreijgwart]

@YoungCapta1n, I added you as a co-author for this fix to acknowledge your contribution (see #68). But I wanted to check with you just in case. If you would prefer not to be mentioned, let me know - the commit can still be changed before it gets merged.

[victorreijgwart]

One thing that changed between the feature/plugin_system branch and release v2.0.0 is that the TF lookup now happens based on the timestamp of ros::Time::now() instead of using the timestamp of the last measurement. We had to make this change to support ROS-agnostic map operations in wavemap's C++ library.

In your tests, are you replaying a rosbag? If so, could you check if you set /use_sim_time: true and run rosbag play with the --clock argument?

[YoungCapta1n]

One thing that changed between the feature/plugin_system branch and release v2.0.0 is that the TF lookup now happens based on the timestamp of ros::Time::now() instead of using the timestamp of the last measurement. We had to make this change to support ROS-agnostic map operations in wavemap's C++ library.

In your tests, are you replaying a rosbag? If so, could you check if you set /use_sim_time: true and run rosbag play with the --clock argument?

Thanks for your reply. I use wavemap2.0 with real-time stream of MID-360, not rosbag. I will check the timestamp and test the crop operation.

[victorreijgwart]

Hi @YoungCapta1n, I'll close this issue for now since the bug is fixed. If you have follow-up questions or would like to discuss how the timing is handled for map operations, don't hesitate to open a new issue :)