From a042d7a93897dffb2f322c6b69cb23b6d5f268b7 Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Mon, 7 Nov 2022 10:08:08 +0100 Subject: [PATCH 01/11] Add new message for BoundingBox sub-sections --- osi_common.proto | 68 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/osi_common.proto b/osi_common.proto index 3243a37a7..fb16cddee 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -387,6 +387,68 @@ message LogicalLaneAssignment optional double angle_to_lane = 4; } +// +// Note: The parent bounding box of the base object should not be setup as a BoundingBox, use the dimension field of the message for this (make this clear in a support image) +message BoundingBox +{ + // The 3D dimensions of the bounding box. + // + optional Dimension3d dimension = 1; + + // The 3D position of the bounding box. + // + // TODO: Make sure this is clear that the position is "absolute" to the GT frame + optional Vector3d position = 2; + + // TODO: make sure this is clear, the parent frame is intended to mean the GT frame for this use-case + // The relative orientation of the bounding box w.r.t. its parent + // frame, noted in the parent frame. The orientation becomes global/absolute + // if the parent frame is inertial (all parent frames up to ground truth). + // + // \f$ Origin_{\text{base stationary entity}} := + // Rotation_{yaw,pitch,roll}( \f$ \c #orientation \f$ )* + // (Origin_{\text{parent coord system}} - + // \f$ \c #position \f$ )\f$ + // + // + optional Orientation3d orientation = 3; + + // The type of object contained in the bounding box. + // + optional TYPE contained_object_type = 4; + + // Opaque reference of an associated 3D model of the bounding box. + // + // \note It is implementation-specific how model_references are resolved to + // 3d models. + // + // TODO: Do we want to offer general guidelines regarding the origin of the 3d model vs the BoundingBox pos, Object pos, etc. + // + optional string model_reference = 5; + + // TODO: See if this can be aligned to the way other OSI enums are named + enum Type + { + // General stuff + TYPE_UNKNOWN = 0; + TYPE_OTHER = 1; + + // Car stuff + TYPE_CHASIS = 2; + TYPE_DOOR = 3; + TYPE_SIDEMIRROR = 4; + TYPE_CARGO = 5; + + // People/animal stuff + // TODO: Those interested in pedestrian modeling need to add their input here + TYPE_TORSO = 6; + TYPE_LIMB = 7; + TYPE_HEAD = 8; + + // TODO: Do we want to handle data for BaseStationary here as well? What problems would having this solve? + } +} + // // \brief The base attributes of a stationary object or entity. // @@ -569,6 +631,12 @@ message BaseMoving // The polygon is defined counter-clockwise. // repeated Vector2d base_polygon = 7; + + // Sub-divisions of the overall bounding box of the BaseMoving object. + // + // \note The bounding box sections can include side mirrors for vehicles. + // + repeated BoundingBox bounding_box_section = 9; } // From 41bb5d0d000b35ee8db4c8b3f49ed3c019fe5ad7 Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Mon, 21 Nov 2022 10:09:23 +0100 Subject: [PATCH 02/11] Fix typos, extend comment --- osi_common.proto | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/osi_common.proto b/osi_common.proto index fb16cddee..2f7f80bc9 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -415,7 +415,7 @@ message BoundingBox // The type of object contained in the bounding box. // - optional TYPE contained_object_type = 4; + optional Type contained_object_type = 4; // Opaque reference of an associated 3D model of the bounding box. // @@ -434,7 +434,7 @@ message BoundingBox TYPE_OTHER = 1; // Car stuff - TYPE_CHASIS = 2; + TYPE_CHASSIS = 2; TYPE_DOOR = 3; TYPE_SIDEMIRROR = 4; TYPE_CARGO = 5; @@ -634,7 +634,8 @@ message BaseMoving // Sub-divisions of the overall bounding box of the BaseMoving object. // - // \note The bounding box sections can include side mirrors for vehicles. + // \note The bounding box sections can include side mirrors, cargo, etc. + // for vehicles, as well as body-part sections for pedestrians. // repeated BoundingBox bounding_box_section = 9; } From e0b7c21987d293fc365cec9007d31c33442cf34d Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Thu, 1 Dec 2022 16:20:35 +0100 Subject: [PATCH 03/11] Add comments and update formatting --- osi_common.proto | 127 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 95 insertions(+), 32 deletions(-) diff --git a/osi_common.proto b/osi_common.proto index 2f7f80bc9..656891e81 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -387,8 +387,14 @@ message LogicalLaneAssignment optional double angle_to_lane = 4; } -// -// Note: The parent bounding box of the base object should not be setup as a BoundingBox, use the dimension field of the message for this (make this clear in a support image) +// \brief A bounding box containing a sub-section of a object. +// +// A bounding box representing a sub-section of it's parents overall dimension, +// either that of a \c MovingObject or \c StationaryObject . +// +// The parent frame of the \c BoundingBox is not relative to the parent object +// it is associated to, but in the same parent frame as the parent object. +// message BoundingBox { // The 3D dimensions of the bounding box. @@ -397,55 +403,94 @@ message BoundingBox // The 3D position of the bounding box. // - // TODO: Make sure this is clear that the position is "absolute" to the GT frame + // \note The position should be within the same coordinate frame as it's + // parent, not relative to coordinate frame of the parent object. The + // position becomes global/absolute if the parent frame is inertial + // (all parent frames up to ground truth). + // optional Vector3d position = 2; - // TODO: make sure this is clear, the parent frame is intended to mean the GT frame for this use-case - // The relative orientation of the bounding box w.r.t. its parent - // frame, noted in the parent frame. The orientation becomes global/absolute - // if the parent frame is inertial (all parent frames up to ground truth). - // - // \f$ Origin_{\text{base stationary entity}} := - // Rotation_{yaw,pitch,roll}( \f$ \c #orientation \f$ )* - // (Origin_{\text{parent coord system}} - - // \f$ \c #position \f$ )\f$ + // The 3D orientation of the bounding box. // + // \note The orientation should be within the same coordinate frame as it's + // parent, not relative to coordinate frame of the parent object. The + // orientation becomes global/absolute if the parent frame is inertial + // (all parent frames up to ground truth). // optional Orientation3d orientation = 3; // The type of object contained in the bounding box. // - optional Type contained_object_type = 4; + optional Type contained_object_type = 4; // Opaque reference of an associated 3D model of the bounding box. // // \note It is implementation-specific how model_references are resolved to - // 3d models. - // - // TODO: Do we want to offer general guidelines regarding the origin of the 3d model vs the BoundingBox pos, Object pos, etc. + // 3d models. This means the coordinate system, model origin, and model + // orientation are also implementation-specific. // optional string model_reference = 5; - // TODO: See if this can be aligned to the way other OSI enums are named + // Definition of different types of object contained within the bounding box + // enum Type { - // General stuff + // Object of unknown type (must not be used in ground truth). + // TYPE_UNKNOWN = 0; + + // Any other type of object. + // TYPE_OTHER = 1; - // Car stuff + // The main chassis of a vehicle. + // TYPE_CHASSIS = 2; + + // The door of a vehicle. + // TYPE_DOOR = 3; - TYPE_SIDEMIRROR = 4; + + // The side mirror of a vehicle. + // + TYPE_SIDE_MIRROR = 4; + + // Additional cargo attached to the a vehicle which is temporarily + // attached. + // TYPE_CARGO = 5; - - // People/animal stuff - // TODO: Those interested in pedestrian modeling need to add their input here - TYPE_TORSO = 6; - TYPE_LIMB = 7; - TYPE_HEAD = 8; - - // TODO: Do we want to handle data for BaseStationary here as well? What problems would having this solve? + + // The wheel of a vehicle. + // + TYPE_WHEEL = 6; + + // The torso section of a person or animal. + // + TYPE_TORSO = 7; + + // An external limb of a person or animal. + // + TYPE_LIMB = 8; + + // The head of a person or animal. + // + TYPE_HEAD = 9; + + // The trunk section of a tree. + // + TYPE_TREE_TRUNK = 10; + + // The crown of a tree, usually encompassing the branches and leaves. + // + TYPE_TREE_CROWN = 11; + + // The vertical pole of a street light. + // + TYPE_STREET_LIGHT_POLE = 12; + + // The horizontal arm of a street light. + // + TYPE_STREET_LIGHT_ARM = 13; } } @@ -509,6 +554,17 @@ message BaseStationary // The polygon is defined counter-clockwise. // repeated Vector2d base_polygon = 4; + + // Sub-divisions of the overall bounding box of the \c BaseStationary object. + // + // The bounding box sections can include separate parts on partially-opaque + // objects such are trees with a distinction between trunk and crown. + // + // \note When one or more \c BoundingBox s are associated to a + // \c BaseStationary , the expectation is that all sections are contained + // within the bounds of the \c #dimension . + // + repeated BoundingBox bounding_box_section = 5; } // @@ -610,6 +666,7 @@ message BaseMoving // \f$ \c #orientation_rate \f$ .roll(t-dt) \f$ // optional Orientation3d orientation_acceleration = 8; + // Usage as ground truth: // The two dimensional (flat) contour of the object. This is an extension of @@ -631,11 +688,17 @@ message BaseMoving // The polygon is defined counter-clockwise. // repeated Vector2d base_polygon = 7; - - // Sub-divisions of the overall bounding box of the BaseMoving object. + + // Sub-divisions of the overall bounding box of the \c BaseMoving object. + // + // The bounding box sections can include side mirrors, cargo, etc. for + // vehicles, as well as body-part sections for pedestrians. // - // \note The bounding box sections can include side mirrors, cargo, etc. - // for vehicles, as well as body-part sections for pedestrians. + // \note When one or more \c BoundingBox s are associated to a + // \c BaseMoving , the expectation is that all sections are contained + // within the bounds of the \c #dimension . Currently there several accepted + // exceptions to this rule, specifically the sub-sections for cargo, vehicle + // side mirrors, and doors not in the their closed position. // repeated BoundingBox bounding_box_section = 9; } From 60f0e59b87060a08bbb89f93ac3fb0194f700b53 Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Thu, 1 Dec 2022 16:21:31 +0100 Subject: [PATCH 04/11] Remove extra blank line --- osi_common.proto | 1 - 1 file changed, 1 deletion(-) diff --git a/osi_common.proto b/osi_common.proto index 656891e81..37b24bdb2 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -666,7 +666,6 @@ message BaseMoving // \f$ \c #orientation_rate \f$ .roll(t-dt) \f$ // optional Orientation3d orientation_acceleration = 8; - // Usage as ground truth: // The two dimensional (flat) contour of the object. This is an extension of From a9e947baf4603527b2389dc258e81c3805d62b4b Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Mon, 7 Nov 2022 10:08:08 +0100 Subject: [PATCH 05/11] Add new message for BoundingBox sub-sections Signed-off-by: Nicholas Dunning --- osi_common.proto | 68 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/osi_common.proto b/osi_common.proto index 3243a37a7..fb16cddee 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -387,6 +387,68 @@ message LogicalLaneAssignment optional double angle_to_lane = 4; } +// +// Note: The parent bounding box of the base object should not be setup as a BoundingBox, use the dimension field of the message for this (make this clear in a support image) +message BoundingBox +{ + // The 3D dimensions of the bounding box. + // + optional Dimension3d dimension = 1; + + // The 3D position of the bounding box. + // + // TODO: Make sure this is clear that the position is "absolute" to the GT frame + optional Vector3d position = 2; + + // TODO: make sure this is clear, the parent frame is intended to mean the GT frame for this use-case + // The relative orientation of the bounding box w.r.t. its parent + // frame, noted in the parent frame. The orientation becomes global/absolute + // if the parent frame is inertial (all parent frames up to ground truth). + // + // \f$ Origin_{\text{base stationary entity}} := + // Rotation_{yaw,pitch,roll}( \f$ \c #orientation \f$ )* + // (Origin_{\text{parent coord system}} - + // \f$ \c #position \f$ )\f$ + // + // + optional Orientation3d orientation = 3; + + // The type of object contained in the bounding box. + // + optional TYPE contained_object_type = 4; + + // Opaque reference of an associated 3D model of the bounding box. + // + // \note It is implementation-specific how model_references are resolved to + // 3d models. + // + // TODO: Do we want to offer general guidelines regarding the origin of the 3d model vs the BoundingBox pos, Object pos, etc. + // + optional string model_reference = 5; + + // TODO: See if this can be aligned to the way other OSI enums are named + enum Type + { + // General stuff + TYPE_UNKNOWN = 0; + TYPE_OTHER = 1; + + // Car stuff + TYPE_CHASIS = 2; + TYPE_DOOR = 3; + TYPE_SIDEMIRROR = 4; + TYPE_CARGO = 5; + + // People/animal stuff + // TODO: Those interested in pedestrian modeling need to add their input here + TYPE_TORSO = 6; + TYPE_LIMB = 7; + TYPE_HEAD = 8; + + // TODO: Do we want to handle data for BaseStationary here as well? What problems would having this solve? + } +} + // // \brief The base attributes of a stationary object or entity. // @@ -569,6 +631,12 @@ message BaseMoving // The polygon is defined counter-clockwise. // repeated Vector2d base_polygon = 7; + + // Sub-divisions of the overall bounding box of the BaseMoving object. + // + // \note The bounding box sections can include side mirrors for vehicles. + // + repeated BoundingBox bounding_box_section = 9; } // From 2b65b9be83c23985c3a68507066334d6088832dd Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Mon, 21 Nov 2022 10:09:23 +0100 Subject: [PATCH 06/11] Fix typos, extend comment Signed-off-by: Nicholas Dunning --- osi_common.proto | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/osi_common.proto b/osi_common.proto index fb16cddee..2f7f80bc9 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -415,7 +415,7 @@ message BoundingBox // The type of object contained in the bounding box. // - optional TYPE contained_object_type = 4; + optional Type contained_object_type = 4; // Opaque reference of an associated 3D model of the bounding box. // @@ -434,7 +434,7 @@ message BoundingBox TYPE_OTHER = 1; // Car stuff - TYPE_CHASIS = 2; + TYPE_CHASSIS = 2; TYPE_DOOR = 3; TYPE_SIDEMIRROR = 4; TYPE_CARGO = 5; @@ -634,7 +634,8 @@ message BaseMoving // Sub-divisions of the overall bounding box of the BaseMoving object. // - // \note The bounding box sections can include side mirrors for vehicles. + // \note The bounding box sections can include side mirrors, cargo, etc. + // for vehicles, as well as body-part sections for pedestrians. // repeated BoundingBox bounding_box_section = 9; } From aebcff76f2f7e9233852074a939f0877a622daec Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Thu, 1 Dec 2022 16:20:35 +0100 Subject: [PATCH 07/11] Add comments and update formatting Signed-off-by: Nicholas Dunning --- osi_common.proto | 127 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 95 insertions(+), 32 deletions(-) diff --git a/osi_common.proto b/osi_common.proto index 2f7f80bc9..656891e81 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -387,8 +387,14 @@ message LogicalLaneAssignment optional double angle_to_lane = 4; } -// -// Note: The parent bounding box of the base object should not be setup as a BoundingBox, use the dimension field of the message for this (make this clear in a support image) +// \brief A bounding box containing a sub-section of a object. +// +// A bounding box representing a sub-section of it's parents overall dimension, +// either that of a \c MovingObject or \c StationaryObject . +// +// The parent frame of the \c BoundingBox is not relative to the parent object +// it is associated to, but in the same parent frame as the parent object. +// message BoundingBox { // The 3D dimensions of the bounding box. @@ -397,55 +403,94 @@ message BoundingBox // The 3D position of the bounding box. // - // TODO: Make sure this is clear that the position is "absolute" to the GT frame + // \note The position should be within the same coordinate frame as it's + // parent, not relative to coordinate frame of the parent object. The + // position becomes global/absolute if the parent frame is inertial + // (all parent frames up to ground truth). + // optional Vector3d position = 2; - // TODO: make sure this is clear, the parent frame is intended to mean the GT frame for this use-case - // The relative orientation of the bounding box w.r.t. its parent - // frame, noted in the parent frame. The orientation becomes global/absolute - // if the parent frame is inertial (all parent frames up to ground truth). - // - // \f$ Origin_{\text{base stationary entity}} := - // Rotation_{yaw,pitch,roll}( \f$ \c #orientation \f$ )* - // (Origin_{\text{parent coord system}} - - // \f$ \c #position \f$ )\f$ + // The 3D orientation of the bounding box. // + // \note The orientation should be within the same coordinate frame as it's + // parent, not relative to coordinate frame of the parent object. The + // orientation becomes global/absolute if the parent frame is inertial + // (all parent frames up to ground truth). // optional Orientation3d orientation = 3; // The type of object contained in the bounding box. // - optional Type contained_object_type = 4; + optional Type contained_object_type = 4; // Opaque reference of an associated 3D model of the bounding box. // // \note It is implementation-specific how model_references are resolved to - // 3d models. - // - // TODO: Do we want to offer general guidelines regarding the origin of the 3d model vs the BoundingBox pos, Object pos, etc. + // 3d models. This means the coordinate system, model origin, and model + // orientation are also implementation-specific. // optional string model_reference = 5; - // TODO: See if this can be aligned to the way other OSI enums are named + // Definition of different types of object contained within the bounding box + // enum Type { - // General stuff + // Object of unknown type (must not be used in ground truth). + // TYPE_UNKNOWN = 0; + + // Any other type of object. + // TYPE_OTHER = 1; - // Car stuff + // The main chassis of a vehicle. + // TYPE_CHASSIS = 2; + + // The door of a vehicle. + // TYPE_DOOR = 3; - TYPE_SIDEMIRROR = 4; + + // The side mirror of a vehicle. + // + TYPE_SIDE_MIRROR = 4; + + // Additional cargo attached to the a vehicle which is temporarily + // attached. + // TYPE_CARGO = 5; - - // People/animal stuff - // TODO: Those interested in pedestrian modeling need to add their input here - TYPE_TORSO = 6; - TYPE_LIMB = 7; - TYPE_HEAD = 8; - - // TODO: Do we want to handle data for BaseStationary here as well? What problems would having this solve? + + // The wheel of a vehicle. + // + TYPE_WHEEL = 6; + + // The torso section of a person or animal. + // + TYPE_TORSO = 7; + + // An external limb of a person or animal. + // + TYPE_LIMB = 8; + + // The head of a person or animal. + // + TYPE_HEAD = 9; + + // The trunk section of a tree. + // + TYPE_TREE_TRUNK = 10; + + // The crown of a tree, usually encompassing the branches and leaves. + // + TYPE_TREE_CROWN = 11; + + // The vertical pole of a street light. + // + TYPE_STREET_LIGHT_POLE = 12; + + // The horizontal arm of a street light. + // + TYPE_STREET_LIGHT_ARM = 13; } } @@ -509,6 +554,17 @@ message BaseStationary // The polygon is defined counter-clockwise. // repeated Vector2d base_polygon = 4; + + // Sub-divisions of the overall bounding box of the \c BaseStationary object. + // + // The bounding box sections can include separate parts on partially-opaque + // objects such are trees with a distinction between trunk and crown. + // + // \note When one or more \c BoundingBox s are associated to a + // \c BaseStationary , the expectation is that all sections are contained + // within the bounds of the \c #dimension . + // + repeated BoundingBox bounding_box_section = 5; } // @@ -610,6 +666,7 @@ message BaseMoving // \f$ \c #orientation_rate \f$ .roll(t-dt) \f$ // optional Orientation3d orientation_acceleration = 8; + // Usage as ground truth: // The two dimensional (flat) contour of the object. This is an extension of @@ -631,11 +688,17 @@ message BaseMoving // The polygon is defined counter-clockwise. // repeated Vector2d base_polygon = 7; - - // Sub-divisions of the overall bounding box of the BaseMoving object. + + // Sub-divisions of the overall bounding box of the \c BaseMoving object. + // + // The bounding box sections can include side mirrors, cargo, etc. for + // vehicles, as well as body-part sections for pedestrians. // - // \note The bounding box sections can include side mirrors, cargo, etc. - // for vehicles, as well as body-part sections for pedestrians. + // \note When one or more \c BoundingBox s are associated to a + // \c BaseMoving , the expectation is that all sections are contained + // within the bounds of the \c #dimension . Currently there several accepted + // exceptions to this rule, specifically the sub-sections for cargo, vehicle + // side mirrors, and doors not in the their closed position. // repeated BoundingBox bounding_box_section = 9; } From 77e8a1913dcc097f76284f98fa6efdf74c5c6a09 Mon Sep 17 00:00:00 2001 From: ndunningbmw Date: Thu, 1 Dec 2022 16:21:31 +0100 Subject: [PATCH 08/11] Remove extra blank line Signed-off-by: Nicholas Dunning --- osi_common.proto | 1 - 1 file changed, 1 deletion(-) diff --git a/osi_common.proto b/osi_common.proto index 656891e81..37b24bdb2 100644 --- a/osi_common.proto +++ b/osi_common.proto @@ -666,7 +666,6 @@ message BaseMoving // \f$ \c #orientation_rate \f$ .roll(t-dt) \f$ // optional Orientation3d orientation_acceleration = 8; - // Usage as ground truth: // The two dimensional (flat) contour of the object. This is an extension of From 0cfbf75664c398c1df18911154f4cf4a0ea02c82 Mon Sep 17 00:00:00 2001 From: Philip Windecker <95633467+philipwindecker@users.noreply.github.com> Date: Mon, 7 Nov 2022 11:55:46 +0100 Subject: [PATCH 09/11] Build/master branch naming (#672) Change version naming for master branch, update Ubuntu image, and add Antora generator trigger. Signed-off-by: Philip Windecker Signed-off-by: Philip Windecker <95633467+philipwindecker@users.noreply.github.com> Signed-off-by: Pierre R. Mai Signed-off-by: Nicholas Dunning --- .antora/antora.yml | 1 + .github/workflows/antora-generator.yml | 24 ++++++++++++++++++++++++ .github/workflows/protobuf.yml | 10 +++++----- 3 files changed, 30 insertions(+), 5 deletions(-) create mode 100644 .github/workflows/antora-generator.yml diff --git a/.antora/antora.yml b/.antora/antora.yml index e091a6471..009e10a9d 100644 --- a/.antora/antora.yml +++ b/.antora/antora.yml @@ -3,6 +3,7 @@ name: asamosi version: # Update version number accordingly. This is the version for the main branch main: 'current' + master: 'current' v(*)-antora: V$1 v(*): V$1 V(*): V$1 diff --git a/.github/workflows/antora-generator.yml b/.github/workflows/antora-generator.yml new file mode 100644 index 000000000..e5632fa1c --- /dev/null +++ b/.github/workflows/antora-generator.yml @@ -0,0 +1,24 @@ + +name: Antora build trigger + +on: + push: + branches: [ master ] + pull_request: + branches: [ master ] + +jobs: + trigger_antora: + name: Trigger antora generator + + runs-on: Ubuntu-latest + + steps: + - name: Trigger generator + uses: peter-evans/repository-dispatch@v2 + with: + token: ${{ secrets.MACHINE_USER_PAT }} + event-type: antora-build-trigger + repository: OpenSimulationInterface/osi-antora-generator + client-payload: '{"src": "${{ github.repository }}", "ref": "${{ github.ref }}", "sha": "${{ github.sha }}", "head_ref": "${{ github.head_ref }}"}' + \ No newline at end of file diff --git a/.github/workflows/protobuf.yml b/.github/workflows/protobuf.yml index a7acae918..c719a68ce 100644 --- a/.github/workflows/protobuf.yml +++ b/.github/workflows/protobuf.yml @@ -9,7 +9,7 @@ jobs: build-proto2-linux64: name: Build Proto2 Linux 64 - runs-on: ubuntu-18.04 + runs-on: ubuntu-22.04 steps: - name: Checkout OSI @@ -30,10 +30,10 @@ jobs: - name: Cache Dependencies id: cache-depends - uses: actions/cache@v2 + uses: actions/cache@v3 with: path: protobuf-3.20.1 - key: ${{ runner.os }}-v1-depends + key: ${{ runner.os }}-v2-depends - name: Download ProtoBuf if: steps.cache-depends.outputs.cache-hit != 'true' @@ -100,7 +100,7 @@ jobs: build-proto3-linux64: name: Build Proto3 Linux 64 - runs-on: ubuntu-18.04 + runs-on: ubuntu-22.04 steps: - name: Checkout OSI @@ -121,7 +121,7 @@ jobs: uses: actions/cache@v2 with: path: protobuf-3.20.1 - key: ${{ runner.os }}-v1-depends + key: ${{ runner.os }}-v2-depends - name: Download ProtoBuf if: steps.cache-depends.outputs.cache-hit != 'true' From b0a1413ec6953a2ca730beab2af0e8402fa01e32 Mon Sep 17 00:00:00 2001 From: "Pierre R. Mai" Date: Mon, 7 Nov 2022 14:26:23 +0100 Subject: [PATCH 10/11] Never trigger antora builds for PRs from forks (#686) Since no secrets will be available for security reasons, do not try to trigger antora builds when those secrets are not available. Signed-off-by: Pierre R. Mai Signed-off-by: Nicholas Dunning --- .github/workflows/antora-generator.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/workflows/antora-generator.yml b/.github/workflows/antora-generator.yml index e5632fa1c..251478266 100644 --- a/.github/workflows/antora-generator.yml +++ b/.github/workflows/antora-generator.yml @@ -13,12 +13,15 @@ jobs: runs-on: Ubuntu-latest + env: + MUP_KEY: ${{ secrets.MACHINE_USER_PAT }} + steps: - name: Trigger generator + if: ${{ env.MUP_KEY != '' }} uses: peter-evans/repository-dispatch@v2 with: token: ${{ secrets.MACHINE_USER_PAT }} event-type: antora-build-trigger repository: OpenSimulationInterface/osi-antora-generator client-payload: '{"src": "${{ github.repository }}", "ref": "${{ github.ref }}", "sha": "${{ github.sha }}", "head_ref": "${{ github.head_ref }}"}' - \ No newline at end of file From 5e4307e67d10cff09b351edb2746be1edf8c6d28 Mon Sep 17 00:00:00 2001 From: Thomas Sedlmayer Date: Thu, 13 Oct 2022 10:03:24 +0200 Subject: [PATCH 11/11] Fix traffic sign variability attribute description Aligns variability attribute description with existing enum description Signed-off-by: Thomas Sedlmayer Signed-off-by: Nicholas Dunning --- osi_trafficsign.proto | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/osi_trafficsign.proto b/osi_trafficsign.proto index b3136e4d9..5eed93647 100644 --- a/osi_trafficsign.proto +++ b/osi_trafficsign.proto @@ -242,8 +242,9 @@ message TrafficSign // message Classification { - // The traffic sign is not stationary, for example a temporary - // traffic sign in a street construction. + // This value indicates if a sign is static or dynamic regarding its + // content (e.g., electronic sign bridge) and/or regarding its + // position on the road. // optional Variability variability = 1;