MMRS Simulator

This simulator models the movement of a group of mobile robots (MMRS - Multiple Mobile Robot System) along given paths. Unlike other similar solutions, such as Stage, Gazebo or V-REP, this simulator igores the geometry of paths. Hence, it can be used to test high-level supervisors that control the simultaneous movement of large groups of robots in a manner preventing collisions and deadlocks between theese vehicles.

Problem statement

In our task we consider a group of heterogeneous mobile robots working in a common 2D workspace. Each vehicle is represented as a disk with radius r, which fully covers it. Vehicles functionality is significantly restricted - they can only accelerate forward and deceletare (until they stop), but moving backwards is impossible. Each robot has a path to complete. The paths are divided into separate sectors. A sample task is shown in Figure 1. Figure 1: Example of paths divided into sectors.

It presents 2 robots - R1 and R2 on their paths. Both paths are divided into sectors described as Sij, where i denotes path ID and j denotes sector position on that path. If 2 sectors belonging to 2 different paths are too close (shortest distance between them is less than 2r), we mark them as conflict sectors (red areas on Figure 1). Each sector can have any number of other sectors that conflict with it (this number is limited only by integer capacity). The task of the robots is to travel from the beginning to the end of their path in a finite time. If at any time during the simulation, 2 robots will be simultaneously in 2 conflicting sectors, the task ends in failure.

Input data

Paths can be divided into sectors in any way. Some divisions will be more effective, others less, but the process of division itself is carried out by other software. Simulator takes already divided paths, along with the determined conflict relations as input data. The path is represented as:

a list of positive real values, representing distances between endpoints of successive sectors and starting point of the path (this is the path length, not the Euclidean distance between 2 points in 2D. The input data doesn't contain any information about path geometry)
lists containing ID's of colliding sectors for any sector that has at least one of them.

Additionally, a robot is assigned to each path. It is described using the following parameters:

radius r,
velocity (m/s),
acceleration (m/s2),
deceleration (m/s2).

The task described in this way contains full information required by the simulator.

Special points and events

Figure 2: Special points of a sector.

For each sector, we define some special points lying on the path. They are shown in Figure 2. At a distance of r after the end of the sector lies the release point (rp), indicating the place where robots disk no longer overlaps the previous sector. The critical point (cp) lies at the safe distance (r + bd) before the beginning of a sector, where bd denotes a braking distance - maximum distance needed for the robot to slow down and eventually stop. If the robot starts braking at cp, it will not enter the next sector. Reaching cp and rp by the robot results in sending a message containing its ID to the appropriate ROS topic. This message can be read by the supervisor, deciding which vehicle should obtain movement permission. Movement permission is a one-time permit for passing to the next sector. Such permits can be sent by the supervisor multiple times, and each robot counts permits granted to it. When the cp point is reached, if the permission counter of the given robot is 0, it begins to brake and eventually stops, waiting for the permission from the supervisor. Otherwise, one of the permits is consumed - the robot continues without braking, and the permit counter is decremented. This gives the supervisor full control over entering next stages by the vehicles. Such control is necessary to avoid collisions between vehicles. Structure of ROS topics connecting simulator with the supervisor is shown in Figure 3.

Figure 3: ROS nodes and topics between them.

Usage

First, you need to run a supervisor, necessary for the correct execution of the task. Then run the simulator with the command

rosrun mmrs_simulator simulator <task_file.json>

Where <task_file.json> is a previously prepared JSON file describing the task to be performed by robots. It contains information about their number, and a detailed description of their paths. The sample file may look like this:

{
    "NumberOfVehicles": 3,
    "Vehicles": {
        "Vehicle0": [
            {
                "Colliding": [],
                "Endpoint": 1.6
            },
            {
                "Colliding": [],
                "Endpoint": 2.1
            },
            {
                "Colliding": [],
                "Endpoint": 4.4
            },
            {
                "Colliding": [],
                "Endpoint": 5.2
            },
            {
                "Colliding": [],
                "Endpoint": 6.6
            }
        ],
        "Vehicle1": [
            {
                "Colliding": [],
                "Endpoint": 6.6
            },
            {
                "Colliding": [],
                "Endpoint": 6.8
            },
            {
                "Colliding": [],
                "Endpoint": 7.4
            },
            {
                "Colliding": [],
                "Endpoint": 9.2
            },
            {
                "Colliding": [],
                "Endpoint": 11.6
            }
        ],
        "Vehicle2": [
            {
                "Colliding": [],
                "Endpoint": 7.6
            },
            {
                "Colliding": [],
                "Endpoint": 9.1
            },
            {
                "Colliding": [],
                "Endpoint": 11.4
            },
            {
                "Colliding": [],
                "Endpoint": 12.2
            },
            {
                "Colliding": [],
                "Endpoint": 15.6
            }
        ]
    }
}

Summary