Skip to content
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

adding ObstacleDetection and Adaptive Cruise control signals #770

Closed
wants to merge 4 commits into from

Conversation

tguild
Copy link
Contributor

@tguild tguild commented Aug 27, 2024

adding ObstacleDetection:ForwardDistance ObstacleDetection:ForwardTimeGap CruiseControl.AdaptiveIsActive CruiseControl.AdaptiveDistanceSet

Drawing from Android Automotive documentation

https://source.android.com/docs/automotive/vhal/adas-properties

which has:

ADAPTIVE_CRUISE_CONTROL_TARGET_TIME_GAP
ADAPTIVE_CRUISE_CONTROL_LEAD_VEHICLE_DISTANCE

The Commercial Vehicle group came up with the proposed PR for VSS. Cruise Control and Emergency Braking Assist may share the sensor data if vehicle has both so we felt it appropriate to place some of this under ObjectDetection. While the time gap can be calculated based on distance and vehicle speed, we feel it should be defined and represented in VSS.

Nearby we also want to include blind spot detection, both left and right. Vehicle SAE ActiveAutonomyLevel less than 2 tend to merely indicate presence of a vehicle in blind spot, surely level 3 and greater keep track of distance. Instead of staging a proposed representation for left and right isWarning booleans and possibly distance, want to discuss on VSS call what a better future proof representation may be. There may be object (obstacle) presence and distance detection for multiple directions.

tguild added 4 commits August 27, 2024 15:28
…eGap CruiseControl.AdaptiveIsActive CruiseControl.AdaptiveDistanceSet
naming convention, should have had is preceding
camel casing
careless on syntax 🤦‍♂️
datatype: float
type: sensor
unit: m
description: Distance in meters to forward detected object
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Is the idea that if ObstacleDetection.IsWarning == False then the value of this signal is not relevant, or do we need some special values (for example negative values) to represent that there is no obstacle present.
  • How is this signal supposed to behave when reversing? - reporting obstacles behind vehicle or not reporting obstacles at all?
  • Is it deliberately not specified how you calculate distances? Like if you are planning a turn (or the road turns), should it report the straight distance to the obstacle, or the distances you need to drive to hit the obstacle

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lidar (radar, camera, other) sensor distance data is of interest even when there isn't a warning (distance falls below OEM threshold). Distance would generally not be negative unless the vehicle rolls over the object, plausible and sub zero value would indicate impact or run over event occurred.

A vehicle in reverse is going backward, not forward so the distance would be increasing assuming the object in the forward direction is stationary, going forward or reversing slower than the vehicle.

Hoping for insight from OEM and Tier 1s on current state of forward distance sensors. Their adopted use is widespread with emergency braking assist and adaptive cruise control. The user is typically presented with simple incremental units for setting cruise control that presumably are car lengths. As car lengths are not a consistent unit of measure, meters are preferred and OEM calculation to convert is implementation specific unless the underlying sensor is already using meters.

We should discuss future proofing VSS as with ADAS/AV signals will be increasing with additional sensors and presumably different configurations per manufacturer detecting distance in various directions besides forward.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the initial comment made with this PR and this one, very interested in how we can accommodate multitude of direction sensors on existing advanced (SAE AV 4+) or experimental vehicles. As the configurations will vary we cannot use simple directions (front, left, left front, etc) but instead could use degrees with 0 being directly in front of the vehicle. This compares to degrees on a compass (Vehicle.CurrentLocation.Heading in VSS). Sensor type would be of interest as we are seeing a mix.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume the distance to object in front would relate to objects in the trajectory of the moving vehicle. So if there is a curve, stationary objects would not be relevant, if the trajectory is not hitting the object...

description: Distance in meters to forward detected object

ObstacleDetection.ForwardTimeGap:
datatype: int32
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be uint32, or do we intend to use negative values to represent cases like no foreseeable impact.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need negative numbers so uint would indeed be better.

@erikbosch
Copy link
Collaborator

MoM:

  • Please review
  • Ted: This is just first contributions, we have other additions in pipe, future proof design of signals needed, like objects in blind sport. Input from OEMs wanted
  • Stefan: I have seen some examples with "intention", like is pedestrian likely to cross the street or not
  • Daniel: Modelling goes a bit beyond on what we can discuss here, we could possibly reuse info from https://www.asam.net/standards/asam-openxontology/
  • Stephen: "feature complete" or work in progress. May need to have "concept" info that explains the intention of all small steps.

datatype: boolean
type: actuator
description: Indicates if adaptive cruise control system is active (i.e. actively controls speed).
True = Active. False = Inactive.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to clarify meaning of false? Like what should this signal show if cruise control is active but not in adaptive mode (i.e. it is in old fashioned mode were it keeps the speed until you press the brake pedal or crashes)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to my knowledge, there is either adapative or non adaptive cruise control. But it does not change. This signal would just provide the info of what is active in the vehicle...

Copy link
Contributor Author

@tguild tguild Sep 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this further on the Commercial Vehicles' insurance focused breakout call and looked over some of the other nearby (obstacle) signals that exist in production vehicles we would like to see in VSS. Specifically we were looking at left and right blind spot detection mentioned previously and rear cross traffic detection.

ObstacleDetection as it is presently exists in VSS could handle this if there are multiple leaf nodes and well known (defined locations) similar to how multiple tires, seats etc with some generalized optional attributes for
things like warning type, distance, timegap (desired but debatable). Vehicle.ADAS.ObstacleDetection.Front.Distance for example in place of ObstacleDetection.ForwardDistance as was in this PR.

WarningType can have various allowed values such as CROSS_TRAFFIC so that we know it is detecting a moving instead of stationary object at Vehicle.ADAS.ObstacleDetection.Rear.WarningType when Vehicle.ADAS.ObstacleDetection.Rear.IsWarning is True.

Vehicle.ADAS.ObstacleDetection.Left.WarningType=BLINDSPOT and Vehicle.ADAS.ObstacleDetection.Left.IsWarning=True would indicate the presence of a vehicle in the left blind spot as another example.

Instead of scrapping and proposing a new PR, hope to discuss on an upcoming VSS call as there may be other thoughts on how to represent these.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also decided in CV call that we should focus on mainstream production vehicles with their existing sensors and leave aside more complex configurations of evolving AV/ADAS for the time being. We would be interested in participating in discussion on future proofing VSS signals.

@erikbosch
Copy link
Collaborator

MoM:

  • Ted informed that PR might be refactored
  • Erik: If structs makes representation better we can consider that

@erikbosch
Copy link
Collaborator

MoM:

  • Not to be part of 5.0
  • Ted: We have identified some insurance/fleet signals, discussing how to progress
  • Ted: Will create new PR replacing this one, input appreciated
  • Ted: We have an insurance call where we discuss needed signals, feel free to join

@tguild
Copy link
Contributor Author

tguild commented Sep 17, 2024

Nearby discussions, proposals under discussion

#754
master...StefanSellschopp:vehicle_signal_specification:master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants