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

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).