MORSE CODE - PART 3

Since there are a good lot of robot simulators, Gazebo and Stage for the ROS enthusiast, V-REP and webots in the more commercial domain, OpenRave and Microsoft Robotics Developer's Studio are other options one can explore into, therefore when one comes across a new robot simulator, the obvious question is - so what is special about it ? I have been asked this question a few times about MORSE, and is usually accompanied with a comparison with Gazebo. 

My answer is, 

• MORSE is not limited to few robots (10 for Gazebo), I have used Morse for (i) 176 small robots (ATRV) and (ii) 9 PR2 robots, in 2 separate simulations. The limit to the number of robots is not a limitation of the simulator, but rather the limitation of the CPU and graphics card.

Pic.1. Multiple PR2 simulations

• MORSE has bindings with various middlewares ROS, YARP and MOOS, which enables it more versatility [1]. 

Pic.2. ROS binding, rviz visualisation and mapping of MORSE simulation

• There is facility for human robot interaction. Like in motion gaming, direct input from the motion sensor (Microsoft Kinect, ASUS Xtion or Nintendo Wiimote) enables human avatar in the simulator [2]. 

Pic.3. Human avatar

• Since everything happens through Python scripts,one need not care about compilation and executable files. MORSE is 'pythonic' [3] and can be arguably said to be an extension of Blender.

• It is based on Blender and not Ogre, so it doesn't take up a hell lot of resources. Also, the texture and the graphics are more sleeker than Gazebo.

• New robot models can be developed through Blender, and the developmental process is simple [4]. 

Pic.4. Blender model of the robots

• Blender has a huge online community. Hence help and support is easy to find.

I would not be giving a very honest opinion if I do not talk about the shortcomings of MORSE,

• Binding with ROS is a laborious process and often discourages the novice ROS user, particularly due to Python 3 and also because only certain versions of Blender works well with the MORSE + ROS + Python 3 set-up.

• Physics simulation in Blender/MORSE is inferior to Gazebo. Getting force, torque values etc is not yet possible.

The latest release is MORSE 1.2 and more details can be found at http://www.openrobots.org/wiki/morse. A good part of this post came out of discussions at the MORSE mailing list, morse-users at laas dot fr .

REFERENCES

[1] http://www.openrobots.org/morse/doc/latest/user/integration.html
[2] http://www.openrobots.org/morse/doc/stable/user/advanced_tutorials/mocap_tutorial.html

[3] http://www.openrobots.org/morse/doc/stable/user/basic_morse.html

[4] http://www.openrobots.org/morse/doc/stable/user/advanced_tutorials/a_journey_to_a_new_simulation.html

MORSE CODE - PART 2

Playing around with MORSE 0.6, I was tempted to try out basic obstacle avoidance through ROS (Fuerte) nodes on PR2 and ATRV. An obstacle avoidance approach involves a closed loop control system, which is executed by a laser or sonar scan with a 'see the obstacle => turn left', type of algorithm. After some initial hiccups I was able to get it working.

Here are some details of my efforts,

Fig.1. PR2 simulation and its rxgraph

Fig.2. ATRV simulation

in the PR2 simulation, one can see the closed loop of the system in the rxgraph of the ROS nodes.

I am grateful to Michael (kargm at in dot tum dot de) for his help and suggestions. Michael has also made a video of the PR2 obstacle avoidance simulation, https://www.dropbox.com/s/66rpmuyhzkm2ka4/pr2_obstacle_avoidance.m4v .

The codes can be found at, https://github.com/Arkapravo/laser_obstacle_avoidance_morse

TORTUE

TORTUE is an effort to marry a motion sensor with a Roomba base. It was inspired from Turtlebot, Billibot and Oculus. For the base we used Roomba 560 and for the motion sensor we used ASUS Xtion Pro Live. The software platform is ROS Electric. The project is still in its early days and more is being planned for the future.

Fig.1. Concept development for Tortue

