Add new message for sub-bounding boxes #732
Conversation
pmai
force-pushed
the
feature/sub-bounding-boxes
branch
3 times, most recently
from
4206564 to
58ecd44
Compare
|
It was unlcear which pivot point the Position definition represents in relation to the dimension and rotation. Added a comment, that it is the center of the BoundingBox. For Type "TYPE_OTHER", there was no possibility to express the object more detailed. I introduced a string type to describe it. This other_object_type offers the possibility to reduce the Type enum and split it up an an additional PR to update it later on. This type should not be in conflict to other current approaches harmonizing object type definition. Through the other_object_type filed, the overall SubBoundingBox approach is already usable. @pmai Why did my DCO fail again? :.( |
thempen
added
the
ReadyForCCBReview
|
CCB 2024-01-29: Type enum should be reviewed (e.g. by @PhRosenberger, @thomassedlmayer, @pmai) esp. w.r.t. sensor modeling needs and a minimum list should be proposed. If no such list emerges, then having no enums, but also dropping the string fallback (as e.g. model_reference can already be used as a last effort fallback) would be the preferred way forward. Will be re-reviewed at next CCB. |
thempen
force-pushed
the
feature/sub-bounding-boxes
branch
from
24dfdbb to
12ef6dc
Compare
thempen
removed
the
ReadyForCCBReview
thempen
added
the
ReadyForCCBReview
|
CCB 2024-02-26: Small addition of examples for TYPE_DOOR in the context of vehicles to be added by @pmai, otherwise is ready for merge as-is. |
pmai
force-pushed
the
feature/sub-bounding-boxes
branch
from
9230083 to
7d8e37b
Compare
pmai
added
ReadyToMerge
Signed-off-by: Nicholas Dunning <[email protected]>
Signed-off-by: Nicholas Dunning <[email protected]>
Add information regarding the handling of side mirrors and the definition of the bounding box. Signed-off-by: Pierre R. Mai <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
- Clarified the position definition. - Added a "other_object_type" sting to define object types, which are not part of the Type definition enum. - Reduced the Type field, because of compatibility reason. There is a general approach to harmonize object type definitions. So the definition should not get in conflict to that approach. Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Thomas Sedlmayer <[email protected]>
Signed-off-by: Thomas Hempen <[email protected]>
Removed invalid tabs. Signed-off-by: Thomas Hempen <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
pmai
force-pushed
the
feature/sub-bounding-boxes
branch
from
7d8e37b to
7e81917
Compare
7 participants
This PR is a continuation of #695 (and #685) with fixed history. It proposes the addition of bounding box sub-sections to BaseMoving and BaseStationary objects, to help sub-divide and classify different parts of the overall object structure.