questoins about rss-lib document about ad-rss-lib HOT 8 CLOSED

Hi,
this section in the documentation describes how the exemplary implementation within ad_rss_map_integration transforms from the roads, lanes from the AD-map into the lane-based coordinate system which is noted as preliminary within the original RSS paper. The section "C. Situation-Based Coordinate System" in https://ieeexplore.ieee.org/document/8813885 also covers some portions of this.

The subsection "Calculation of Metric distances within the Road Area" in the docu tries to summarize what is actually calculated within https://github.com/intel/ad-rss-lib/blob/master/ad_rss_map_integration/src/RssObjectConversion.cpp in combination with https://github.com/intel/ad-rss-lib/blob/master/ad_rss/src/world/RssObjectPositionExtractor.cpp. In the implementation we have chosen to deploy the parametric ranges of the map implementation in combination with maximum/minimum length and width of lane segments to calculate the worst-case distances between the vehicles to be presented to the core RSS calculations, which has no notion of the actual lane geometries anymore as we tried to decouple ad_rss from any concrete AD-map realization.

That chosen implementation might be a bit conservative depending on the actual road geometries, so for sure one could implement other more exact measures to calculate the distances between the vehicles within a lane-coordinate system. Especially if for a real productive implementation of RSS the AD-map representation is know upfront and fixed. For the research purposes of this Open Source library we wanted to keep the parts with and without map more independent to support multiple use-cases.

I hope this helps a bit.

from ad-rss-lib.

Dear Bernd,
Appreciate your reply! So, the situation-based coordinate is a complement to lane-based coordinate? In normal road type, lane-based coordinate is enough, while in worst-case, (eg. widening lane), situation-based coordinate is better for RSS to calculate proper response? The origin of the coordinate system is fixed on road segment or fixed to the vehicle? And how to understand sentences: 'every difference between the minimum and maximum values of the width or the length of one of the lane segments might increase the required safety distances. Keep the road area as large as needed, but as small as possible at the same time' in paper you mentioned above?

from ad-rss-lib.

I'd rather formulate it in a way that the used situation-based coordinate system is the situation specific incarnation of a lane-based coordinate system.
And within the implementation the road area usually spans just around the two vehicles under consideration to reduce the negative impact of not relevant parts of the lane which might introduce too conservative worst case distances. So the origin is moving, but in the current implementation it's not within the vehicle center; rather at the outer ends of the vehicles from longitudinal perspective and outer left lane from lateral perspective. In more complex road geometries this is not ideal, but we've stuck to our initial design because of the above mentioned reasons.

And to answer the other part of the question: For all (structured) RSS calculations you need a lane-based coordinate system to come to a notion of lateral/longitudinal distance between the vehicles within a lane. The tricky thing is to find an implementation that works for many possible road geometries. Our starting point was the implementation within the carla-map library and the parametric lane descriptions there. For sure, if you have only straight lanes of constant width (this is only 'normal' for some segments of a road) the transformation from cartesian to lane-based is straight forward.

'every difference between the minimum and maximum values of the width or the length of one of the lane segments might increase the required safety distances' : if you would expand the road area further to the side taking an additional lane at the left into account which shows 2m difference in lane width over the area, the worst-case lateral positions of the vehicles in the calculations performed in the code would also change and the actual measured lateral distance within the resulting lane-based coordinate system would decrease. In a similar way, think of a long curve: the minimum and maximum lengths of a lane segment differ; and the longer the lane segment chosen in the curve is the larger the difference gets. This transfers within the implementation into min/max position of the vehicle; and later e.g. the minimum lon-position value of the front vehicle is compared to the maximum lon-position of the other to evaluate the distance between the two and the measured distance between the two vehicles decreases.
Therefore, the road area (to be passed into this specific implementation!) best only spans the lane segments the two vehicles are touching to remove this kind of unnecessary flaws.

from ad-rss-lib.

I believe some of these flaws of too largely selected road areas one might be able to handle by adapting the implementation; so one should be able to analyze the road-area passed into ad_rss in respect to the two vehicles more detailed and try to remove the unnecessary parts; but that 'intelligence' we initially decided to handle outside with the tooling that was already available from carla-map and cutting the lane segments there.

from ad-rss-lib.

Thank a lot for your interpretation. I will combine the paper, the code and your interpretation to understand RSS !

from ad-rss-lib.

Dear Bernd:
After reading the paper and code over the past few days, I have two new questions for you to consult.

