What's the realistic maximum size this can run on an Orin?

[SteveMacenski]

If I wanted to run navigation over this longer term, when does the performance of this system start to cap out or degrade?

If I set the costmap to a rolling window, is there a setting such that sufficiently old data is dropped so this can remain real-time after we hit the barrier?

[ashwinvkNV]

Yes there is params to enabling clearing the map, except a sphere in the nvblox map about a frame using the parameters:
map_clearing_radius_m
map_clearing_frame_id
clear_outside_radius_rate_hz

Details are here: https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_nvblox/isaac_ros_nvblox/api/parameters.html

Code is here: https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_nvblox/blob/main/nvblox_ros/src/lib/nvblox_node.cpp#L969

Note: As of this post the clearing is disabled by default

[SteveMacenski]

But any idea of what the cap of size is to remain retail in terms of the data size for some particular example?

[ashwinvkNV]

We cannot directly cap the memory usage by number of bytes. But @alexmillane or @remostei can elaborate on how to estimate the memory usage based on the nvblox configuration.

[SteveMacenski]

Sorry, I meant map / spatial size (ballpark: a hotel room, a hotel ballroom, an office floor, a warehouse, an airport), but I suppose I could back that out from bytes.

[alexmillane]

The limiting factor will be memory consumption. In the case of a 2D ESDF output (i.e. the ground robot navigation case), the dominating consumer of memory is the 3D TSDF which is 2 bytes/voxel. At 5cm voxels this is 64Kb/m3. The Orin can have 64Gb memory, but you probably don't want to use all of that for the map... Let's say you want to use 16Gb for the map. That's 250000m3. Let's say with ~3m high ceilings that's ~80000m2 floor area. I guess that's a small warehouse? Would you agree? This analysis ignores that we only allocate memory in observed space, which is likely to approximately double that number.

With all of that said, at the moment, we're intending for nvblox to be used for local mapping. In our forthcoming release, a combination of voxel decay and cropping the map outside of a radius will be turned on by default and will limit map growth beyond the robot's vicinity.

[SteveMacenski]

Got it. 16gb would be pretty extreme, I'd say less than half of that would be still bordering on unreasonable. I doubt we could actually populate and maintain that much data in a real-time update basis separate of the data storage requirements. I'm a little surprised that no one has a general ballpark based on testing (but I appreciate the ballpark on memory!) - might be something worth trying out in the lab / NV floor to see when the performance sputters out of real-time as something to communicate to users for their reference. Might be a nice friday afternoon task

[alexmillane]

Because of how we do the updates, the compute requirements do not scale with the size of the map. Each update only affects the parts of the map in view (plus a bit extra because the ESDF propagates outwards from these areas). You're right though that we should collect experimental evidence to back this claim up. However, like I said our intent at present is that nvblox is used for local mapping, because that's how we're using it.

The main reason that would stop one from using nvblox for online global mapping, is that there's no mechanism in nvblox to account for updates to past poses, like what happens in a loop closure, a global localization, or a bundle adjustment etc. Ironically, I've spent a fair amount of time working on that problem (see for example voxgraph ) but we haven't incorporated that approach here. Our approach thus far has been to have an offline global map, and then do real-time perception locally.

[SteveMacenski]

However, like I said our intent at present is that nvblox is used for local mapping, because that's how we're using it.

Sure, but that size still is relevent to local mapping. If I have a roomba in my apartment, its unlikely to hit that limit. If I have a tractor moving in a field, that's alot of space to update in its open field view. If I have a robot moving at 10m/s in some high speed application, it could be seeing alot of stuff.

Understanding the window size limitations on the Orin is relevant information for alot of application designers. Not just for trying to push the bounds for 'typical' warehouse applications :-)

A global approach would obviously be quite ideal - to have something global of this quality, but I think that update and managing that much information would cause some problems, but maybe/hopefully/possibly solvable or solved! That would be worth investing in, I think, which could be used to generate 2D occupancy grids, 3D meshes for manipulation and many others