Fig.2. First run on 2nd March 2013, Saturday

The video shows a very basic obstacle avoidance behaviour using point cloud.

Fig.3. rxgraph for basic obstacle avoidance

The Tortue team comprises of ,

The project has a home page at github, http://arkapravo.github.io/tortue/. Tortue means Turtle in the French language, which reflects the use of ROS for the robot, ROS has a long term Turtle association and all of their release have a Turtle reference, also ROS softwares (viz. turtlesim) and robots (viz. turtlebot) have such naming. There has been suggestions that tortue has a likeness to wall-e, we do not deny it ! :-)

OBSTACLE AVOID FOR PR2

LASER OBSTACLE AVOIDANCE FOR PR2

One of the basic behaviour a budding roboticist often starts with is obstacle avoidance using sonar or laser scan. While playing with gazebo simulations, we realised that we are yet to try out a very basic laser obstacle avoidance behaviour in the PR2 robot employing the SICK laser. It was not long that we wrote our codes and made our ROS package and started with simulations in gazebo. A surprise awaited us ........

WHAT THE HELL !!!! 

We got an empty world with PR2 and then filled it up with boxes and set our code into action. Much to our surprise the PR2 robot did not try to avoid those boxes, but push them rather awkwardly. 

BOX PUSHING INSTEAD OF OBSTACLE AVOIDANCE

It was after few such 'failed attempts' and cursing our code incessantly that we realised that the issue is with the stretched out arms of the PR2. The distance for the obstacle avoidance to work is at min_range<=0.5, however we never had accounted for the PR2's arms while coding so the obstacle avoidance code is not coming to fore and is restricted by the arm lengths. Thus when the PR2 reaches the obstacle it continues to move and 'push' the obstacles, since gazebo is a physics based simulator thus in a box world it reflects such as a 'box pushing' behaviour. It may be said that such a behaviour arises in the 'emergent' context. Playing around with the code, we finally set it to, min_range<=1.2 which sorted out the issue.

The codes discussed here can be found at, https://github.com/Arkapravo/laser_obstacle_avoidance_pr2, feel free to write to us at Arkapravo Bhaumik (arkapravobhaumik at gmail dot com) and Koushik Kabiraj (koushik dot atti at gmail dot com).

MORSE CODE PART - I

MORSE 0.6

I installed MORSE 0.6 and linked it up with ROS on Ubuntu 12.04 and  it was fun to try out simulations of PR2 and ATRVs. I was interested in simulating a 2 robot system where one robot was guided by ROS nodes while the other was controlled by MORSE. This article is a brief on how I got that working ! 

THE kb_control CODE

Koushik and I have been tying to use kbhit() function to model teleoperation in ROS, however lack of a conio.h  in gcc made us channel our efforts differently (fcntl.h), and develop our codes.

SETTING IT UP IN MORSE

Instead of a single ATRV, I put in 2 ATRVs in my simulation, Castor and Pollux. Castor controlled by ROS nodes while Pollux was by MORSE keyboard. In the Python script (two_atrv.py) it was easy to 'connect up' Castor to ROS and Pollux to MORSE;

To link up ROS nodes with MORSE, remapping of the launch file (kb_control_morse.launch) is done,

The remapping is done by checking the rxgraph and enabling publisher/subscriber connectivity to ensure the interconnectivity of all the nodes. A working rxgraph for this simulation is as shown,

THE SIMULATION

Download the kb_control package from https://github.com/Arkapravo/kb_control and install it, rosmake kb_control

Place the file kb_control/morse/two_atrv.py at /opt/ros/morse/share/morse/examples/scenarii/

Start an instance of the master

Start the morse simulation, cd /opt/ros/morse/share/morse/examples/scenarii/ && morse run two_atrv

Start the kb_node, roslaunch kb_control kb_control_morse.launch

Now you should be able to control Castor with ROS and Pollux with MORSE.Click on the blender screen, the arrow keys will move Pollux around.Click on the kb_control terminal window, the arrow keys will move Castor around.

MORSE 1.0

MORSE 1.0 is slated for release in February 2013, with various improvements and newer features.

ACKNOWLEDGEMENTS

I am thankful to the morse-user mailing list (morse-users at laas dot fr) particularly, Florian Lier (flier at techfak dot uni-bielefeld dot de), Michael Karg (kargm at in dot tum dot de) and Séverin Lemaignan (severin dot lemaignan at laas dot fr). I am also thankful to my friend Vasileios Lahanas (vasileios dot lahanas at hotmail dot com) for his suggestions regarding kbhit() function. 

The codes discussed here can be found at, https://github.com/Arkapravo/kb_control, any issues with the simulation then feel free to write to us, Arkapravo Bhaumik (arkapravobhaumik at gmail dot com) and Koushik Kabiraj (koushik dot atti at gmail dot com).

A vmdk FOR ROS ELECTRIC

ROS INSTALLATION FOR THE NON-INITIATES

For a windows enthusiast, installing ROS is nothing short of a trauma. Install Ubuntu -- Update Ubuntu -- Install ROS -- Configure ROS, all of which over a bad connection can take more than 6-8 hours and getting acquainted with Ubuntu, bash and the ROS commands steepens the learning curve and thus the installation process.

I have been working with a virtual OS (vmdk) on Virtual Box 4.1, though this download is a 3 GB file, however once downloaded it comes pre-installed with ROS electric and Player/Stage on a Ubuntu 10.04 OS. Online installation and configuration is no more an issue. 

DETAILS OF THE vmdk FILE 

Download link; http://ubuntuone.com/1NHvytU3My6TakjeCFgqTi

Download and extract the vmdk file. 

OS details

OS : Ubuntu 10.04.4

login : electric

password : electric

ROS installation details

version : 1.6.9, electric emys

ROS_PACKAGE_PATH is set to ~/ros_packages

Player/Stage installation details

Player version : 3.0.2

Stage version : 3.2.2

The installation files can be found at ~/player-3.0.2 and ~/Stage-3.2.2-Source

  

ETCETERA

1. After a full ROS installation, some basic packages have been downloaded and installed, can be found at ~/ros_packages  
2. The installation of ROS and Player/Stage does not conflict. However while using Stage in ROS, it is advisable to use stageros than stage.
3. C++ code to run Player/Stage can be found at ~/player-3.0.2/examples/libplayerc++ 
4. world and cfg files for basic simulations in Stage can be found at ~/Stage-3.2.2-Source/worlds 
5. gazebo is known to have issues when used on a virtual OS
6. vmdk has been tried and tested in Virtual Box 4.1 on Ubuntu 12.04 host. Prospective users are welcome to try it out in VMWare
7. Make sure to enable 3D acceleration in the Virtual OS
8. Any issues - please email me at arkapravobhaumik at gmail dot com

A GUI FOR ROS !

Once I tried to explain ROS to one of my friends, after about 15 minutes of blabbering and tapping keys on the computer .... he looked at me and asked; "We need to open 4 terminal windows to get this thing moving ?". Though the terminal window is what most of us just love to use, a colourful GUI is always more welcome. Such a GUI, rxDeveloper is provided by Filip Muellers at  http://code.google.com/p/rxdeveloper-ros-pkg/.

The clear advantage that rxDeveloper has over the terminal window is that everything is pictorial and would lure the potentially non-initiated robot enthusiast. I used Stage and Gazebo launch scripts through rxDeveloper and everything worked nearly all right.

The GUI works well with launch files and it doesn't need to explicitly start the master. Tools as rviz, roswtf, rxgraph, rxconsole etc are available as a drop down menu, a bash like script keeps track of the execution of the launch files, each node/process is  pictorially denoted and there are facilities to create, edit and save all kinds of launch files.

With some effort it was  possible to add rxDeveloper to my Applications menu in Ubuntu 10.04,

NOTE : All observations are for rxDeveloper version 1.0b, ROS diamondback version 1.4.10 installed on Ubuntu 10.04 LTS

WALLE@ROS

WALLE@ROS

An interesting recreation in player/stage is walle, which was designed by Richard. I have made a ROS package of the same. The package can be downloaded here, http://mobotica.googlecode.com/files/walle_ros.tar.gz . The simulation may be run with the following command;

rosrun stage stageros `rospack find walle_ros`/world/simple.world 

This stage window should pop-up,
 

The simulation script employs the stage wander controller, and the simulation starts off in the 'PAUSED' mode, left click on the stage window and press P to get things moving. Walle will wander around.

To have a closer look at walle, left click on the stage window and press R (Perspective camera). 
 

NOTE

1. Tested on ROS diamondback, should work on ROS electric
2. Any issues with the ROS package, please write to me at arkapravobhaumik at gmail dot com

TELEOPERATION IN GAZEBO

IROBOT CREATE MODEL IN GAZEBO

We have met the roomba robot in one of my previous articles. Here, I work on some simple teleoperation on it, this time with a 3 dimensional model in gazebo.

I am thankful to Jeff for providing a URDF for the irobot create at http://code.google.com/p/aptima-ros-pkg/ .

TELEOPERATION

I used this roomba model with simple_office.world, which is one of the environments provided by the installation files for gazebo. I was able to move the robot around using teleoperation from teleop_base. 
 

NOTE:

1. The simulations were done in ROS 1.4.10, Diamondback, installed on Ubuntu 10.04 LTS
2. The codes for the simulation are provided at https://github.com/Arkapravo/irobot_create_gazebo

MAPS FROM STAGE SIMULATIONS IN ROS : PART DEUX

SLAM USING TELEOPERATION IN STAGEROS

In my previous article, I discussed realising SLAM using stage's wander controller. Now, I discuss about an alternative method where the robot can be driven around by human participation and thus realising SLAM.

Such can be done in ROS using stage/stageros and teleoperation.

#.1 - Start an instance of the master in a terminal window

roscore

 

#.2 - Start the stage/stageros simulation in a new terminal window 

rosrun stage stageros /path/to/.world file

This world file must not employ the wander controller. The idea is to drive the robot around not let it wander.

#.3 - Start keyboard based teleoperation

rosrun teleop_base teleop_base_keyboard base_controller/command:=cmd_vel 

#.4 - Start gmapping in a new terminal window 

rosrun gmapping slam_gmapping scan:=base_scan

#.5 - Start map server in a new terminal window 

rosrun map_server map_saver

The map will get saved in the directory from where the command for map_server is issued as a pgm file.

Drive the robot around using u,i,k,l etc and check the map as it starts to develop. Drive it around a few times across the whole environment that should give a sufficiently good map. 

The rxgraph for this simulation is as shown;

The pros and cons with the previous method can be seen in contrast;

NOTE : Simulations done in ROS 1.4.10 diamondback

MAPS FROM STAGE SIMULATIONS IN ROS

SLAM USING STAGE'S WANDER CONTROLLER IN ROS

SLAM, Simultaneous Localisation and Mapping; using simulations in stage/stageros  to map the environment based on sensor readings from a mobile robot in the 'wandering' mode may be done as follows;

#.1 - Start an instance of the master in a terminal window

roscore

 

#.2 - Start the stage/stageros simulation in a new terminal window 

rosrun stage stageros /path/to/.world file 

The world file employs stage controller 'wander' hence the robot starts moving immediately and is in a wandering mode. 

#.3 - Start gmapping in a new terminal window 

rosrun gmapping slam_gmapping scan:=base_scan

#.4 - Start map server in a new terminal window 

rosrun map_server map_saver 

The map will get saved in the directory from where the command for map_server is issued as a pgm file.

Run the simulation sufficiently long enough for a good map. While the simulation is running, on running rxgraph in a new terminal window one may see the following graph for the ROS nodes.

SAMPLE OUTPUTS

#.1 

#.2 

 

#.3

 
NOTE : Simulations done in ROS 1.4.9 diamondback

REFERENCES
1) I thank Mac at ROS for his suggestions
2) This blogpost went to be motivation for a ROS tutorial - http://www.ros.org/wiki/stage/Tutorials/MakingMapsUsingStagesWanderController

ROS TUTORIAL, STAGE CONTROLLERS

My first contribution to the ROS community, Tutorial on Introduction to Stage Controllers

Codes for the tutorial are available here

USING GAZEBO

GAZEBO

 

Gazebo is a part of the Player Project. It is a 3D simulator utilising ODE and OGRE. ROS has incorporated Gazebo into their distributions with some minor modification.

GAZEBO@ROS WITH WORLD FILES - A DETOUR FROM THE USUAL

Gazebo, while it is a part of Player Project is used with world files. However, ROS recommend using Gazebo with launch files - these launch files identify the corresponding world file.

However in the spirit of Player/Stage/Gazebo it is possible to run Gazebo with world files from its executable, located at /opt/ros/diamondback/stacks/simulator_gazebo/gazebo/bin .

Thus using ./gazebo with pioneer2dx.world, which is a well known Player Project world file;

1. Start an instance of roscore - gazebo is built with slight modification, so an instance of master (roscore) is needed. The later scripts search for the master.
   
2. Navigate to the gazebo executables directory ( cd /opt/ros/diamondback/stacks/simulator_gazebo/gazebo/bin)  
3. Start Gazebo with pioneer2dx.world file (./gazebo /path/to/pioneer2dx.world)
4. The following window should pop up,  

Trying the rxgraph to check the ROS nodes at work;

Trying with pioneer2at.world file;

The same works for Stage, the executables at /opt/ros/diamondback/stacks/simulator_stage/stage/bin  can be used in a similar manner. The executables, stage and stageros work same with a world file giving 2D simulations. However stage is the primitive Player Project executable and doesn't need a roscore master while stageros is more 'ROS like', needs roscore and works with ROS nodes. 

NOTE 

1. Tested on ROS 1.4.9 Diamondback (Gazebo 0.10.0 and Stage 3.2.2)     
2. pioneer2dx.world and pioneer2at.world files can be found in Gazebo installation files (viz. gazebo-0.10.0/worlds)
3. An alternative is to use, rosrun gazebo gazebo /path/to/pioneer2dx.world file

REFERENCES

(1) I thank John Hsu for his help

(2) stage vs. stageros 

(3) launch files for gazebo

(4) N.Koenig, A.Howard,"Design and Use Paradigms for Gazebo, An Open-Source Multi-Robot Simulator"
(5) Gazebo Test at Care-O-Bot webpage 
(6) Alternative download form the pioneer2dx.world file - http://ubuntuone.com/5pWIiUyo1mhrY2PHP4I86C

ROOMBA@PLAYER/STAGE

ROOMBA ROBOT

The roomba series of robots were designed by iRobot Corporation, primarily for vacuum cleaning and floor washing purposes. However, they are excellent and inexpensive tools to study robotics.

ROOMBA@PLAYERSTAGE

In Player/Stage installation files, one can find the irobot.inc file at; Stage-3.2.2-Source/worlds/irobot.inc

Making the irobot.inc file work with the sick laser one can get simple simulations.

ROOMBA@ROS

Roomba also has a  ROS package

ROOMBA@WEBOTS

Roomba icreate is  ready design in the the robot simulator webots. Though webots is not a free software, but it finds popularity in various universities. 

ROOMBA@GAZEBO 

For some samples of Roomba simulation in Gazebo simulator see my post, http://mobotica.blogspot.in/2012/01/teleoperation-in-gazebo.html