Question about the relationship between octree and occupied map, and ghost in dynamic scenes.

[jingyang-huang]

Dmap is absolutely a marvellous work, I tried it on my own dataset, and fount that it could construct a map with high resolution and very low disk usage. However, I found there`s a few questions about it and wish you could consider it. Firstly, I tried to comment Octree updating code in D-map.cpp (octree.UpdateTree(&segtree, init_FoV, &cur_depthmap);) . I observed that the grid map remained unaffected, and the map quality stayed the same. It appears that the construction of the grid map does not depend on the octree map to represent known cells. This is contrary to my expectation: the occupied map should only update cells marked as known by the octree map.

(left is UpdateTree commented, while the right is not commented)

Secondly, since Dmap assumes the scene to be static, dynamic objects persist in the map and form ghost, which can be seen in picture above. As far as I know, works like Removert or Erasor can be used to remove them from the map, or M-detector can filter dynamic objects before mapping. However, is there a way to modify DMap to make it suitable for dynamic scenes, similar to those maps with occupancy probabilities?

[zhujiangchao]

您的邮件已经收到，我会尽快查看，谢谢！

[Ecstasy-EC]

Thanks for your interest in D-Map.

For the first question, as we assume strong confidence in the LiDAR measurement, D-Map keeps registering LiDAR points into the grid map without the unknown/known information. Therefore, no matter whether you disabled the octree update process or not, the grid map remained the same. We used to consider a similar update mechanism as you proposed, but the problem is that the updating is too time-consuming because you need to check every LiDAR point on the octree. You might consider querying both the octree and the grid map for a voxel and then deciding its occupancy state by combining information from both sides. For example, if the octree shows the voxel is unknown but the grid map shows the voxel is occupied, it is your turn to determine whether you are using it as occupied or unknown.

The probability could be considered in our D-Map and we did implement a version with occupancy probability for D-Map. However, as the version is inconsistent with our initial assumption in our paper, we will not include it in our repo. You might refer to our paper for the methodology and make some modifications based on our original code.

I hope my answers will help.

[zhujiangchao]

您的邮件已经收到，我会尽快查看，谢谢！

[jingyang-huang]

Thanks for your interest in D-Map.

For the first question, as we assume strong confidence in the LiDAR measurement, D-Map keeps registering LiDAR points into the grid map without the unknown/known information. Therefore, no matter whether you disabled the octree update process or not, the grid map remained the same. We used to consider a similar update mechanism as you proposed, but the problem is that the updating is too time-consuming because you need to check every LiDAR point on the octree. You might consider querying both the octree and the grid map for a voxel and then deciding its occupancy state by combining information from both sides. For example, if the octree shows the voxel is unknown but the grid map shows the voxel is occupied, it is your turn to determine whether you are using it as occupied or unknown.

The probability could be considered in our D-Map and we did implement a version with occupancy probability for D-Map. However, as the version is inconsistent with our initial assumption in our paper, we will not include it in our repo. You might refer to our paper for the methodology and make some modifications based on our original code.

I hope my answers will help.

Thanks for your reply. I now understand the reasoning behind D-Map's updating technique, which is to update quickly while retaining more data. This is an intriguing and instructive feature that sets this effort apart from others. To make it useful in more situations, I would make some changes. Lastly, D-Map is a fantastic work and I have gained a lot from it.

[AmishaSomaiya]

Hi, Great paper and repo. @Ecstasy-EC and @HuangJY503, which version of Ubuntu and ROS did you use /recommend for this repo. I have Ubuntu22-ROS2 Humble with a VM of Ubuntu18-ROS1 Melodic. For Humble, I did colcon build instead of catkin_make, changed the corresponding dependencies with ament_cmake among other changes but I am having a tough time running this repo on both. I also tried on my VM but I am having version issues of Qt5 in Melodic for it.

Request to kindly advise on the recommended approach to run this code on Ubuntu 22 : Should I setup a ROS2-ROS1 bridge or migrate this code to ROS2. Thank you,

[jingyang-huang]

Hi, Great paper and repo. @Ecstasy-EC and @HuangJY503, which version of Ubuntu and ROS did you use /recommend for this repo. I have Ubuntu22-ROS2 Humble with a VM of Ubuntu18-ROS1 Melodic. For Humble, I did colcon build instead of catkin_make, changed the corresponding dependencies with ament_cmake among other changes but I am having a tough time running this repo on both. I also tried on my VM but I am having version issues of Qt5 in Melodic for it.

Request to kindly advise on the recommended approach to run this code on Ubuntu 22 : Should I setup a ROS2-ROS1 bridge or migrate this code to ROS2. Thank you,

Hello, My version is Ubuntu 20.04 with ROS1 noetic. I have not tested this repo on Ubuntu22-ROS2 Humble or Ubuntu18-ROS1 Melodic myself, but if you want to migrate this code to ROS2, I suppose you could modify the communication part (like ROS topic) in this repo, as ROS just serves as an information channel and map IO is handled by the PCL library. With this would be helpful to you.

[AmishaSomaiya]

Hi Hua,

Thank you for your response. I had too many issues migrating the code to ROS2 with Ubuntu22. Finally, since I needed ROS Noetic for a few other reasons as well, set-up a VM with Ubuntu20-ROS1 Noetic. Code works like a charm.

Thanks, Amisha.

On Sat, Feb 17, 2024 at 6:53 AM Hua Jiaoyu @.***> wrote:

Hi, Great paper and repo. @Ecstasy-EC https://urldefense.com/v3/__https://github.com/Ecstasy-EC__;!!K-Hz7m0Vt54!m8au172chPRIixFLYkzgt1IiHLSYGw2by1nL8vhCzEcN0cWrgF5C2LUgVnHvMy3sbaZGbtNktDOty94jfDVEoZc$ and @HuangJY503 https://urldefense.com/v3/__https://github.com/HuangJY503__;!!K-Hz7m0Vt54!m8au172chPRIixFLYkzgt1IiHLSYGw2by1nL8vhCzEcN0cWrgF5C2LUgVnHvMy3sbaZGbtNktDOty94jpwkaVPU$, which version of Ubuntu and ROS did you use /recommend for this repo. I have Ubuntu22-ROS2 Humble with a VM of Ubuntu18-ROS1 Melodic. For Humble, I did colcon build instead of catkin_make, changed the corresponding dependencies with ament_cmake among other changes but I am having a tough time running this repo on both. I also tried on my VM but I am having version issues of Qt5 in Melodic for it.

Request to kindly advise on the recommended approach to run this code on Ubuntu 22 : Should I setup a ROS2-ROS1 bridge or migrate this code to ROS2. Thank you,

Hello, My version is Ubuntu 20.04 with ROS1 noetic; I have not tested Ubuntu22-ROS2 Humble, but I suppose you could modify the communication part (like ROS topic) in this repo, as ROS just serves as an information channel and map IO is handled by the PCL library. With this would be helpful to you.

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/hku-mars/D-Map/issues/5*issuecomment-1950228639__;Iw!!K-Hz7m0Vt54!m8au172chPRIixFLYkzgt1IiHLSYGw2by1nL8vhCzEcN0cWrgF5C2LUgVnHvMy3sbaZGbtNktDOty94jZJhi39s$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ASMQNI7RPTBJS3BD2TROUZ3YUC77XAVCNFSM6AAAAABBWGV2FCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQGIZDQNRTHE__;!!K-Hz7m0Vt54!m8au172chPRIixFLYkzgt1IiHLSYGw2by1nL8vhCzEcN0cWrgF5C2LUgVnHvMy3sbaZGbtNktDOty94jOe_hIT0$ . You are receiving this because you commented.Message ID: @.***>