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