search

intel / ad-rss-lib

Library implementing the Responsibility Sensitive Safety model (RSS) for Autonomous Vehicles
https://intel.github.io/ad-rss-lib/
GNU Lesser General Public License v2.1
339 stars 138 forks source link

Unstructured Roads Implementation #48

Closed shantanusingh16 closed 4 years ago

shantanusingh16 commented 5 years ago

Hi, I want to understand how to implement the unstructured case for RSS and need clarity. I feel the problem is intractable because the number of trajectories for each set of robot is essentially infinite and hence it is not possible to evaluate the intersection of each pair for two sets of robots.

Even if we consider the braking and continue forward constraints and work with the bounds determined by the heading angle and inverse of rate of change of radius, the possible number and range of trajectories is infinite and hence the possible positions of the robot with continue forward constraint is highly complex and makes it difficult to evaluate the RSS constraints.

Can you please provide some insight?

berndgassmann commented 5 years ago

Hi, sorry for the late answer. But somehow I missed the opening of this issue. But better a late answer than none... As we are currently focusing on integration with CARLA simulation (https://github.com/carla-simulator/carla/pull/1935) and beyond the open pull request working on supporting scene creation based on the open drive map including intersection and traffic light handling, we didn't look into the details and actual implementation of unstructured roads, yet. But I see, when you are focusing on a mobile robot, there are usually no predefined lanes... but the rules for unstructured roads also might have to be applied on the road if you think on the traffic around e.g. "Arc de Triomphe". Let me try to give some comments here and start the discussion on how we might be able to actually implement this. I believe, an implementation will not require to calculate every possible trajectory. A safety layer like RSS mainly has to consider the outer boundaries of the reachable set; nothing else is done by the calculations at the 'in lane'/ 'structural' case. Therefore the trajectories to be calculated are the extreme ones (see e.g figure 11 in the original RSS paper https://arxiv.org/abs/1708.06374); one has to ensure that the checks consider the area in between as 'occupied', too when calculating the distances. Then you have to take into accout that after the response time braking has to be applied as in the structural case (maybe that's not so obvious when you didn't work with RSS before). The lateral analogy is then to stop the change of circle radius what will lead to driving on a circle where the circle is the analogy of the lane. So the bounds on the heading change are only relevant within the response time and are the analogy of lateral acceleration within the respose time. After response time + some time to come to drive with a fixed radius (might be very short, I believe), the vehicles are expected to drive on a circle with that fixed radius. This is true for the braking trajectories as well as for the continue forward trajectories! The difference between braking and continue forward trajectory is in the longitudinal direction only: the braking trajectories perform braking as in the structured case at least with brake min (and come to a full stop), where the continue forward trajectories are allowed to further accelerate or brake as they wish. So both longitudinal movement strategies are within some given the acceleration bounds what again allows to consider the extrema. In the unstructured case longitudinal and lateral dimensions are much more tight to each other, that's true, but looking at the combination of the extremes (lat-min/long-max), (lat-min/long-min), (lat-max/long-max), (lat-max/long-min), for every point in time (proper sampling rate to be determined) one should be able to span some kind of polygon hull approximation of the area the vehicle/robot potentially can be in (ensuring the worst case under the given constraints is always covered)... and based on this calculate if these two hulls overlap. A first quick check might even be able to take the union of these hulls over time into account (summing up to some kind of triangle-like polygon) as a speed up for vehicles that are still far away from each other (in respect to reaction time, speed and acceleration parameters) and only require the detailed sampling in time if the quick check detects a collision. In addition, when taking the Definition 22 into account, for safety calculations one never compares two forward trajectories with each other. What in the end restricts the time horizon for the checks. Having said this, I believe that the required calculations are in fact hand-able... at least to my current understanding; but we didn't look into the details there yet. There are some other features even higher in the working list like: handling of occlusions in conjunction with CARLA implementation, AD map data and ego-vehicle sensor coverage as well as support for Pedestrians. Where the latter, is directly connected to the unstructured road use-case. Hope this provides a bit more information ... but for sure, my current thoughts might be wrong here ... so don't nail me down ;-) Bernd.