Page tree
Skip to end of metadata
Go to start of metadata

This page contains information about the robot monitoring and control using the Web Tools packages available in ROS.

1. Why the need of a monitoring and control web tool ?

  1.  To check if nodes are running properly
  2.  To check if topics are published
  3.  To check if parameters needed by nodes are being properly set up
  4.  To have the possibility of checking whether services are alive
  5.  To have the possibility of restarting nodes

 

2. Why a web tool ?

  1. Because starting nodes from a terminal implies a certain degree of in-depth knowledge of the workflow
  2. Because it can be used by operators lacking the required in-depth knowledge
  3. Because a certain independence from a certain OS could be achieved
  4. Because it provides the availability of accessing it from multiple devices: computer, phone, tablet, etc.

3. ROSBridge

       ROSBridge provides a set of tools that enable the development of web tools that could easily interact with the ROS environment. It is based mainly on JavaScript technologies that communicate with ROS using WebSockets.

 

 

4. Monitoring tool

The monitoring tool is found in the baxter_monitoring_tool package along with all the needed components. The package has the following structure:

  • build      - contains the source files for AngularJS, Bootstrap, ROSLibJS required for the functioning of the tool
  • html        - contains the monitoring tool as an html page
  • js            - contains the AngularJS controllers required by the monitoring tool
  • launch   - contains a launch file that when executed automatically launches the monitoring tool back-end functionalities
  • msg       -  contains the definition of specific messages that the tool uses, which will be presented below
  • scripts - contains the additional back-end functionalities of the tool: status server, file parser developed in Python
  • src         - contains the part of the similar functionalities developed in C++
  • srv         - contains the definition of the specific service file, statusInfo.srv

 

 

 

4. Installation

Icon

The monitoring tool ha been developed under Ubuntu 14.04 using ROS Indigo.

The tool has been developed under Ubuntu 14.04 using ROS Indigo

The current project has been developed using AngularJS and Bootstrap

 

In order to be able to use the tool in its current state or to further develop it you need to make sure several packages are installed:

  1. Install the rosbridge_suite using the following command in a terminal sudo apt-get install ros-indigo-rosbridge-suite
  2. Download AngularJS from the following link. In case an Internet connection is always available then it can be configured so that AngularJS is downloaded any time the web page is loaded.
  3. Download Bootstrap from the following link. In case an Internet connection is always available then Bootstrap can be configured to be automatically downloaded any time the web page is loaded.
  4. Make sure Python and especially the multiprocessing module are installed. If  not install multiprocessing with sudo pip install multiprocessing
  5. Download roslibjs from the following link. Copy it into your catkin workspace and include it properly into your HTML page.

If choose the option of downloading package from the repository then carry out step 1 and additionally make sure that step 4 is in accordance. The package already contains all the other dependent components

such as: Bootstrap, AngularJS, ROSlibJS.

5. What does the tool know to do?

While being under development and maintenance a stable version of the tool has achieved. The tool is able to carry out the following actions:

  1. Provide a list of active/running nodes
  2. Provide a list of the topics being published and their types
  3. Provide a list of the nodes required for the demo
  4. Start a node
  5. Kill a node
  6. Provide a list of the arguments that nodes have
  7. Test whether a node is alive or not (pinging)
  8. Connecting/disconnecting to a certain host

Functionality under development:

  1. Each demo has a master launch file, that launches all the compulsory nodes or launch files for the demo. The functionality is to recursively parse this launch file plus all the possible nested ones and to obtain
    all the nodes that are required. After this the availability of each of them should be tested and the ones not running should be automatically started.

 

6. How to use the tool?

The first step in the process of using the tool is to start therosbridge server.

1.Start the rosbridge server and status server service

  1. Open a new terminal (shortcut Ctrl+Alt+T)
    Execute ./baxter.sh (baxter shell)
    Launch the rosbridge server , in the same terminal enter roslaunch rosbridge_server rosbridge_websocket.launch you can specify the port as roslaunch rosbridge_server rosbridge_websocket.launch port:=port_value

  2. In a new terminal after you have executed the baxter shell start the status server service with the command rosrun baxter_monitoring_tool status_server.py
    The previous steps can be carried out in one action with the command roslaunch baxter_monitoring_tool baxter_monitoring_tool.launch. Make sure that the baxter shell has been previously ran in the terminal.

    Then go to the html file in the package and open the monitor.html page

2. Open and use the web page

Go to the html folder and open the monitor.html page. If everything is successful you will see something like below.

 

Fill in the localhost and port spaces with the proper values, for localhost usually the values of localhost is used and for the port number the port number on which the websocket is listening.

After this step hit the Connect button

 

3. Use the commands provided by the interface.

If the connection process went well then you can start using the facilities provided by the interface. The first thing to be noticed when connection has been established is that the Connection button will be replaced

by a Disconnect button.

You can query the list of published topics by pressing Get Topics and then visualize the list by filling in the tick.

You can query the list of running nodes by pressing Get Nodes and then visualize the list by filling in the tick.

                    - By clicking on an entry in the list of running nodes a query will appear in which different actions for the node (depending on its state) are available such as: ping node, kill node, start node.

You can query the list of required nodes by pressing Get Required Nodes and then visualize the list by filling in the tick.

                    - By clicking on an entry in the list of required nodes a query will appear in which different actions for the node (depending on its state) are available such as: start node, kill node, ping node.

7. Insights found during development

  1.   ROS provides a lot of means of querying the running nodes, published topics, functionalities of killing, pinging a node. However, it does not provide a functionality of starting a node programatically. 
    A node can be   started either from a terminal with rosrun or from a launch file.  Thus, from the research carried out, one way of starting a node from code is to start it as a subprocess. In this manner, a
    ROS Service has been developed  and when the request of starting a node is made then  using multiprocessing the node is started as a daemon process. Why as a daemon process? Because, if not the
     mother process is blocked untill  the subprocess finishes  case in which the service is out of order and it cannot handle other requests. If the service dies then the subprocesses will run as nodes in the
     background. They can be killed either with the kill functionality of the tool or from the terminal with rosnode kill node  or when the roscore is shut down.

  2.  Another issue found out during development are performance related ones. This happened when querying the available topics. One way is to get them directly from the web page using roslibjs and the
    other way is to issue a service call that would use the rospy Pyhton module.  When tested on a real Baxter robot where the number of topics is >200, then the former version was slower than the latter one.
    When tested on a simple roscore with several dummy nodes and topics than both versions were fast enough.