Multi Robots Multi Missions Requirements for a team
Multi Robots Multi Missions Requirements for a team of robots executing dynamic missions
Assumptions Limited resources (energy, cpu, communication range) Unreliable communication Central server manages the system Unlimited number of members in system Team members with different capabilities/properties Predefined robot capabilities
Assumptions Robot has one mission at a time Robot can be a member in many sub teams All robots in a mission have communication to mission manager at the beginning Limited number of robots in mission/team Unknown, dynamic mission Unknown, dynamic team
System Architecture Server - clients Operator sends commands to robots Robot consult services
Robot Architecture Sensors Monitor Perception Generate Events* Partial shared with Other team-members Execution Dynamic & Static decision making Actions
Mission Execution Engine. Single robot Run a validated plan Plan is an instance of a recipe Mission Engine run behaviors with (DDM) Dynamic Decision Making Behavior executes one of the Robot action
Mission Execution Engine. Single robot Recipe Parts Behaviors Transitions rules Incoming events Parallel- control all the sub recipes’ end (first to end, all), drill down events Start behavior Finish behaviors Internal shared memory between behaviors Parameters - shared internal memory with inherited
Mission Execution Engine. Single robot Instance the ‘start behavior’ and execute its action Remap incoming events to the active behavior When behavior finished, make decision what to do next Consider transition rules priority Recognize the perception module and may consult it in the transition rules At ‘Finish’ return status
Mission Execution Engine. Single robot Support singleton behaviors Support unlimited number of behavior instances. Include sub recipe Support unfamiliar sub recipe (that cannot be called by this robot but is part of plan) Dynamic expanding of sub recipe (consulting system’s service) Synchronize progress of sub-recipes (wait for other sub recipe to reach a sync point)
Mission Execution Engine. Single robot Behavior Static decision making Parts Parameters Action- code that execute a real action Finish condition Handle interruptions Close list of events. Plan may remap other events to known events
Mission Execution Engine- Team Recipe Parts Allocation protocols. Roles Sub-team Templates instantiation (same sub recipe with different parameters) Voting protocols- what is the next sub-mission to execute as a sub team Synchronize- wait for all the members in sub-team before calling allocation/voting protocols or as standalone action Merge protocol- when robot lose communication to team, and reconnectdata may be merged.
Mission Management. Mission Manager Communicate with the mission members directly Communicate with the operator and systems’ services via server May be located on one of the team members Can work without connection to server (and reconnect when available again) Manage the team and sub teams Manage the mission status Recognize loss of team-member communication (include
Mission Management. Mission Manager Receive the following commands Start (initialize) Stop Plan and replan Intend Join/leave of a robot Unintended leave of a robot Receive updates from members Alerts, warnings, etc. Mission status, details
Mission Management. Mission Member Register to mission (and main team) Register to sub-teams Receive plan from the mission manager to execute Execute its plan Report to the mission manager- status, alerts, warnings Recognize loss of communication to network
Mission Management. Mission Member Can work without connection to mission manager (when reconnect may merge the shared data using dedicated protocol) May leave the mission (and teams) by command from the mission manager, operator, or according to decision (e. g. , loss of communication for a long time) Awareness to its abilities, (known actions, recipes, protocols)
Mission Management- Team Member Shared, synchronized data between the (sub)team members Minimum communication Share data only with the sub team members (according to the recipe hierarchy). Do not transmit internal data Transparent synchronization Controlled data/events properties (what and when to share) On change- inject data/event to all the members and trigger a response Lazy- when the member request data it get the updated value
Mission Management- Team Member Update shared data by any member (while locking it) View mode of shared data (locked for changes, but more than a single member can view the data) Avoid data locked by lost team member (include member with temporary communication disconnection)
Mission Management- Team Member Progress synchronization Mandatory wait for all the rest of members before continuing to next part of the sub-mission or before executing team allocation/voting protocol Dynamic support on change of sub(team) members (join/leave)- don’t wait to sync with robot that has left the team Wait for other team members (by member id or number of members) at a specific point in the plan. The other members must be part of the team, but may not be
Plan representation GUI Different representation for recipe components different allocations and parallel Represent transition rules and priority Represent behaviors Represent teams hierarchy Create new and edit existing plan Validation Check all the recipe/behavior parameters are fulfilled
Plan representation Discovery of pre-defined components Protocols Perception variables Recipes Behaviors list Behavior properties Known interruption events Remap parameters’ names, events
Thank you
- Slides: 21