Huangying-Zhan
commented
1 week ago Hi @Taekbum , thanks for pointing out this issue. It seems to me that it is a mistake in our released code (I will double check the internal commit history and see if we had this issue while running our experiements). I think the reasons this wasn't discovered previously are (1) most of our scenes are not multi-room environement , probably the major reason; (2) we have additional collision detection mechanism in MP3D that prevents it from collision, even the planned path turns out to be not completely free from collision. Please see https://github.com/oppo-us-research/NARUTO/blob/0eb0240033d5252228ffc88a9a15a78700cdd89b/src/planner/naruto_planner.py#L566
I have already updated the release code. Thanks again.
First of all, thank you for the code of this nice research! I am currently trying to evaluate its performance on Gibson dataset with the same configuration settings as for MP3D. I’ve noticed an issue where the planned paths incorrectly pass through walls, particularly in scenes with multiple rooms connected only by narrow doors. An example of this can be seen in the attached pictures from the Cantwell scene. (I changed viewpoint of o3d visualizer)
While investigating, I suspect there might be an issue with the collision check in the RRT implementation. It seems that the line of code intended to move from point pa to point pb but stops just before a collision occurs, but curiously, self.goal._xyz_arr is located at pa instead of pb. Is this intentional, or could it be an error?
(Actually, swapping the positions of self.nodes[-1]._xyz_arr and self.goal._xyz_arr in the function input seems to correct the issue with the erroneous paths.)
Could you please clarify if there’s a rationale behind this implementation, or if it is indeed a mistake?
Thank you for your assistance.