Open 3zuli opened 2 years ago
Min_z impacts the clearly frustum logic, not the marking logic. Typically, if you have occlusions in your sensor field of view due to your platform, you’d use a robot self filter or similar as a preprocessing step to the data into the navigation stack. That would go for this layer and any others that might be using that data stream. There are several packages that can do this, but for example in 2D lidars there’s the Filters project that have length and angular range filters to remove such points. I’d suggest looking into those.
Thanks for the clarification about min_z and max_z. Since there already is a maximum obstacle_range
parameter, I was expecting that there would also be a parameter for minimum obstacle range. After some digging I found that it could be added to this line in spatio_temporal_voxel_grid.cpp
if needed. In my case, using something like the rgbd_self_filter package is overkill, if the same thing can be accomplished just by changing an if condition. For now I just moved the camera forward in AirSim.
Hello, I am trying to use STVL in conjunction with AirSim to simulate a drone with a depth camera. The problem is that the point cloud from the virtual depth camera also contains parts of the drone, which are then added into the STVL map as obstacles:
The obvious way to fix this is to move the camera forward so it doesn't see parts of the drone (this can be adjusted in AirSim). However, is it possible to configure STVL to ignore points that are closer than a threshold? I tried adding the
min_z = 1.0
andmax_z = 7.0
parameters to my marking source, as I understood that they define the near and far planes of the frustum. However this has no effect, the near points are still added to the map regardless of themin_z
value.I am using ROS Melodic and STVL is built from source. This is my config: