Interactive Navigation in Complex Environments Using Path Planning Salomon et al.(2003) University of North Carolina Presented by Mohammed Irfan Rafiq Using Slides from Xiaoshan Pan(2003)
Jan 23, 2016
Interactive Navigation in Complex Environments Using Path Planning
Salomon et al.(2003) University of North Carolina
Presented by Mohammed Irfan RafiqUsing Slides from Xiaoshan Pan(2003)
Motivations
The design and evaluation of complex engineering products requires interactive navigation using appropriate interaction modes.
Navigating in a driving mode with an unconstrained free-flying camera gives confusing views of geometry.
Earlier work on navigation with constrained camera motion are limited to be local navigation modes or in small environments.
Problem & Approach
How to automatically plan a motion path to assist 3D interactive navigation with a constrained camera in a complex environment?
The approach is to combine robot motion planning techniques and driving interaction methods.
Good application for a multi-query and visibility based roadmap
Inputs– model geometry and dimensions of the avatar
Constraints
Constrained avatar motion– Translation along a surface– Rotation about an axis orthogonal to the surface– Motion must lie on a walkable surface such as a
floor or stairway– Can not walk up or down unreasonably steep
slopes
Content
2 modes of navigation: Global
– Pre-compute a global roadmap– Graph search (inigoal) in real-time– Display motion
Local– User-steered exploration
Basic Idea
Preprocessing phase
Runtime algorithm
•Connectors - Rc > Rg
Rc
Guards & Connectors (C-space)
•Reachability -neighborhood around a config that can be reached using a local planner
Rg•Guards - guards can’t see each other
- yes reject c, goto while
c
- no! c becomes a Guard, connect to connectors (if any), goto while
Algorithm (build_roadmap)
While (map_coverage < P_cover), do // map_coverage = guards_reachable/entire_space
Return roadmap
Connector
GuardGuard
Connector
GuardGuard
Connector
GuardGuard
2. Can c be a Connector? See any Guards in Rc? - Yes then connect, goto while (else goto 3)
1. Pick a random config. c
c
3. Can c be a Guard? See any Guards in Rg?
c
Be a Connector Be a Guard Be rejected
Roadmap – Connecting Nodes
Is c1 in Reach(c2,r)?– check if distance between the two locations is
less than or equal to r– use the local planner to test if c1 is reachable
from c2
Roadmap – Pruning Connectors
To remove redundant connectors and keep connectors with highest number of linked guards
If an existing reachable connecter join the same set of guards as the new connector, then discard the new connector If an existing reachable connector only joins a subset of guards that is reachable from the new connector, then add the new connector and remove the existing connector
Search for a path: init goal Initial position (Rc radius)
ini
goal
Goal position Graph search…
Display Motion: Smooth Path Walk along the path
ini
goal
Smoothing path (cutting redundant corners while walking)
Roadmap - Sampling
Gravity
•Shooting rays
Random Rays
Roadmap - Sampling
Gravity
•Shooting rays
ө ө
•Walkable surface
•Construct roadmap
Roadmap - Analysis
Roadmap size– Number of guards is limited by mutual unreachability, number of connectors is minimized by connector pruning– In Practice, less than one connector for every guard
Estimated coverage– Maintain a tally of the number of samples that are reachable from at least one guard – The ratio of reachable samples to total samples is a lower bound on the ratio Nreachable/N – As N grows large, Nreachable/N converges to Areachable/A
User-steered exploration (local walk)
User has control– A directional vector
Robot always stays on a walkable surface
– In free space– Surface within a tolerance
angle– Steps ok, cliffs NO!!
Robot do not penetrate objects
Local Walk Algorithm
Follow the directional vector, if- Goal is reached, stop
- Collision, project along obstacle edge
- New surface, step up/down (not a cliff!)- Edge, step up/down or project along the edge
Local Walk
collisions below a certain height with non -walkable surfaces are permitted so that the avatar is able to step over low obstacles
when redirected the avatar is not allowed to move in a direction that makes an angle
> 90 with the original direction
Results
Limitations
the avatar follows the path in linear segments, hence the paths may look unnatural
the avatar cannot bend to look under objects does not address the narrow passage problem the precomputation process is time consuming would require recomputing the graph for a
dynamic environment