Small Angles between direction vectors
Status: Alpha
Brought to you by:
cwreynolds
Menu
▾
▴
Has anyone noticed that at small angles between two vehicles (e.g., 5 degrees) moving in the same direction, the procedure "predictNearestApproachTime" (located in SteerLibrary.h) will predict a time that is larger than the actual time when a collision will occur?
This is due to the fact that as the angle between the direction vectors of the two vehicles decreases the point of intersection goes off to infinity. However, due to their size the two vehicles will collide way before the predicted time. Therefore, the only adjustment made by the system is that prescribed by steerToAvoidCloseNeighbors when they actually do collide. No premediated correction is made.
You can see this using the data for two vehicles:
Vehicle InitialPosition Direction MaxSpeeds TargetPosition
1 (6,0,0) (-1,0,0) 1.3 (-6,0,0)
2 (7.977,0,0.523) (-1,0,-.0875) 1.6 (-5.977,0,-.523)
Has anyone developed a change to code to deal with this problem?
This is an interesting observation. As you note this issue is normally masked by other behaviors like steerToAvoidCloseNeighbors or steerForSeparation. (There is a note in SteerLibrary.h that the latter should replace the former.)
However, the code is written to take radii into account, so I am not sure what you are seeing. predictNearestApproachTime is not directly relevant since it deals in velocity and time, not distance. computeNearestApproachPositions definitely ignores the radii of the two vehicles, it just looks at the distance between their centers (so shouldn't it be called computeNearestApproachDistance ?). However it is called from steerToAvoidNeighbors which defines collisionDangerThreshold to be twice the radius. (It should actually be the sum of "my" radius and "his" radius -- plus arguably some user-defined safety margin.) Does this not correspond to what you see?
Have you tried adjusted the minTimeToCollision parameter of steerToAvoidNeighbors? It might be that the potential collision of the nearly parallel vehicles is beyond the time threshold you specify, so it is being ignored. As a test try making minTimeToCollision ten times bigger and see if there is a difference in behavior.
(As I look at this code I wonder if minTimeToCollision isn't misnamed. Should it be maxTimeToCollision? I think it means "ignore potential collisions more than this amount of time into the future, since such speculative prediction is unreliable" but that phrase is a little too long for a variable name, even for me!)
usherjm: please post here if you learn more about this issue. I will file a bug report referencing this forum thread.
1) Thanks for the reminder about steerForSeparation. I have not delved into that behavior yet, so I have made no replacement at this time.
2) As I saw in the steerToAvoidNeighbors procedure, in order for a vehicle to be considered a threat the predicted time had to be between 0 and minTime. Therefore, predictNearestApproachTime is the gatekeeper for any vehicle to even be considered a potential threat (aside from first check to see if there is immediate interpenetration).
As mentioned, at small angles the predicted "time" is large so it does not fall within the boundard 0 to minTime. Given this is true, increasing the value of minTimeToCollision (which initializes minTime) will allow the system to recognize the impending collision, but I do not want to inflate this value in general as I plan to use this value as a variable whose value varies with the crowd density. I want it to have real-world significance.
What I have done is add logic to take into consideration the angle between the direction of the two vehicles considered. If the angle is small then the minTime boundary value is adjusted. This is NOT an elegant solution and sidetracks proper use of the geometry of the problem.
I will have to ponder the appropriate geometrical solution to predicting time to collision that considers vehicle size. As you say, predictNearestApproachTime only considers velocity and position. (Did I overlook a procedure in the code to handle velocity, position, and geometry?)
This is off the top of my head without much thought, I just wanted to jot it down for when I return to this issue. (And note that after tomorrow I will be away for two weeks.)
If we think of the vehicles as being represented as their bounding spheres, and given a ceiling on the length of time we will look into the future ("minTimeToCollision"), then the geometric interpretation of the near future is a set of "swept spheres" tubes (cylinders with hemispheres at the ends, aka "capsules" or "hot-dogs") extending forward from each vehicle. We want to know if our tube intersects with any other vehicles.
I think the case that usherjm noticed is when the tubes touch, but the intersections of their centerlines (the vehicle's forward axes) is well beyond the length of the tubes. Perhaps steerToAvoidNeighbors should be recast to look for tube-to-tube intersections, rather than looking for the point of nearest approach and reasoning backwards from that. One issue that I can see with this "timeless" geometric approach is that path intersections do not necessarily imply collisions. A pedestrian can cross the street safely in front of an oncoming car as long as they get to the other side before the car reaches their path.
bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=1616121&group_id=77546&atid=550583