You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a voxel image from the Blocks (1.8.1 Linux) release, if using a cube with dimensions greater than 250 (125 meters in each direction from origin) - then the voxel grid gives erroneous booleans. For example the images below show the floor and objects in the map when calling:
You can see holes in each. I am assuming this happens because I am using a cube outside of some preset rendering boundaries (can't simulate to infinity after all). However it is not intuitive to where the boundaries for each release are. If this is the case, then listing the valid dimensions of each release would be beneficial. Also, if the dimensions are not a cube I think voxels has some wonky behavior...
Here is what the images look like when calling with a valid working-range cube that I empirically found:
It's odd that if you use a cube outside of the valid range - that it causes holes within the valid range, as opposed to just not returning booleans for coordinates outside of the valid range. This raises concerns on not just the Voxels but how the simulation operates if the drone wanders somewhere outside of the 125x125x125 cube (rendering, collisions, stability). This might be a source of some instabilities I have been running into? Another problem for another time...
The text was updated successfully, but these errors were encountered:
I've seen very similar errors but have never had an issue with the agent becoming unstable very far away from the origin. I believe there is a core issue with their Voxel Grid calculation when not doing cubes.
Also, if you are using Numpy, the y axis is the first index (row major) which could cause issues with planning and the like.
Since AirSim is not longer being developed, we continued it here: Colosseum
I've been recently doing work with occupancy maps generated by the voxel grids with multi-agent, which you can see here (it's a longer video): Link. Works so far!
Bug report
What's the issue you encountered?
When creating a voxel image from the Blocks (1.8.1 Linux) release, if using a cube with dimensions greater than 250 (125 meters in each direction from origin) - then the voxel grid gives erroneous booleans. For example the images below show the floor and objects in the map when calling:
client.simCreateVoxelGrid((0,0,0), 300, 300, 300, 1, path).
floor:

objects:

You can see holes in each. I am assuming this happens because I am using a cube outside of some preset rendering boundaries (can't simulate to infinity after all). However it is not intuitive to where the boundaries for each release are. If this is the case, then listing the valid dimensions of each release would be beneficial. Also, if the dimensions are not a cube I think voxels has some wonky behavior...
Here is what the images look like when calling with a valid working-range cube that I empirically found:
client.simCreateVoxelGrid((0,0,0), 250, 250, 250, 1, path).
floor:

objects:

It's odd that if you use a cube outside of the valid range - that it causes holes within the valid range, as opposed to just not returning booleans for coordinates outside of the valid range. This raises concerns on not just the Voxels but how the simulation operates if the drone wanders somewhere outside of the 125x125x125 cube (rendering, collisions, stability). This might be a source of some instabilities I have been running into? Another problem for another time...
The text was updated successfully, but these errors were encountered: