RadarReturn: clarify order of angles

[tobiasneumann]

The current description for the azimuth and elevation angles doesn't directly specify the order of these angles.
From the comment for elevation "For 2D radar, this will be 0." the order can be deducted, but it could be clearer.

Proposed change

• Add the description that the angles are supposed to be used as "elevation-over-azimuth"

[SteveMacenski]

Move next to rest of the comments.

Also, these are single-values (float32), how is there any ordering? What does "elevation over azimuth" mean? This is not immediately clear.

[tobiasneumann]

Move next to rest of the comments.

done

Also, these are single-values (float32), how is there any ordering? What does "elevation over azimuth" mean? This is not immediately clear.

The comment is regarding how the 2 angles elevation and azimuth are supposed to be used.
Depending on the order of how these values are applied a different point is described.

The comment For 2D radar, this will be 0 already only allows the order "elevation over azimuth", but this is very indirect and I wanted to clarify this.

[SteveMacenski]

I don't understand the necessity for clarification. Why is this important? And if it is, is there a standard that can be named / linked?

[MRQ]

Hello together,
I was working with @tobiasneumann on the specification of this pull request.

how is there any ordering? […]
I don't understand the necessity for clarification. Why is this important?

When rotating multiple angles in a 3D space, there is always a rotation hierarchy:
You start with the world reference frame and rotate it around one of its axis. After that you obtain another reference frame. In this you rotate the next angle around the next axis.

The difference between the hierarchies can also be seen at the construction of antenna positioners: Azimuth over Elevation and Elevation over Azimuth.

Our proposal defines the position of a return as Rot(azimuth, z) * Rot(-elevation, y) * (range, 0, 0). Flattened version:

x = range * cos(azimuth) * cos(elevation)
y = range * sin(azimuth) * cos(elevation)
z = range * sin(elevation)

And if it is, is there a standard that can be named / linked?

I don't know if this has been formally specified.

[SteveMacenski]

Can we try to root this in some kind of standard / convention? I understand the point this is making and I believe that is how this is already used, but it would be nice if that policy was based on some kind of standard / convention that we can point to from 3D lidar manufacturers, named coordinate system using this convention, etc

[tobiasneumann]

I'm not aware of standard for this.

If you want to break it down maybe the following helps.

• azimuth-over-elevation: can be seen as a 2D sensor that is scanning the in x/y plane (mirror is rotating around yaw or z-axis).
  And this sensor is mounted on a tilting platform that moves the sensor around the x/z (or y/z, doesn't makes a difference) plane, so whole 2D sensor is rotated around the pitch or y-axis.
• elevation-over-azimuth: Can be seen as a 2D sensor that is scanning in the x/z plane (like it is lying on its side).
  And then is rotated additionally around the yaw or z-axis.

When a 2D sensor is moved to scan in 3D, azimuth-over-elevation, might be the first intuitive mounting method and the first paper that did that also choose these mountings.
Modern sensors like FARO Focus or RIEGL VZ and also velodyne (the non solit state once) however seem to be build for elevation-over-azimuth .