Topological Map Robot Control

First assignment of experimental robot laboratoy.

Introduction

Main idea of building a robot that changes position from one location to another and during movement consumes the battery and must return to the initial location to recharge. The robot has to visit all locations, so you need to record the time when it passes away from one location.

The map considered for this assignment

Tools

To solve the following problem I used various tools, like:

1. Protègè: it was used to create the topological map and define the logical part.
2. aRMOR: it was used to load topological map and manipulation and query classes.
3. Arch_skeleton: it was used to build a plan between the points defined on the map.
4. SMACH viewer: to view robot status

Documentation

For more information on nodes and sofar then refer to Documentation

Software architecture

UML graph

Robot state node

Consisting of a node that allows the client to use the GET_POSE and SET_POSE service and communicate with other nodes.

Motion Controller

It is built by two controller_client and controller nodes to move the robot between different locations.

Motion Planner

It is built by two planner_client and planner nodes to generate a map of points to switch from one room to another (points are defined inside the map / see map section).

aRMOR
Armor package is built from 6 nodes which allows me to do:

• Manipulation in ontology map
• Query from ontology map
• Exception on ontology map
• Architecture name mapper for each node via name_tag

Finite state machine

Inside this node, most of the functions have been defined and it allows me to view the robot status via GUI SMACH viewer

rqt graph

rqt graph

/finite_state_machine node starts listing the rooms that have not been visited in a long time, consider the first room in the list as the /target_point post message to /motion/palnner. planner builds a /path and publishes it to /motion/controller. Controller will bring robot to destination and /finit_state_machine node will update /smach_viewer.
The messages communicated between the nodes are done through the GET_POSE and SET_POSE service defined in /robot_state node.

Temporal diagram

temporal diagram

At the beginning Launch file topological_map_robot_control.launch, starts six nodes and one armor service. The service works directly with the FSM node and the topological_map.owl map. The service allows the FSM node to modify, check, and load the topological_map.owl map.

In addition Launch file sets the size of the environment at the planner node and the initial position of the robot in the environment at the controller_client node. Parameters were used to set the values.

FSM node publish \target_point to planner_client. Planner make a path to use different point to reach goal and publish \path to controller_client node.

Nodes in pairs like MOTION PLANNER and MOTION CONTROLLER start working with each other through SimpleAction. The first node has role of server and the second node has role of client, client uses CALLBACK to connect to server and server uses FEEDBACK to control status of client.

Usage

• You have to creat your own repository, to do that

  $ mkdir ros_ws /src
  $ cd src
  

• Frok package from my repository

  $ git clone https://github.com/mrhosseini75/tmrc.git
  $ cd ..
  $ catkin_make
  

• You need to install SMACH viewer

  $ sudo apt-get update
  $ sudo apt-get install ros-noetic-smach ros-noetic-smach-ros ros-noetic-executive-smach ros-noetic-smach-viewer
  

• Now you can launch program

  $ roslaunch tmrc topological_map_robot_control
  

!!!WARNING!!!
In scripts, the system path has been specified in order to use the carried package. As following way:

import sys
sys.path.append('/root/ros_ws/src/tmrc')

if you clone repository in diffrenet path, to have to update this line of code.

Video

smach_viewer.mp4

Hypothesis and environment

Map

System’s features

• Final environment was considered in this way. A map with size 10x10 and there are 7 points indicating different locations. Planner uses these points to create /path.
• Each time robot passes by a room the time is recorded in the visitedAt method and it updates the list of room to visit.
• If more than 7 seconds have passed since the last time the robot was there, the room was on the URGENT list.

System’s limitations

• The robot only charges in room E, and can only charge up to 20 percent.
• Every time the robot moves the battery is consumed and if it remains stationary in a room the battery is not consumed.
• If the robot battery reaches 7 percent, system indicates room E as the first urgent case to visit.

Possible technical Improvements

• It is possible to add a world in which the robot's behavior can be better visualized.
• Walls have not been considered so you can use world and /laser_scan topic to create an obstacle_avoidness node.
• No control over robot speed, you can use /cmd_vel topic to generate velocity.

Autor and contact

• Mohammad Reza Haji Hosseini
• email: mrhhosseini75@gmail.com