Skip to content

MBZIRC2020 Architecture explained

Jump to bottom
franreal edited this page Oct 7, 2019 · 19 revisions

The overall MBZIRC2020 architecture consists of the following entities: Components, Robot Action Servers, Robot Tasks and Task Dispatcher scripts.

Components

Components lie at the lowest level of the architecture and implement functionalities that are needed for the challenges, but are not directly related to robot movement (see Robot Action Servers in the next section). Each functionality may require one component instance per-robot (e.g., brick object detection, robot localization) or just one centralized component instance (e.g., moving target estimation, shared regions management). Typically, they are implemented as ROS nodes inside their own packages, and all services and topic messages they offer should be defined in the mbzric_comm_objs package. The following list enumerates some examples of packages implementing Components:

Before implementing a new functionality in the architecture not yet available, one needs to answer some questions first, in order to determine whether a new Component should be created:

  • Can that functionality be implemented mainly in a ROS node with the typical services/messages communication mechanisms?
  • Is it not directly related to robot movements or actions?

If the answers is yes, we should create a new component. Normally this implies creating a new package and adding some srv/msg descriptions into the mbzirc_comm_objs package.

Robot Action Servers

Each robot, UAV or UGV, will implement a set of actions through an action server. Each action represents an indivisible and time-defined movement-related-task that a robot can execute with no information or coordination from other robots, just relying on onboard Components and maybe some internal state. Coordination implies communication out of the robot, and it must be minimized because its bandwidth and quality are uncertain. In particular, each type of robot must implement actionlib SimpleActionServers for the set of actions described in mbzric_comm_objs/action, and provide a mbzirc_comm_objs/RobotDataFeed message with basic information (currently, just pose).

The uav_action_server.cpp file implements such a set of action servers for the UAV, in a class called UalActionServer. However, it is not mandatory to implement all servers on a single ROS node nor to use grvc-ual for communication with the autopilot. Robot Action Servers can be programmed in C++ or Python, depending on performance requirements.

Before implementing a new action in the architecture not yet available, one needs to answer some questions first, in order to determine whether a new action should be added to the Robot Action Server:

  • Is the action related to robot movement?
  • Is it indivisible and starting and finish points in time are well defined?
  • Can it be executed on a robot isolated from the rest?, also not relying on centralized Components.

If the answers are yes, then a new .action file must be defined, and a new SimpleActionServer must be implemented into the robot_action_servers package. Otherwise, it would not be an action but a task that needs to be implemented with the procedure explained in the next section.

Robot Tasks

At a higher level of the architecture, Robot Tasks are in charge of composing Robot Actions and Components to build more complex tasks. Tasks could be assigned to different robots and are implemented as Python classes that must satisfy 3 requirements in order to ease execution management:

  1. inherit from smach.State or smach.StateMachine
  2. have outcomes = ['succeeded', 'aborted', 'preempted']
  3. implement a define_for(self, robot) function, where in variable robot a RobotProxy object is expected, which defines the task for the robot and does return self.

If a new Robot Task has to be implemented, it has to be composed with other Tasks, Robot Actions and/or other Components services/topics. Once implemented, it should be placed within the most related Python submodule (or within a new submodule if needed) at robot_tasks/scripts/tasks:

  • move: for movement-related Tasks. [TakeOff, GoTo, FollowPath, Land]
  • build: for Tasks related with building the wall on Challenge 2. [PickAndPlace]
  • region: for Tasks related with shared regions management. [AskForRegionToHover, AskForRegionToMove, FreeRegions]
  • timing: for timing-related Tasks. [SleepAndRetry]

In general, Robot Tasks re-usable, and the same Task should be valid for both UAVs and UGV (unless it makes no sense, e.g., TakeOff, Land). The Robot Task will use underneath Components and Robot Action Servers that will be the ones with different implementations depending on the type of robot.

Task Dispatchers

A Task Dispatcher is the element on top of the architecture. Basically, it is a script implementing the behavior of the team, in charge of assigning Tasks to robots to perform the Challenge. It encodes the overall strategy of the Challenge, and the execution of Tasks is delegated to task objects for different robots in the team. For example, the script c2_dispatcher_coop.py runs the MBZIRC2020 Challenge 2 with a cooperative strategy.

A robot is uniquely identified by its Id. The Task Dispatcher should be aware of the available robots at any moment. At the beginning, by means of initial information provided by the human operator or by means of an auto-discovery mechanism. Later, if one robot dies (or loses communication), the Task Dispatcher should update the list of available robots and adapt its behavior when assigning new Tasks.

In general, the Task Dispatcher is a central element managing the behavior of the whole team. However, inter-robot communication is not taken for granted in the architecture. In case of no available communication between the robots (from the beginning of the mission), a Task Dispatcher could also be run on board each robot, acting isolated and implementing a specific behavior for that non-cooperative situation. Furthermore, as ROS multimaster scheme does not allow robots to share parameter servers, all rosparam usage should be limited to the Task Dispatcher (or otherwise centralized Components).

Clone this wiki locally