Merge branch 'master' into FreeBoundaryDefinition

pmai · web-flow · commit 363064d63622 · 2025-04-10T10:26:57.000+02:00
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -13,8 +13,8 @@ How has it been tested?
 #### Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:
 - [ ] My suggestion follows the [style and contributors guidelines](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/start_contributing.html).
 - [ ] I have taken care about the [message documentation](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/commenting_messages.html) and the [fields and enums documentation](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/commenting_fields_enums.html).
-- [ ] I have done the [DCO signoff](https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/howtocontribute.html#developer-certification-of-origin-dco).
-- [ ] My changes generate no errors when passing CI tests. 
+- [ ] I have done the [DCO signoff](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/dco.html).
+- [ ] My changes generate no errors when passing CI tests.
 - [ ] I have successfully implemented and tested my fix/feature locally.
 - [ ] Appropriate reviewer(s) are assigned.
 
diff --git a/.github/workflows/protobuf.yml b/.github/workflows/protobuf.yml
@@ -97,7 +97,7 @@ jobs:
 
     - name: Get git Version
       id: get_version
-      run: echo "VERSION=$(git describe --tags --always)" >> $GITHUB_OUTPUT 
+      run: echo "VERSION=$(git describe --tags --always)" >> $GITHUB_OUTPUT
 
     - name: Prepare Documentation Build
       run: |
@@ -122,28 +122,13 @@ jobs:
     - name: Run Python Tests
       run: python -m unittest discover tests
 
-    - name: Archive Documentation
-      if: ${{ github.event_name == 'pull_request' }}
-      uses: actions/upload-artifact@v4
-      with:
-        name: linux64-doc
-        path: doc/html
-        if-no-files-found: error
-
     - name: Upload Python Distribution
       if: ${{ github.event_name == 'pull_request' || ( github.event_name == 'push' && ( github.ref == 'refs/heads/master' || startsWith(github.ref, 'refs/tags/v') ) ) }}
       uses: actions/upload-artifact@v4
       with:
         name: python-dist
         path: dist/
 
-    - name: Deploy to gh-pages if push to master branch
-      if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/master' }}
-      uses:  peaceiris/actions-gh-pages@v3
-      with:
-        github_token: ${{ secrets.GITHUB_TOKEN }}
-        publish_dir: ./doc/html
-
   build-proto3-linux64:
     name: Build Proto3 Linux 64
 
diff --git a/doc/architecture/architecture_overview.adoc b/doc/architecture/architecture_overview.adoc
@@ -4,11 +4,21 @@ include::{root-path}_config.adoc[]
 endif::[]
 = Overview of OSI architecture
 
-OSI contains an object-based environment description that uses the message format of the https://github.com/protocolbuffers/protobuf/wiki[Protocol Buffer] library.
-Google developed and maintains the Protocol Buffer library.
+OSI contains an object-based environment description that uses the message format of the https://github.com/protocolbuffers/protobuf/wiki[Protocol Buffer^] library developed by Google.
 OSI defines top-level messages that are used to exchange data between separate models.
-Top-level messages define the `GroundTruth` interface, the `SensorData` interface, and – since OSI version 3.0.0 – the interfaces `SensorView` and `SensorViewConfiguration`.
-Further top-level messages that were added in later versions of OSI are `HostVehicleData`, `TrafficCommand`, `TrafficCommandUpdate`, `TrafficUpdate`, `MotionRequest`, and `StreamingUpdate`.
+
+Top-level messages define the following interfaces:
+
+- xref:architecture/ground_truth.adoc[`GroundTruth`]
+- xref:architecture/sensor_data.adoc[`SensorData`]
+- xref:architecture/sensor_view.adoc[`SensorView`]
+- xref:architecture/sensor_view_configuration.adoc[`SensorViewConfiguration`]
+- xref:architecture/host_vehicle_data.adoc[`HostVehicleData`]
+- xref:architecture/traffic_command.adoc[`TrafficCommand`]
+- xref:architecture/traffic_command_update.adoc[`TrafficCommandUpdate`]
+- xref:architecture/traffic_update.adoc[`TrafficUpdate`]
+- xref:architecture/motion_request.adoc[`MotionRequest`]
+- xref:architecture/streaming_update.adoc[`StreamingUpdate`].
 
 The following figure shows the interfaces and models involved in modeling a sensor.
 
diff --git a/doc/architecture/ground_truth.adoc b/doc/architecture/ground_truth.adoc
@@ -6,4 +6,6 @@ endif::[]
 
 `GroundTruth` messages describe the simulated environment containing all simulated objects in the global coordinate system at consecutive time instances.
 They are based on data available to the simulation environment.
-`GroundTruth` messages are typically contained in `Sensorview` messages.
+`GroundTruth` messages are typically contained in `Sensorview` messages.
+
+For more details, see xref:gen:structosi3_1_1GroundTruth.adoc[].
diff --git a/doc/architecture/host_vehicle_data.adoc b/doc/architecture/host_vehicle_data.adoc
@@ -0,0 +1,12 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+endif::[]
+= Host vehicle data
+
+The `HostVehicleData` message targets the perception of the vehicle of its own internal states.
+
+It captures the knowledge the vehicle has internally, which can differ from the actual or global truth for various reasons.
+This message can also be understood as an interface container for the signals of a rest bus simulation.
+
+For more details, see xref:gen:structosi3_1_1HostVehicleData.adoc[].
diff --git a/doc/architecture/motion_request.adoc b/doc/architecture/motion_request.adoc
@@ -5,4 +5,6 @@ endif::[]
 = Motion Request
 
 `MotionRequest` messages are traffic participant internal messages.
-They function as a interface between a motion/behavior planning model and a dynamics model including, for example, controllers and vehicle kinematics.
+They function as a interface between a motion/behavior planning model and a dynamics model including, for example, controllers and vehicle kinematics.
+
+For more details, see xref:gen:structosi3_1_1MotionRequest.adoc[].
diff --git a/doc/architecture/sensor_data.adoc b/doc/architecture/sensor_data.adoc
@@ -13,3 +13,5 @@ Sensor data can be used as input for an automated driving function, a sensor mod
 `SensorData` messages include `FeatureData` messages which contain detected features in the reference frame of a sensor.
 `FeatureData` messages are generated from `GroundTruth` messages.
 They serve, for example, as an input to sensor models simulating object detection or feature fusion models.
+
+For more details, see xref:gen:structosi3_1_1SensorData.adoc[].
diff --git a/doc/architecture/sensor_view.adoc b/doc/architecture/sensor_view.adoc
@@ -10,4 +10,6 @@ All information regarding the environment is given with respect to the virtual s
 
 * Physical technology-specific data, given with respect to the physical sensor coordinate system specified in the corresponding physical sensor's mounting position.
   One example of technology-specific data is: xref:gen:structosi3_1_1CameraSensorView.adoc#ac58456a34babf78792ea2608eb963f36[`image_data` of `osi3::CameraSensorView`]
-* Ground truth given in the global coordinate system.
+* Ground truth given in the global coordinate system.
+
+For more details, see xref:gen:structosi3_1_1SensorView.adoc[].
diff --git a/doc/architecture/sensor_view_configuration.adoc b/doc/architecture/sensor_view_configuration.adoc
@@ -35,4 +35,6 @@ In response to this difference, the sensor model can either accept this differen
 
 The packaging layer defines the specifics of this auto-negotiation mechanism.
 
-After the initialization phase, the environment simulation provides the actual sensor-view configuration as part of each `SensorView` message.
+After the initialization phase, the environment simulation provides the actual sensor-view configuration as part of each `SensorView` message.
+
+For more details, see xref:gen:structosi3_1_1SensorViewConfiguration.adoc[].
diff --git a/doc/architecture/streaming_update.adoc b/doc/architecture/streaming_update.adoc
@@ -7,4 +7,6 @@ endif::[]
 The `StreamingUpdate` message provides an interface to transmit a subset of ground truth and/or vehicle internal data.
 This interface mainly addresses applications with low latency requirements and no need for highly consistent and complete data, e.g. visualization applications.
 Static and/or non-relevant objects can be omitted as required for the specific use case.
-Note that the receiver of partial updates can only rely on the most up-to-date information at the corresponding timestamp. E.g. omitting objects does not indicate static behaviour but it may be sufficient for the use case to update certain objects at a later point in time.
+Note that the receiver of partial updates can only rely on the most up-to-date information at the corresponding timestamp. E.g. omitting objects does not indicate static behavior but it may be sufficient for the use case to update certain objects at a later point in time.
+
+For more details, see xref:gen:structosi3_1_1StreamingUpdate.adoc[].
diff --git a/doc/architecture/traffic_command.adoc b/doc/architecture/traffic_command.adoc
@@ -4,4 +4,6 @@ include::{root-path}_config.adoc[]
 endif::[]
 = Traffic command
 
-`TrafficCommand` messages contain control commands from the scenario engine to traffic participant models.
+`TrafficCommand` messages contain control commands from the scenario engine to traffic participant models.
+
+For more details, see xref:gen:structosi3_1_1TrafficCommand.adoc[].
diff --git a/doc/architecture/traffic_command_update.adoc b/doc/architecture/traffic_command_update.adoc
@@ -0,0 +1,9 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+endif::[]
+= Traffic command update
+
+`TrafficCommandUpdate` messages enable the traffic participant model to send updates to the scenario engine about the execution of its received xref:architecture/traffic_command.adoc[TrafficCommand] input.
+
+For more details, see xref:gen:structosi3_1_1TrafficCommandUpdate.adoc[].
diff --git a/doc/architecture/traffic_update.adoc b/doc/architecture/traffic_update.adoc
@@ -5,4 +5,6 @@ endif::[]
 = Traffic update
 
 `TrafficUpdate` messages are provided by traffic participants.
-They provide updates on the position, state, and future trajectory of a traffic participant back to the simulation environment.
+They provide updates on the position, state, and future trajectory of a traffic participant back to the simulation environment.
+
+For more details, see xref:gen:structosi3_1_1TrafficUpdate.adoc[].
diff --git a/doc/open-simulation-interface_user_guide.adoc b/doc/open-simulation-interface_user_guide.adoc
@@ -21,8 +21,12 @@ include::./architecture/sensor_view_configuration.adoc[leveloffset=+3]
 
 include::./architecture/sensor_data.adoc[leveloffset=+3]
 
+include::./architecture/host_vehicle_data.adoc[leveloffset=+3]
+
 include::./architecture/traffic_command.adoc[leveloffset=+3]
 
+include::./architecture/traffic_command_update.adoc[leveloffset=+3]
+
 include::./architecture/motion_request.adoc[leveloffset=+3]
 
 include::./architecture/traffic_update.adoc[leveloffset=+3]
diff --git a/open_simulation_interface-config.cmake.in b/open_simulation_interface-config.cmake.in
@@ -6,5 +6,5 @@ find_dependency(Protobuf)
 if(NOT TARGET @PROJECT_NAME@ AND NOT @PROJECT_NAME@_BINARY_DIR)
   set_and_check(OPEN_SIMULATION_INTERFACE_INCLUDE_DIRS "@PACKAGE_OSI_INSTALL_INCLUDE_DIR@")
   set(OPEN_SIMULATION_INTERFACE_LIBRARIES "@PROJECT_NAME@")
-  include("${CMAKE_CURRENT_LIST_DIR}/open_simulation_interface_targets.cmake")
+  include("${CMAKE_CURRENT_LIST_DIR}/open_simulation_interface-targets.cmake")
 endif()
diff --git a/osi_version.proto.in b/osi_version.proto.in
@@ -25,10 +25,7 @@ package osi3;
 // properly set the version components prior to sending.
 //
 // Increments will happen as part of changes to the whole interface.
-// The meaning of different InterfaceVersions is defined in [1].
-//
-// \par Reference:
-// [1] Open Simulation Interface. (2020, January 25). <em>README</em>. Retrieved January 25, 2020, from https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/README.html
+// The meaning of different InterfaceVersions is defined in the versioning chapter of the official OSI documentation.
 //
 message InterfaceVersion
 {
