Slope in downhills

Hi,

I am using a ZED 2i to calculate slopes of some floors. I have they real slope measured with a level.

I have noticed that, always that the slope is positive, the calculation is fine, however, if i rotate the surface to make the slope go down, the calculation is wrong.

This happens almost always, is this a limitation of the camera?

Hi @CristianViSa
can you please record an SVO with ZED Explorer and share your code so we can test and debug it in the same conditions?

You can send the material to support@stereolabs.com if you do not want to share it publicly.

Hi, sorry for the late response, i was on vacations.

Here you can see my svo2 on a WeTransfer link. WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

In the frames where the slope is Upwards, the slope is perfect, howerver, when it goes Downwards is wrong.

With a level, the slope is 7.5º.

My code is simple, i just simply read the cloud points, rotate them using YZX convention and then i use a cloud point viewer (potree) to calculate the slope.

My guess is i am doing something wrong with the rotation, maybe the angles? maybe the order?

Here is my .py
slope.py (4.9 KB)

Request #54242 “Slope calculation using ZED 2i i…” was closed and merged into this request. Last comment in request #54242:

Hi, I recently wrote a post on your forum asking for help about calculating slopes in downhills. I was asked to upload an svo so you could test it on same conditions but I had no response, so I send this email.

I am using this camera to measure the slope of terrains. I attach my .py file so you can use it if you need. The script act as follows:

Read SVO
*
Obtain XYZ Angles of rotation
*
Rotate the cloud point this angels to make it “straight” in YZX order
*
Export Rotated PC to LAZ format

Then i use a cloud point viewer (potreehttps://github.com/potree/potree) to see the cloud point and obtain the points for slope calculation (distance in height / distance in horizontal) * 100.

The thing is, when the slope goes upwards, it matches perfectly with reality. In the SVO I attach via drive link, the slope that can be seen from frames 1080 to 1500 is 7.5º measured with a level.

However, when it goes downwards, the slope DOES NOT MATCH REALITY, I obtain 3º of slope.

Is this a limitation of the camera? or am I doing something wrong? Maybe the rotation angles, i use the orientation angles of the camera to straight the cloud point, is this de correct angle process?

Thanks in advance

SVO2 Video:https://drive.google.com/file/d/1VdMA1NKcC7dEWgIJyqzNCrY1FTmAkQJP/view?usp=sharing

Un saludo,

[cid:0f19f013-fcea-4999-b2a8-e02c5b534559]https://app.businesscards.eco/e/dd10pe/full
Outlook-c4hvcvl1.png
Slope_Calc.zip

Hi Cristian,

I sincerely apologize for the late reply.

The ZED SDK has a parameter in its API that allows to directly transform the 3D data (e.g. point cloud, object detection boxes, etc) in the WORLD reference frame, which is what you are trying to do by rotating the point cloud using the positional tracking.
Can you export the point cloud with this parameter RuntimeParameters.measure3d_reference_frame set to REFERENCE_FRAME.WORLD, and remove your point cloud rotations? This way we can make sure that the correct rotations are applied.
(You may require to set the translation to identity)

Best,
Matthew Rousseau

Stereolabs Support

Hi,

No worries. I have tried to set it as said, but with this parameter i obtain wrong values for both cases.

When going upwards i obtain slope values around 0.5º to 1.5º (Reality is 7º)
When going downards i obtain slope values around 2.5º and 3º

Here is the code, i just update the reference frame in the RuntimeParameters and remove rotations.

slope_world.py (5.3 KB)

Hi @CristianViSa,

I see that you set the set_gravity_as_origin to false in your sample, have you tried with it set to true?

As the floor plane estimation may change for each camera startup, having the gravity as origin may return a more robust world rotation and give you a better slope angle.