- Install the rosbridge_suite using the following command in a terminal sudo apt-get install ros-indigo-rosbridge-suite
- 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.
- 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.
- Make sure Python and especially the multiprocessing module are installed. If not install multiprocessing with sudo pip install multiprocessing
- Download roslibjs from the following link. Copy it into your catkin workspace and include it properly into your html HTML page.
5. Current functionalities of the tool
The tool is currently under development and it is likely to suffer modifications. The current functionality consists of:
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:
- Provide a list of active/running nodes
- Provide a list of the topics being published and their types
- Provide a list of the nodes required for the demo
- Start a node
- Kill a node
- Provide a list of the arguments that nodes have
- Test whether a node is alive or not (pinging)
- The possibility of connectingConnecting/disconnecting to a certain host
- 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
- 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
- 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
6. Development issues
- 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 a 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.
- 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.