Transient

Developing a navigagation stack for swarm robots.

⚠️ Code is buggy ⚠️

1.0 Introduction:

This repository contains code & resources for thesis research project, titled "Transiently Informed Robotic Swarms for Search & Rescue", being undertaken at the Indian Institute of Science, Bengaluru.

1.1 Thesis Advisors: Dr. Vishwesha Guttal [1] & Dr. Debasish Ghose [2].

[1] - Center for Ecological Sciences, Indian Institute of Science, Bengaluru.
[2] - Department of Aerospace Engineering, Indian Institute of Science, Bengaluru.

• The main purpose of this package is to design a navigation stack for swarm robots, inspired by transient behaviour as seen in ant groups. [3]

• We hypothesize, that such an architecture will bring about a reduction in the amount of energy expended by the entire swarm, all the while being directed along the optimal path to the destination, in-turn set by a user.

• Currently, this repository contains catkin_ws, which is the catkin workspace for the project. It contains the transient package which in-turn comprises of the launch files and scripts.

2.0 Pacakge Overview:

2.1 Scripts

• 2.1.1 Movement: This script brings together the different parts of the navigation stack together, and acts as the central script triggered at the start of the autonomous simulations.

• 2.1.2 Odometry: This script subscribes to the odometry data being published by the /odom topic. The coordinates are then passed over to the goal_checker.py script.

• 2.1.3 Autonomous Navigation: This script charts a path to a given set of coordinates from the mapping data accumlated by the gmapping module. The robot then autonomously traverses this path.

• 2.1.4 Goal Checker: This script subscribes to the /move_base/goal topic and checks if the robot has reached the coordinates specified by the user.

• 2.1.5 Scan: The node in this unit subscribes to the /scan topic and publishes the LiDAR unit required to carry out obstacle avoidance during autonomous navigation.

• 2.1.6 MathWiz: The processing of the del_x & del_y & waypoint generation is carried out by this unit.

2.2 Launch Files

• 2.2.1 Gazebo Launch: This .launch file triggers the Gazebo environment and the playpen configuration of the prototyping world.

• 2.2.2 RViz Launch: This .launch file spawns the control panel for the robot interaction tools.

• 2.2.3 Exploration Launch: This .launch file evokes the environment exploration package, which enables the robot to map an unknown portion of the surroundings, utilizing 3 smaller packages: 1. Adaptive Monte Carlo Localization (AMCL) 2. move_base 3. Frontier Exploration

• 2.2.4 Transient Launch: This .launch file calls the three previous .launch files at once, instead of running 3 seperate launch files in 3 different terminals.

3.0 Usage:

3.1 We initialize the preinstalled Husky playpen environment to test of the scripts. Previously, the scripts were tested out in the empty_world environment, but we have since shifted to playpen.

	roslaunch transient transient.launch

3.2 Once the Gazebo world has launched with the Husky at the center, we invoke the movement.py script, which triggers the navigation stack.

	python movement.py

3.3 To debug the package and the stack during run-time we genereate an RQT_GRAPH to check the transaction of topics between the individual nodes.

	rosrun rqt_graph rqt_graph

4.0 Snapshots:

4.1 Frontier Exploration Progression:

• Fig 4.1.1 Initially provided a 4-sided polygon for exploration.

• Fig 4.1.2 Due to delays in the map updating process, there is a mismatch between the map being generated and the pointclouds being provided by the LiDAR.

• Fig 4.1.3 The initially provided 4-sided polygon area has been explored by the agent. With enough number of iterations, the map update syncs up with the pointclouds being generated.

5.0 Known Issues:

• 5.1 Currently, the repository contains basic movement scripts. Other packages are lined up, and will ne integrated with rospy before being pushed here to the repository.

• 5.2 ROS code requires python2.x to function and not python3.x. Hence, take make sure that these commands are syntactically correct at execution.

• 5.3 The Frontier Exploration stack which is a part of this package is pretty buggy. At times the exploration of a given region can fail, due to a number of different reasons, which are currently being worked out.