1. Firstly, from the official document, in structured situation, if the planning of ego car will cause the safety envelope, which is the minimum safe distance, to be compromised, lateral and longitudinal deceleration will be triggered to ensure the safety of ego car, Based on this, I think RSS should be regarded as a kind of 'monitoring' for safe distance. While for unstructured situation, there are three ways to deal with RSS: Driveaway, Continue forward and Brake, which were proposed in this paper for operations such as driveaway, bypassing obstacles may seem to me to be an act of 'control' rather than just 'monitoring', so does RSS only 'monitoring' or it also include control?
2. Sencondly, if the RSS can be deployed on the car for vehicle verification, it will be a great progress to ensure the safety of the AD system. My question is, if the RSS is deployed on vehicle, whether the distance, speed and other information obtained by different sensors need to be transformed into a unified coordinate system? The lateral and longitudinal distances to other object are obtained from different sensors, could the lateral and longitudinal RSS check and response be carried out in their respective coordinate systems? Or do you have any engineering experiences or challenges about RSS to share.
   Looking forward to your reply, thank you!

from ad-rss-lib.

1. Yes, you are right. RSS can be used as a safety monitoring component which provides lateral and/or longitudinal minimum decelerations in case the safety envelope is comprised due to the ego vehicle being the responsible entity according to the RSS Rules. Also in unstructured mode it's mainly monitoring, DriveAway with the allowed heading ranges is mainly providing some additional restrictions to the controlling component which is only allowed to start moving again if it's steering far enough away from the other. But it's not performing the planning. The safety layer allows only plans to proceed if they are within the desired control range (e.g. including the steering angle in the DriveAway case). Therefore, I'd still see this as monitoring.
   But due to the Doer/Checker nature of RSS and influencing the vehicle controller there is always some sort of control-influence integrated if you connect directly to a controller, too. Here, this then is true for both, structured and unstructured with their output of acceleration restrictions.
   Note: If you including also Rule 5 of RSS "If you can avoid an accident without causing another one, you must do it" (which is not implemented by these libraries!) the required evasive maneuvers go beyond decelerations and cover all between accel_max and brake_max longitudial and/or lateral; such implementation would require more sophisticated portion of actual planning.

2. In terms of coordinate system, the ad_rss_map_integration library receives the object input data in the map coordinate frame. From there these are transferred into the above mentioned situation based coordinate system that is finally presented to ad_rss checks. In CARLA simulator integration of RSS one gets the ground truth from the simulator already in map frame; in a real vehicle your (verified) sensor fusion object list will be used as input; there you also then have to know how the objects are located within the map frame to perform the analysis on the road network (or you have to run always in unstructured mode when no map area is available).
   Another challenge on vehicle integration is maybe the transformation back of the restricting accelerations from the lane based output of RSS into the vehicle frame when applying them directly to the vehicle controller which usually doesn't have any idea of the lanes. In the CARLA Restrictor we have only implemented a super simple version on how to handle the restrictions, but not considered the actual acceleration intervals all the time, which is required to ensure the vehicle is driving within the bounds that are used as assumptions within the RSS model see also that paper. One example that comes into my mind is e.g. constant lateral acceleration restrictions from RSS in lane based output will have to be transformed into changing intervals within the vehicle frame while driving in curves where additional centripetal accelerations have to be considered by the vehicle controller to just keep the vehicle centered within the lane.

from ad-rss-lib.

Hi Bernd,
Thank you for your assistance!
For Answer 1: As a monitor for planning, RSS has higher priority than planning. In my opinion, as soon as the RSS detects an unsafe planning result, it takes over control of the vehicle, while planning continues in the background, until it passes the RSS safety eveluation, then the planning takes over control of the vehicle. This is my further understanding of the relationship between RSS and planning.If wrong, please correct me.
There is such an example that when the front car slows down to stop, ego car will firstly driveaway(from planning). When it doesn't meet the safety, ego car will brake. When the front car still don't move after ego car stops, DriveAway(from RSS) will be triggered until planning results meet safety. So,:
1. RSS don't performe planning, but it outputs control(DriveAway) from the perspective of safety layer?
2. If the front car doesn't move and the DriveAway(from RSS) case cannot be carried out due to the traffic flow at this time, then the AD system should give an alarm to the driver and remind him/her to take over the vehicle, or just keep waiting until situation changes? From my opinion, the probability of occurrence of the above example is extremely low in the utopian world described in RSS paper, but we are on our way to achieving such a utopia, and this situation is common at the moment. Just like you mentioned above: 'it requires more sophisticated portion of actual planning'.
The above is my personal thinking about RSS. Highly appreciate for your reply !

from ad-rss-lib.