-
Notifications
You must be signed in to change notification settings - Fork 129
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
Fix documentation on coordinate systems and transformations #723
Fix documentation on coordinate systems and transformations #723
Conversation
|
||
``SensorData::mounting_position``:: | ||
This field defines the sensor's position and orientation and thereby the origin of the sensor coordinate system. | ||
The mounting position is given in the vehicle coordinate system. | ||
This field defines the sensor's virtual mounting position and orientation and thereby the origin of the virtual sensor coordinate system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just say "mounting position" instead of "virtual mounting position"? Has the virtual some special meaning hiere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to emphasize the distinction between physical and virtual mounting positions so that they do not get confused. The SensorData::mounting_position is virtual/"imaginary", while SensorDetectionHeader::mounting_position is referring to the actual physical mp of a detector. The OSI class reference docs also describe the SensorData::mounting_position as "virtual mounting position".
I just tried to align/unify terms so far. But I think it would make sense to also add an explanation of the physical mounting position in this section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as a side-note: For OSI 4.0 it would be a good idea to name the fields accordingly.
@@ -91,19 +91,19 @@ In Open Simulation Interface, an object's position is defined by the coordinates | |||
This field defines the orientation of the vehicle's reference point in global coordinates. | |||
|
|||
``GroundTruth::moving_object::vehicle_attributes::bbcenter_to_rear``:: | |||
This field specifies the vector pointing from the vehicle's reference point to the middle of the rear axle under neutral load conditions in the vehicle coordinates. | |||
This field specifies the vector pointing from the vehicle's reference point to the middle of the rear axle under neutral load conditions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "vehicle reference point" is the center of the bounding box, right? Therefore, i would suggest to call it object reference point to have it in a similar naming, than the object coordinate system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we could do that. Though, this section only describes the messages in the context of a vehicle so I tried to not change even more things except for the necessary parts.
We could also extend or partly generalize this section for other objects. We should just make sure to adapt all occurrences of "vehicle reference point". This term is used all over the OSI class reference documentation.
Harmonization group meeting result:
|
CCB 2023-06-12: Merge as-is. |
Signed-off-by: Thomas Sedlmayer <[email protected]>
- Add definition of host vehicle coordinate system - Fix multiple bugs in coordinate transformation chapter - Replace example figure that shows wrong phys. mounting pos. reference Signed-off-by: Thomas Sedlmayer <[email protected]>
e0dcbcc
to
3494001
Compare
This PR fixes some issues with the documentation on coordinate systems and transformations.
I've tested the Antora documentation build locally.
Feel free to add any thoughts.
Checklist: