Adapting to real-time updating feature map

[smoggy-P]

Hi, thanks for the great work! I was trying to reproduce the pipeline with my own simulation setups. However, after some trials, I found it difficult to adapt the current code for a real-time updating feature map. It seems that in the currently released code, you read the ground truth feature map loading from a ply file.

Could you share some insights about adapting the current code to a real-time published feature map? I believe you are doing the same in the real-world test, but I cannot find the relevant code in this repo. Thank you in advance.

[STUDYXIN]

Hi, thanks for the great work! I was trying to reproduce the pipeline with my own simulation setups. However, after some trials, I found it difficult to adapt the current code for a real-time updating feature map. It seems that in the currently released code, you read the ground truth feature map loading from a ply file.

Could you share some insights about adapting the current code to a real-time published feature map? I believe you are doing the same in the real-world test, but I cannot find the relevant code in this repo. Thank you in advance.

Hi, thanks for the kind words! You’re right—the public repo loads a static ground-truth feature map from a .ply file for reproducibility. In our real-world runs we use a live, incrementally updated feature map. In brief, we take streamed feature points with odometry, maintain a persistent feature cloud plus a KD-tree, and update them online. For each update:

• first remove currently visible/trusted nearby points,
• keep only points that pass bounds/FOV/occlusion checks (and drop obvious floating/noisy ones),
• finally, apply a voxel-downsampling pass to keep the map compact and stabilize point density before publishing.

Hope this helps!

[smoggy-P]

Hi, thanks @STUDYXIN for your response. I tried again to implement it in this fork. What I did was to create a new pointcloud callback to take new points and merge them to the feature_cloud_ while adding a fake flag to known_flag_. I can see the feature map getting updated correctly. However, the FSM acts very weirdly and slowly, and the planning pipeline does not work in my case. The /planning/pos_cmd topic only outputs the target position without intermediate trajectories.

Is that possible for you to also open-source the code you used for real-world experiments? There might be some details I neglected in my implementation. It would be very helpful to do that. I will only use it for baseline comparison.

[sanghun17]

Hi, thanks for the great work and for sharing the code!

I'm a graduate student working on risk-aware 3D planning for autonomous drones, and I'm currently integrating LA-Planner as a comparison baseline in our AirSim/Unreal simulation environment.

I'm running into the same challenge as @smoggy-P regarding feature map setup. In my case, I'm stuck between two options:

Static PLY approach: I'd like to generate a feature.ply for our environment, but I'm not sure what criteria were used to create the provided map1/feature.ply (e.g., manually placed, extracted from mesh/texture, etc.), so it's difficult to replicate the process for a new environment.

Real-time approach: The online feature cloud update method you described above sounds like a more generalizable solution, but as @smoggy-P mentioned, the code for this isn't available in the current release.

Would it be possible to share either some guidance on how to generate the static PLY for a custom environment, or the real-time feature map update code? Either would be incredibly helpful for adapting LA-Planner to new simulation environments.

Thank you so much for your time!