Attendees
- Sachin
 - Gil
 - Caroline
 - Ethan
 - Eitan
 - Brian
 - Leila
 - Bhaskara
 - Peter
 - Max, Ben, Mike (PENN)
 
Agenda
- Coordinate the effort to do motion planning/control for dynamic obstacles and define a set of objectives and roadmap for the same - in particular look at the needs (from a motion planning/control perspective) for people aware navigation
 - Define the needs/interface required from people detection/tracking for the planning/control effort
 
Details
- Planning  
- Planners that can deal with dynamic obstacles
 - Global vs. Local planners
 - Planning times
 
 - Control 
- Local controllers that can deal with dynamic obstacles
 - Modify trajectory rollout to deal with dynamic obstacles
 - Other control schemes
 
 - Representation  
- Define structures for representing dynamic obstacles 
- Position
 - Velocity
 - Uncertainty
 - id
 
 - Minimally modify current costmap structure to deal with dynamic obstacles 
- Remove dynamic obstacles from incoming sensor stream
 - Deal with dynamic obstacles using forward simulation in trajectory rollout
 
 - Time varying costmap representations
 
 - Define structures for representing dynamic obstacles 
 - Sensing 
- Needs for planning/control 
- position/velocity of dynamic obstacles (can be stubbed out for now)
 - uncertainty - represent expected path (for people)
 - sensor models for obstacles - needed to discriminate static/dynamic obstacles
 
 
 - Needs for planning/control 
 - Demo scenarios 
- Follow a person down the hallway instead of replanning and turning around
 - Person avoidance - stop and wait/move to the side if person walking towards you
 
 
Minutes
Describe motion_planning/Meetings/Minutes 2009-11-18 here.
- Minimal change in current architecture approach 
- Deal with dynamic obstacles separately
 - New trajectory planner plugin takes dynamic world representation
 - World model is a combination of dynamic and static obstacles
 - Is this completely safe - if you think the person is going away from where you will be in the next timestep  
- is there a way to make this more safe?
 
 - Local planning window may be too small (1.5 seconds)
 
 - Dynamic obstacle tracker returns a list of predicted points in the future instead of returning velocities 
- minimal separation distance - what should this distance be? 
- prevent chattering in this instance
 
 
 - minimal separation distance - what should this distance be? 
 - Global planner can generate a plan to avoid dynamic obstacles (Max) 
- local planner could decide on which dynamic obstacles the global planner needs to be worried about
 - Representation:  
- List of predicted positions in time for each dynamic obstacle 
- x, y + variance to incorporate uncertainty estimates
 
 - Radius of each dynamic obstacle
 - Allows for multiple trajectories for the same obstacle 
- maybe a person turns into an orthogonal hallway
 
 
 - List of predicted positions in time for each dynamic obstacle 
 - Planning 
- x,y,theta, time - considers the probability of collision as well - if probability is high, those particular positions of robot in time are prohibited
 - finite horizon planning in time 
- longer than x,y,theta lattice planner - planning time within a few seconds
 
 
 - For each obstacle - multi-modal representation 
- Radius (Footprint? - need to lay down the footprint) - if the footprint exists, it overrides radius
 - Vector of trajectories 
- Each trajectory - vector of points + 1 probability for each trajectory 
- Each point - x,y,theta,variance (time?)
 
 
 - Each trajectory - vector of points + 1 probability for each trajectory 
 - Time - uniform sampling/time for each point in trajectory - could be enforced in API for planner but data structure could still support non-uniform sampling.
 
 
 - Sensing  
- diff two consecutive sensor views to try and find dynamic obstacles
 - 2D optical flow?
 
 - Action items  
- Create a message to represent the dynamic obstacles (Eitan/Mike(Penn))
 - Perception literature 
- tracking/finding dynamic obstacles
 - optical flow?
 - blob tracker