MORSE
...in 15 min

MORSE video for the 1.0 release, in Feb. 2013
Lasts 1'42"

Presentation outline

The MORSE project
Simulating with MORSE
MORSE Principles
- Level of realism
- Components
- Inner loop
- Interfaces
Human-Robot Interaction
Massive simulations
Roadmap

The MORSE project

100% open-source, permissive BSD-like license
Code, issues, roadmap available on GitHub
Release 1.0 in Feb. 2013, 1.1 due for Sep. 2013
~30K LOC, mostly Python

The MORSE community

Academic project, baked by academics
Initiated at LAAS-CNRS in 2009
As of Apr. 2013, contributions by 12 institutions worldwide

The MORSE community

15 different individual contributors for the last releases
> 630 commits in 2013 only
> 150 users on morse-users
... + the Blender and Bullet communities!

Blender Game Engine + Bullet

primary a 3D modeller
provide a 3D game engine, support shaders
Switch from the modeller to the simulation == press 'P'
BGE: written in C++, extensible in Python + logic bricks
Bullet is integrated to the BGE, state-of-the art open-source library
support for rigid bodies and soft bodies simulation
limited support for dynamics (Vehicle class)

What if...

...we want to simulate a PR2 mapping a kitchen environment?

To show how easy it is to set up a scenario to perform 2D Mapping with standard ROS components, I want to demonstrate a bit the MORSE workflow by giving you an example of the steps you have to take on the MORSE side...

$ morse create pr2_kitchen

This example requires latest git version of MORSE

First choose a name for your scenario and create it. MORSE takes care about the rest and creates the needed files and folders...

$ vim pr2_kitchen/defaults.py

from morse.builder import *

robot = BasePR2() # Bare PR2 model
robot.add_default_interface('ros') # control PR2 via ROS

odometry = Odometry() # Sensor for Odometry information
odometry.add_interface('ros', topic="/odom")
robot.append(odometry)

keyboard = Keyboard() # Keyboard control
robot.append(keyboard)

scan = Hokuyo() # Hokuyo 2D laser scanner
scan.translate(x=0.275, z=0.252)
scan.add_interface('ros', topic='/scan')
robot.append(scan)

env = Environment("kitchen.blend") # load custom 3d model

In the auomatically generated defaults.py file, we can define our simulation scenario...
In the first 2 lines: PR2 + ROS
Odemetry sensor + keyboard control (mention PR2_keyboard_teleop)
Custom 3 model of the env (in this case blender, but 3D Studio etc. also possbile via Blender import)

$ morse run pr2_kitchen

Using standard ROS robot_state_publisher and gmapping

$ morse run pr2_kitchen

Using standard ROS amcl localization

Having built the map, we can also use AMCL for localization...

Navigation using move_base and AMCL localization

[...]	
motion = MotionXYW() # Motion controller
motion.add_interface('ros', topic='/cmd_vel')
robot.append(motion)
[...]

$ morse run pr2_kitchen

MORSE specific features

Adjustable degree of realism
Completely scriptable via Python
Middleware independence
Human avatar for HRI scenarios
Distributed multi-node simulation
Friendly community !

ROS users know Gazebo, and while Gazebo is a great simulator, there are also good reasons to take a closer look at MORSE!
Explain why I use MORSE: Human component, High-level sensors make it easy to test high-level resoning algorithms whithout dealing too much with low-level components (perception etc.)
High-level sensors: If you don't want to deal with navigation, use waypoint actuator, if you want to skip perception, use semantic camera
+ other avantages

MORSE Principles: level of realism

Allow to test only what you are interested in

Full stack of components (low-level simulated sensors / actuators)
High-level components only (higher-level simulated sensor / actuators

Levels of abstraction: level 0 — Levels of abstraction: vision level

This set of 4 slides show how MORSE can be used at different level of abstraction: from 'few things simulated, lot of robot software running' to 'almost everything simulated, only high-level robot softwares'.

Levels of abstraction: level 1 — Levels of abstraction: depth map level

Levels of abstraction: level 2 — Levels of abstraction: terrain level

Levels of abstraction: level 3 — Levels of abstraction: semantic level

MORSE Principles: Components

MORSE simulations are made of components
Base components are sensors, actuators or robots,
Other components are interfaces, modifiers and overlays
They are defined by a mandatory Python description,
They optionally come with a (Blender) 3D mesh.

A click on the image redirect to MORSE Component Library in the on-line doc.
Scroll there to quickly show the available components.

MORSE Principles: Inner loop

2 interactions modalities: datastreams and services,
datastreams: published by MORSE for sensors, read for actuators,
strong decoupling: components are not aware of surrounding interfaces/modifiers,
modifiers alter the sensors/actuators data, typically to add noise,
components' local data are exported/imported by external interfaces like sockets,
services: RPC-style interaction, can be synchronous or asynchronous

MORSE Principles: Interfaces

Generic: sockets, text,
Specific to robotics: middlewares
- GenoM/pocolibs
- MOOS
Mapping to interaction semantics: RPC-oriented or datastream-oriented
Language bindings available for Python. Easy to develop for other languages through the socket interface.
Simulation introspection possible through sockets interface