Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
SteveMacenski opened this issue Feb 29, 2024 · 8 comments
Open

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

SteveMacenski opened this issue Feb 29, 2024 · 8 comments
Assignees

Comments

@SteveMacenski
Copy link

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?

@rbonghiNV rbonghiNV assigned rbonghiNV and alexmillane and unassigned rbonghiNV Mar 6, 2024
@ashwinvkNV
Copy link

ashwinvkNV commented Mar 6, 2024

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
Copy link
Author

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

@ashwinvkNV
Copy link

ashwinvkNV commented Mar 6, 2024

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
Copy link
Author

SteveMacenski commented Mar 6, 2024

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

SteveMacenski commented Mar 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants