-
Notifications
You must be signed in to change notification settings - Fork 915
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
[Question] Benchmarking FPS for camera rendering #100
Comments
Hi @sashwat-mahalingam , We checked the scripts and realized the numbers reported earlier on the website corresponded to the rendering frequency which didn't account for the overhead of reading the buffers and sending them to the camera buffers. The FPS you get currently is what we expect as well. We are waiting for the multi-camera support from Isaac Sim to provide better-quality numbers on camera rendering and reading out the data. Sorry for the confusion on this! |
# Description Earlier the `TerrainGeneratorCfg` and `TerrainImporterCfg` were in the same file. However, this leads to some issues with circular dependencies when referring to the `TerrainImporter` as an attribute of the `TerrainImporterCfg` (i.e. providing the class name as a member of the config object). The MR fixes the above circular dependency. Also, it moves all the terrain parameters to its configuration object to make the terrain initialization consistent with the other asset constructors. ## Type of change - Breaking change (fix or feature that would cause existing functionality to not work as expected) ## Checklist - [x] I have run the [`pre-commit` checks](https://pre-commit.com/) with `./orbit.sh --format` - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have updated the changelog and the corresponding version in the extension's `config/extension.toml` file
# Description Earlier the `TerrainGeneratorCfg` and `TerrainImporterCfg` were in the same file. However, this leads to some issues with circular dependencies when referring to the `TerrainImporter` as an attribute of the `TerrainImporterCfg` (i.e. providing the class name as a member of the config object). The MR fixes the above circular dependency. Also, it moves all the terrain parameters to its configuration object to make the terrain initialization consistent with the other asset constructors. ## Type of change - Breaking change (fix or feature that would cause existing functionality to not work as expected) ## Checklist - [x] I have run the [`pre-commit` checks](https://pre-commit.com/) with `./orbit.sh --format` - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have updated the changelog and the corresponding version in the extension's `config/extension.toml` file
I recently set up a simple reaching environment within ORBIT's
reach_env.py
class, adding one Pinhole camera into the environment and setting--num_envs 10
so each environment instance would have a Pinhole camera. When I profile this setup, I average 0.18 seconds per simulation step, equating to an FPS of10 / 0.18 = 55.5 FPS
. Having experimented with multiple values of--num_envs
between 1 and 20 (which is the maximum I can go to that exhausts my memory on my GPU), I am still stuck at this value - 0.18 seconds - for rendering 10 cameras per step.My workflow is, all within
reach_env.py
:env_0
namespace in the__init__
.Spawning is done in
design_scene()
asself.camera.spawn(self.template_env_ns + "/CameraSensor")
, right after the robot is spawned.In
initialize_views()
,initialize
each grid-cloned environment instance's camera within that grid-cloned environment's namespace, and update all camera buffers usingupdate
.sim.step()
is called in__init__
, I needed to callupdate
again else I would run intoNoneType
errors when trying to read the buffer later on.During
_step_impl()
, update each camera's buffer as described in step 3.To access camera observations, the observation manager invokes:
Is there any efficiency technique I am missing in my implementation here? Additionally, how was the implementation done for the benchmarking experiment that computed 270 FPS when having ten cameras record observations? Thanks!
The text was updated successfully, but these errors were encountered: