-
Notifications
You must be signed in to change notification settings - Fork 170
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
Conversation
…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 |
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.
- 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
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.
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.
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.
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.
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 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 |
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.
Could be uint32, or do we intend to use negative values to represent cases like no foreseeable impact.
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.
We don't need negative numbers so uint would indeed be better.
MoM:
|
datatype: boolean | ||
type: actuator | ||
description: Indicates if adaptive cruise control system is active (i.e. actively controls speed). | ||
True = Active. False = Inactive. |
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.
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)
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.
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...
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.
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.
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.
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.
MoM:
|
MoM:
|
Nearby discussions, proposals under discussion #754 |
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.