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

How to use 6 DoF robot localization #22

Closed
SeungRyeol opened this issue Nov 12, 2020 · 11 comments
Closed

How to use 6 DoF robot localization #22

SeungRyeol opened this issue Nov 12, 2020 · 11 comments

Comments

@SeungRyeol
Copy link

I followed your instructions and applied "3 DoF robot localization / mapping" to my real robot successfully. (#18 (comment))

And I want to try 6 DoF robot localization now.

First, I wonder if I must use this file(https://github.com/carlosmccosta/dynamic_robot_localization_tests/blob/hydro-devel/launch/environments/labiomep/labiomep_6dof.launch).

Or should I use octo_map.launch?

Can you tell me which parameters to change and which launch file to use?

@carlosmccosta
Copy link
Owner

Good night,

For 6 DoF tracking you can use as a starting point the launch files from labiomep_6dof.launch or ethzasl_kinect_dataset.launch (mainly to see the yaml configurations for the drl pipeline, the rest is for configuring the test environment and automatically load the bag files).

OctoMap can be used for adding the mapping functionality with ray tracing and dynamic addition and removal of geometry.

drl can do additive mapping internally (it can keep adding the registered point clouds to its reference map, if you enable that feature). But if you require dynamic maps in which there are dynamic objects moving around the 3D space, octomap allows the removal of these points, because it does ray tracing -> when several sensor rays from consecutive scans pass through voxels that were marked as occupied (using data from previous sensor scans), then, those 3D cells are marked as "free space", effectively removing geometry / points from the map (because they no longer occupy that 3D space).

But in the weekend I will make a more user friendly launch file within the dynamic_robot_localization launch folder.
The drl pipeline is highly reconfigurable, so you can optimize it further to your particular use case. Nevertheless, I will add a generic 6 DoF tracking launch, so you can have a more user friendly starting point.

Have a nice day :)

@SeungRyeol
Copy link
Author

Thanks for your detailed explanation. :)

I'm looking forward to your more launch file.

I will use your outdated launch file until your next update.

@tw0b33rs
Copy link

tw0b33rs commented Nov 23, 2020

Hi Carlos,
I also wanted to mention, that I'm looking forward to a more generic 6 dof tracking launch file.
Keep up the great work!
-Tobias

@carlosmccosta
Copy link
Owner

Hello,

I am occupied with other research projects right now, but I might be able to allocate some time during the end of this week to create the launch file after I finish the implementation of the Meijster distance transform in my PCL fork for initializing the correspondence estimation using look up tables that I implemented in my PCL fork -> it can significantly speedup ICP.

Have a nice day,

@tw0b33rs
Copy link

Great, I'm looking forward to it. The results in your paper look very promising, too. That could result in much better real-time 6dof localization.

@WilliamWoo45
Copy link

Hi Carlos! @carlosmccosta

In recent days, I'm trying to implement your 3-D (6 DoF) Global Localization approach to achieve initial pose estimation and pose recovery. I'm wondering:

  1. Which launch file should I use?
  2. Is there any recommended demo dataset that I can use for testing?
  3. Should I follow similar steps as the previous 2D localization case you guided me ?

Thanks again!
Wish you & your family a Merry Christmas and Happy New Year ! :)

Best Regards,
William

@carlosmccosta
Copy link
Owner

Hello,

As a starting point you can look at labiomep_6dof.launch and ethzasl_kinect_dataset.launch, which have both the configurations for drl and datasets.

I haven't had time yet to finish the lookup tables initialization with the Meijster algorithm. When I finish implementing it, I will create a more generic 6 DoF launch file using lookup tables for faster localization (when compared with kd-trees).

Merry Christmas and happy new year :)

@WilliamWoo45
Copy link

Dear Carlos,

Thanks for your speedy reply.
I'm very looking forward to your more generic 6 DoF launch file :)

Best Regards,
William

@tw0b33rs
Copy link

tw0b33rs commented Feb 9, 2021

Hi Carlos,

I wonder whether you had success implementing and testing the lookup tables initialization with the Meijster algorithm. Any news on that topic?

Best, T

@carlosmccosta
Copy link
Owner

Good night,

I am involved in other research projects and haven't had time to finish the Meijster lut initialization.
Nevertheless, the lut initialization with kd-trees is implemented, but it takes longer to initialize the lut when compared with the Meijster algorithm.
I may have some time next month, depending on how long it takes to finish the other projects tasks.

Have a nice day :)

@carlosmccosta
Copy link
Owner

Hello,

I refactored ethzasl_kinect_dataset.launch into a more generic 6 dof launch file available at dynamic_robot_localization_system_6dof.launch.

Examples on how to use it in use_cases.md.

For now, the usage of lookup tables (LUTs) in 6 DoF requires the initialization with k-d trees (when I have some time I will finish the Meijster algorithm to speedup its initialization).

For activating the LUTs it is only necessary to change the correspondence_estimation_approach from CorrespondenceEstimation to CorrespondenceEstimationLookupTable in the cluttered_environments_dynamic_large_map_3d.yaml.

The lookup tables can speedup the correspondence estimation phase of the iterative closest point (ICP) algorithm from 20 to 60 times, depending on the sensor data, reference point cloud and configurations of drl.

But keep in mind that a LUT with small cell size (below 1 cm) for large reference point clouds (bounding box with several meters) requires a lot of RAM, while the corresponding k-d tree is extremely efficient in memory usage (at the cost of being slower than the LUT).

Also, k-d trees by being sparse search data structures initialize much faster than LUTs.

Have a nice day :)

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

No branches or pull requests

4 participants