Middlewares provide a means for the simulated data to be shared with external programs. MORSE is designed to be middleware independent, so that its internal functioning is not tied no any one particular middleware, but it is capable of communicating with any type of architecture.
The binding of middlewares with the components in the scene is done using the concept of hooks.
Refer to the table below for details regarding which features are actually supported for each middleware.
The table below summarizes the level of support of MORSE features for each middleware.
When a component is supported (✔), we specify the middleware-specific format we use (like Viam or YarpImage).
If no format is specified, MORSE uses its default serialization mechanism, i.e., a straight serialization of the JSON representation of the component data. Please refer to each middleware to know more about it.
Feature | Text file based | Raw sockets | YARP | ROS | Pocolibs | Moos | |
---|---|---|---|---|---|---|---|
Communications | |||||||
IN/OUT Data streams | ✔ | ✔ | ✔ (ports) | ✔ (topics) | ✔ (posters) | ✔ (database) | |
RPC (requests) | ✘ | ✔ | ✔ | ✔ (only services) | ✔ (requests) | ✘ | |
Sensors | |||||||
Accelerometer | ✔ | ✔ | ✔ | ✔ Twist | ✘ | ✔ | |
Battery | ✔ | ✔ | ✔ | ✔ Float32 | ✘ | ✔ | |
GPS | ✔ | ✔ | ✔ | ✔ PoseStamped | ✔ POM_ME_POS | ✔ | |
Gyroscope | ✔ | ✔ | ✔ | ✘ | ✔ POM_ME_POS | ✔ | |
Human posture | ✔ | ✔ | ✔ | ✘ | ✔ SPARK_CONFIGURATION | ✘ | |
IMU | ✔ | ✔ | ✔ | ✔ Twist | ✘ | ✔ | |
Odometry | ✔ | ✔ | ✔ | ✔ Odometry | ✘ | ✔ | |
Pose | ✔ | ✔ | ✔ | ✔ Twist | ✘ | ✔ | |
Proximity sensor | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | |
ptu_posture | ✔ | ✔ | ✔ | ✘ | ✔ PLATINE_STATES | ✔ | |
Rosace (victim sensor) | ✔ | ✔ | ✔ | ✘ | ✘ | ✘ | |
Semantic camera | ✔ | ✔ | ✔ | ✔ String | ✔ VimanObjectPublicArray | ✘ | |
Sick (Laser range finder) | ✔ | ✔ | ✔ List (x, y, z) | ✔ LaserScan, PointCloud | ✘ | ✔ | |
Thermometer | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | |
Velodyne | ✔ | ✘ | ✘ | ✘ | ✔ Velodyne3DImage | ✘ | |
Video camera | ✘ | ✘ | ✔ YarpImage | ✔ Image | ✔ viamImageBank | ✘ | |
Actuators | |||||||
armature actuator | ✘ | ✔ | ✔ | ✔ | ✘ | ? | |
Straight line movement | ✘ | ✔ | ✔ | ✘ | ✘ | ✔ | |
gripper | ✘ | ✔ | ✔ | ✔ Bool | ✘ | ? | |
KUKA LWR arm | ✘ | ✔ | ✔ | ✔ JointState | ✔ Gb_q7 | ✘ | |
light | ✘ | ✔ | ✔ | ✔ Bool | ✘ | ? | |
orientation | ✘ | ✔ | ✔ | ✘ | ✘ | ? | |
Mitsubishi PA-10 arm | ✘ | ✔ | ✔ | ✘ | ✘ | ✘ | |
Pan-Tilt unit | ✘ | ✔ | ✔ | ✔ JointState | ✔ POM_SE_POSTER or PLATINE_AXIS_STR | ✘ | |
steer_force | ✘ | ✔ | ✔ | ✘ | ✘ | ? | |
(v, w) motion control | ✘ | ✔ | ✔ | ✔ Twist - supports as well (Vx,Vy,ω) | ✔ GENPOS_CART_SPEED | ✔ | |
waypoint motion | ✘ | ✔ | ✔ | ✔ (set of Pose2D) | ✘ | ✘ |
It is no longer necessary to link another object into the scene to get access to middleware connectivity. In the current version of MORSE, it is enough to properly describe the middleware that will be used by each component.
The simplest way to configure the middlewares is by using the Builder API. This process is explained in the basic tutorial and the yarp tutorial.
Alternatively, when building a scene using the Blender interface, as explained in the tutorial, you have toadd the full description of the middleware into the file component_config.py that should be part of every MORSE scenario file. In that file, the dictionary component_mw lists the components and the middleware they will use to export/import their data. The unique names of the components are the keys of the dictionary, and the values are lists. The first item in the list is the full path and class name of the middleware you wish to use, followed by the name of the middleware function that should be called by the component to share its data. Additional parameters may be necessary to use specific bindings between particular components and middlewares. More information about the format of this file can be found in the hooks documentation.
New middlewares can be added to MORSE by following these instructions.