Skip to content

Software

Jump to bottom
Bas Janssen edited this page Jul 9, 2017 · 21 revisions

Table of Contents

Software

This page details the design of the software, the prerequisites and the installation of the software package.

Overview

This software package aims to implement the decentralized control system for a swarm or fleet of robots for the Multirobot Logistics System.

The software is designed to run in a ROS multimaster environment. This means that each robot, (un)load point and the system interface run a ROS master, and specified topic are synced between these master systems. Using these topics exchange messages containing commands for the robots, e.g. move there and pick up this object, or responses sharing data between the robots, e.g. I have this amount of free space and I'm this far away from that point.

Demo Videos

These videos show the progress made with the software in simulation.

This video was used for the first pitch:

This video was used for the second pitch:

This video show the final product in simulation:

Prerequisites

  • Ubuntu 14.04 + ROS Indigo
  • ros-indigo-multimaster-fkie
  • Turtlebot stack

Installation

  • Install Ubuntu and Ros
  • Install the multimaster-fkie package and the turtlebot stack
  • Clone this repository and copy the catkin_ws folder
  • Compile the package in the catkin_ws folder

Running

To run the system in simulation mode use the following command:

roslaunch multirob_test multirob_test.launch
To run the system on live robots modify the command as follows:
roslaunch multirob_test multirob_test.launch sim:=false
If you want to create your own map using gmapping, modify the command to:
roslaunch multirob_test multirob_test.launch mapping:=true

Design

Based on the decision tree, drawn in draw.io, the software has been designed to handle the defined commands.

Written in C++ and based on a multi-threaded design, the software is build on top of ROS and the turtlebot stack. The multi-threading has been chosen to handle the decisions after a message has been received. This to allow multiple messages to be received in rapid succession. The current implementation can result in undefined behaviour as the threads are spun up and left to finish their task. The thread is not reattached to the main thread.

For the software code click this link : software code.

Recommendations

Program

  • Delivering the products to multiple locations is now done by order of the locations, this has to be done according to the distance between the robot and each location and the one who's closest will be first.
  • The program now allows the robot to transfer the products ones with another robot, if the robot has products from three locations or more the robot must be able, if other robots are available, to transfer products more than once.
  • If the robot request to transfer products with another robot, but no robots are available for this, the robot must be able to deliver the products itself.
  • If the robot doesn't have a task, it can go to a predefined location so the robots are more divided around the field. While executing this the robot must be able to receive new commands and must see these as higher a priority. Driving to a predefined location always comes last.
  • The product choosing between robots can be optimized. This can be done to let the robots communicate with each other who will take how many of each product and if there is a product that has to be split they tell each other this and compromise who takes how many products for that specific location.

Real world test

  • Multimaster-fkie requires the masters not to have nodes with the same name. This means that the robots have to be namespaced. It is recommended to research this further or build a custom solution to share the required data.
  • If the modified turtlebots are used, the URDF needs to be modified to represent the turtlebot correctly.
Clone this wiki locally