Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ROS2 support #16

Merged
merged 1 commit into from
Jul 25, 2023
Merged

Add ROS2 support #16

merged 1 commit into from
Jul 25, 2023

Conversation

shrijitsingh99
Copy link

Ported over the entire code to ROS2
Major changes:

  • Renamed service to be compliant with ROS2 service naming standard
  • Update RViz config for RViz2
  • Use MultiThreadedExecutor with callback groups to achieve what the async spinner did
  • Move some of the includes out 'dlio.h' to remove 'rclcpp' and other library dependencies on gicp
  • Update launch and param files

@kennyjchen kennyjchen changed the base branch from master to feature/ros2 July 25, 2023 17:18
@kennyjchen
Copy link
Contributor

Awesome -- thanks @shrijitsingh99 for porting DLIO to ROS2, it looks great! I've gone ahead and changed the base branch to feature/ros2. Thanks for the contribution :^)

@kennyjchen kennyjchen merged commit 977094b into vectr-ucla:feature/ros2 Jul 25, 2023
@juliangaal
Copy link
Contributor

Have you considered the changes to the sensor / lidar frame when working with Ouster data? @shrijitsingh99

Some recent discussions about it here: ouster-lidar/ouster-ros#33

@shrijitsingh99
Copy link
Author

I don't think any changes are needed here.
From the discussion my understanding is that the data is by default published in sensor frame which the default extrinsics in the yaml reflect. If some user changes the frames they would need to update the extrinsic in the config file here.

The frame_id in the point cloud message itself doesn't affect the algorithm.

@yashmewada9618
Copy link

System: Ubuntu 22
ROS Version: Humble

Hello,
I used DLIO's ROS Noetic version, and it worked perfectly in the first run. However, when I converted the same bag file to ROS 2, things did not work out. After initializing the node, it worked for a short while, but as soon as the robot started moving, the pose estimation got messed up which I think is due to IMU's integration and pose estimation. The local maps from DLIO started moving in the Z direction instead of the correct forward motion. I tried changing the frames (as the Ouster lidar frame and sensor frames are rotated by 180 degrees), and calibration time, but it did not help. I noticed a notable change when I modified the gravity bias from 9.8 to -9.8 in the config file, where the pose estimation translated correctly, but the orientation was wrong.
Has anyone else experienced this issue with the ros2 branch of this code?

Thanks.

gandres42 pushed a commit to Cardinal-Space-Mining/direct_lidar_inertial_odometry that referenced this pull request May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants