ROS Parameters
This page contains all parameters exposed to ROS 2. For the provided
examples in the nvblox_example_bringup
package, parameters are set
using YAML configuration files under
nvblox_examples/nvblox_examples_bringup/config
.
The base parameters are set in nvblox_base.yaml
and there exist
multiple specialization files that overwrite parameters from the
base file depending on which example is launched.
File tree:
config
├── nvblox
├── nvblox_base.yaml
└── specializations
├── nvblox_dynamics.yaml
├── nvblox_humans.yaml
├── nvblox_isaac_sim.yaml
└── nvblox_realsense.yaml
Loaded specializations for each example:
Launch file |
Specializations |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
General Parameters
ROS Parameter |
Type |
Default |
Description |
---|---|---|---|
|
|
|
The name of the TF frame in which the map built. For the RealSense examples, this parameter is exposed as a launch argument. |
|
|
|
Voxel size (in meters) to use for the map. |
|
|
|
Whether to use TF transforms at all. If set to false, |
|
|
|
Whether to listen to topics for transforms. If set to true, will try to get |
|
|
|
Whether to compute the ESDF (map of distances to the nearest obstacle). |
|
|
|
The rate (in Hz) at which to update the ESDF and output the distance slice. |
|
|
|
Whether to compute the ESDF in 2D (true) or 3D (false). |
|
|
|
Whether to output a distance slice of the ESDF to be used for path planning. |
|
|
|
The output slice height for the distance slice and ESDF pointcloud. Does not need to be within min and max height below. In units of meters. |
|
|
|
The minimum height, in meters, to consider obstacles part of the 2D ESDF slice. |
|
|
|
The maximum height, in meters, to consider obstacles part of the 2D ESDF slice. |
|
|
|
The minimum number of pixels of a connected component in the mask image to count as a dynamic detection. Otherwise the component is (optionally) removed. |
|
|
|
Whether to output a mesh for visualization in RViz, to be used with |
|
|
|
The rate (in Hz) at which to update and publish the mesh. |
|
|
|
Whether to integrate color images to color the mesh. |
|
|
|
The maximum rate (in Hz) at which to integrate color images into the color layer. A value of 0.0 means there is no cap. |
|
|
|
Whether to integrate depth images. |
|
|
|
The maximum rate (in Hz) at which to integrate depth images. A value of 0.0 means there is no cap. |
|
|
|
Whether to integrate LiDAR scans. |
|
|
|
The maximum rate (in Hz) at which to integrate LiDAR scans. A value of 0.0 means there is no cap. |
|
|
|
Width of the LIDAR scan, in number of beams. Default works for the VLP16. |
|
|
|
Height of the LIDAR scan, in number of beams. Default works for the VLP16. |
|
|
|
The vertical field of view of the LIDAR scan, in radians (assuming beams are centered around 0 elevation). Default is for the VLP16. |
|
|
|
Whether to use non equal vertical FoV for the LiDAR (not centered around 0 elevation). Should be set to false for a VLP16 and to true for Hesai PandarXT32. The LiDAR model will use the |
|
|
|
The angle below zero elevation of the lowest beam (specified as a positive number in radians). Default is for the Hesai PandarXT32. |
|
|
|
The angle above zero elevation of the highest beam (specified as a positive number in radians). Default is for the Hesai PandarXT32. |
|
|
|
The rate (in Hz) at which to publish the static occupancy pointcloud. |
|
|
|
The rate (in Hz) at which to decay the dynamic occupancy layer. |
|
|
|
Specifies what rate to poll the color & depth updates at. Will exit as no-op if no new images. Set this higher than you expect images to come in at. |
|
|
|
How many messages to store in the sensor messages queues (depth, color, lidar) before deleting oldest messages. |
|
|
|
Radius around the |
|
|
|
The name of the TF frame around which we clear the map. |
|
|
|
The rate (in Hz) at which we clear the map outside of the |
|
|
|
ROS 2 QoS string for the depth subscription. |
|
|
|
ROS 2 QoS string for the color subscription. |
|
|
|
ROS 2 QoS string for the pointcloud subscription. |
|
|
|
Only used if |
|
|
|
Frame to which the map slice bounds visualization is centered on the |
|
|
|
Side length of the map slice bounds visualization plane. |
Mapping Type Parameter
The nvblox node holds two individual mappers (contained in a multi-mapper object). Depth frames received by nvblox are passed to the multi-mapper and split into a static and dynamic part based on a mask image. While the static part is processed by the static_mapper, the dynamic part is handled by the dynamic_mapper.
Depending on the mapping_type
parameter these mappers update different layers:
static_tsdf
:static_mapper: mapping static obstacles using a TSDF layer
dynamic_mapper: disabled
static_occupancy
:static_mapper: mapping static obstacles using an occupancy layer
dynamic_mapper: disabled
dynamic
:static_mapper: mapping static obstacles using a TSDF layer and updating a freespace layer (needed for dynamic mapping)
dynamic_mapper: mapping dynamic obstacles in an occupancy layer
human_with_static_tsdf
:static_mapper: mapping static obstacles using a TSDF layer
dynamic_mapper: mapping humans in an occupancy layer
human_with_static_occupancy
:static_mapper: mapping static obstacles using an occupancy layer
dynamic_mapper: mapping humans in an occupancy layer
The mapping_type
must be specified as a string and defaults to static_tsdf
.
Note
The mapping types [static_tsdf
, static_occupancy
, dynamic
] are only
valid when running the nvblox_node
.
In contrast, the mapping types [human_with_static_tsdf
, human_with_static_occupancy
]
can only run with the nvblox_human_node
.
The nvblox_human_node
is adding additional topic subscriptions
for the mask image containing the human semantic segmentation.
Mapper Parameters
The static and dynamic mappers share the same parameter set.
By specifying the parent parameter name <mapper_name>
,
the parameters can be set for the corresponding mapper (i.e. static_mapper
or dynamic_mapper
).
ROS Parameter |
Type |
Default |
Description |
---|---|---|---|
|
|
|
Whether or not to run the preprocessing pipeline on the input depth image. Currently, this preprocessing only consists of dilating invalid regions in the input depth image. |
|
|
|
Number of times to run the invalid region dilation in the depth preprocessing pipeline (if |
|
|
|
The maximum distance, in meters, to integrate the depth or color image values. |
|
|
|
The maximum distance, in meters, to integrate the depth values for LiDAR scans. |
|
|
|
The truncation distance, in units of voxels, for the TSDF or occupancy map. |
|
|
|
The weighting mode, applied to TSDF and color integrations. Options: [ |
|
|
|
Maximum weight for the TSDF and color integrations. Setting this number higher will lead to higher-quality reconstructions but worse performance in dynamic scenes. |
|
|
|
The inverse sensor model occupancy probability for voxels observed as free space. |
|
|
|
The inverse sensor model occupancy probability for voxels observed as occupied. |
|
|
|
The inverse sensor model occupancy probability for unobserved voxels. |
|
|
|
Half the width of the region which is considered as occupied. |
|
|
|
Minimum weight of the TSDF to consider for inclusion in the ESDF. |
|
|
|
Maximum distance to compute the ESDF up to, in meters. |
|
|
|
Maximum distance to consider a voxel within a surface for the ESDF calculation. |
|
|
|
Minimum weight of the TSDF to consider for inclusion in the mesh. |
|
|
|
Whether to weld identical vertices together in the mesh. |
|
|
|
Decay factor that is applied to the TSDF weight when the TSDF decay is called. |
|
|
|
The decay probability that is applied to the free region on decay. Must be in |
|
|
|
The decay probability that is applied to the occupied region on decay. Must be in |
|
|
|
TSDF distance below which we assume a voxel to be occupied (non freespace). |
|
|
|
Maximum duration of no observed occupancy to keep consecutive occupancy alive. |
|
|
|
Minimum duration since last observed occupancy to consider voxel as free. |
|
|
|
Minimum duration of consecutive occupancy to turn a high confidence free voxel back to occupied. |
|
|
|
Whether to check the occupancy of the neighboring voxels for the high confidence freespace update. |
Note
Decay of the occupancy layer is needed to handle dynamic objects like humans. Without the decay observed dynamic objects stay in the map even if not seen for a long time period. In that time the object might have moved and the map is therefore invalid. Using the decay we simulate the loss of knowledge about parts of the dynamic map currently not observed over time.
Human Reconstruction Parameters
The mapping types [human_with_static_tsdf
, human_with_static_occupancy
] are executed using the nvblox_human_node
.
Below you find additional parameters that only exist for the nvblox_human_node
:
ROS Parameter |
Type |
Default |
Description |
---|---|---|---|
|
|
|
The rate (in Hz) at which to publish debug visualization for human mapping. |