Sensors

This page describes the predefined sensors and their parameters.

Sensor definition and common parameters

A sensor is attached to a vehicle by adding an XML block with the tag name <sensor>.... </sensor> inside:

the <vehicle>...</vehicle> that instantiates a particular robot, or
the <vehicle:class> to have all vehicles of that type with the same sensors installed.

All sensors, via the common base C++ class mvsim::SensorBase, have the common parameters below, with their meaning explained in the XML comments.

<!--
 ``class``: One of the registered sensor classes.
 ``name``: A name for the sensor, must be unique for each robot. If not provided,
           an automatic name will be generated. The name is important since it is
           used when publishing the sensor ROS or ZMQ topics.
-->
<sensor class="camera" name="camera1">
        <!-- Period (in seconds) between each sensor observation.
             Mathematical expressions can be used with $f{} to specify rates in Hz.
         -->
        <sensor_period>0.1</sensor_period>
        <!-- <sensor_period>$f{1/20.0}</sensor_period> -->

        <!-- See notes below -->
        <visual>
                ...
        </visual>

        <!-- Publish sensor on MVSIM ZMQ topic? (Note, **not** related to ROS at all) -->
        <!-- <publish>
                <publish_topic>/${PARENT_NAME}/${NAME}</publish_topic>
        </publish> -->
</sensor>

The <visual> tag is explained in the World XML definition of VisualObject, and the <publish> tag in World XML definition of Simulable entities, since those tags are common to sensors and many other entities.

Also, note that you can use the XML-level variables ${PARENT_NAME} and ${NAME} anywhere inside the sensor definition tag to refer to the parent vehicle and own sensor names, respectively.

Each sensor class has its own additional parameters, listed in the next sections.

3D LiDARs

HELIOS 32 (26 deg FOV)

HELIOS 32 (31 deg FOV)

HELIOS 32 (70 deg FOV)

All parameters available in helios-32-FOV-70.sensor.xml

File: mvsim_tutorial/definitions/helios-32-FOV-70.sensor.xml

<sensor class="lidar3d" name="${sensor_name|lidar1}">
    <pose_3d> ${sensor_x|0.5}  ${sensor_y|0.0}  ${sensor_z|0.7}  ${sensor_yaw|0.0} ${sensor_pitch|0.0} ${sensor_roll|0.0}</pose_3d>

    <!-- vert_fov_degrees: If defined, a symmetric vertical FOV is used.
         The alternative is using a custom list of angles in "vertical_ray_angles"
    -->
    <!-- <vert_fov_degrees>${vert_fov_degrees|70}</vert_fov_degrees> -->

    <vert_nrays>32</vert_nrays>
    <vertical_ray_angles>-55.020 -52.081 -49.142 -46.204 -43.265 -40.326 -37.387 -34.449 -31.510 -28.571 -25.632 -22.694 -19.755 -16.816 -13.877 -10.939 -8.000 -6.667 -5.333 -4.000 -2.667 -1.333  0.000 1.333 2.667 4.000 5.333 6.667 8.754 10.841 12.929 15</vertical_ray_angles>

    <!-- Horizontal / azimuth angular resolution:
        The rotation of the Helios sensor configurable: 5 / 10 / 20 Hz
        Firing timing of the sensor is fixed at 55.296 μs (=18.084 kHz).

        Set the "sensor_rate" (Hz) variable from the parent XML to automatically
        adjust the number of points per horizontal line.
    -->
    <sensor_period>$f{1.0/${sensor_rate|10}}</sensor_period>
    <horz_nrays>$f{(1.0/${sensor_rate|10})/55.296e-6}</horz_nrays>

    <!-- 1.0=minimum (faster), larger values=potentially finer details captured -->
    <horz_resolution_factor>${horz_resolution_factor|1.0}</horz_resolution_factor>
    <vert_resolution_factor>${vert_resolution_factor|1.0}</vert_resolution_factor>

    <!-- Depth ratio (0 to 1) between adjacent depth image to allow linear interpolation of ranges -->
    <max_vert_relative_depth_to_interpolate>${max_vert_relative_depth_to_interpolate|0.3}</max_vert_relative_depth_to_interpolate>
    <max_horz_relative_depth_to_interpolate>${max_horz_relative_depth_to_interpolate|0.1}</max_horz_relative_depth_to_interpolate>

    <range_std_noise>${sensor_std_noise|0.005}</range_std_noise>
    <min_range>${min_range|0.20}</min_range>
    <max_range>${max_range|110.0}</max_range>
    
    <visual> <model_uri>${MVSIM_CURRENT_FILE_DIRECTORY}/../models/velodyne-vlp16.dae</model_uri> <model_roll>90</model_roll> </visual>

    <generate_intensity>${generate_intensity|false}</generate_intensity>

    <!-- Publish sensor on MVSIM ZMQ topic? (Note, this is **not** related to ROS at all) -->
    <publish enabled="${sensor_publish|false}">
        <publish_topic>/${PARENT_NAME}/${NAME}</publish_topic>
    </publish>
</sensor>

OUSTER OS1

Velodyne VLP-16

RGB camera

A regular RGB (color) pin-hole camera (without lens distortion at present). The user must provide the camera intrinsic and extrinsic parameters:

IMU

An inertial sensor that measures (in the current version of MVSim):

3D linear proper acceleration.
3D angular velocity.
(Optionally) 3D orientation as a quaternion.

IMU noise model

The IMU sensor implements the standard continuous-time stochastic error model described in [Forster2016], with two independent noise components per axis for both the gyroscope and accelerometer channels:

White noise (measurement noise).: Zero-mean Gaussian noise added to every sample. Configured via the *_white_noise_std_noise parameters (standard deviation in the channel units: rad/s for gyroscope, m/s² for accelerometer).
Bias random walk (in-run stability / drift).: A slowly-varying bias modelled as a Wiener process (integral of white noise). Configured via the *_random_walk_std_noise parameters (units: rad/s/√s for gyroscope, m/s²/√s for accelerometer). Set to 0 (default) to disable bias drift.

The discrete-time update at each simulation step of duration $\Delta t$ is:

\[\mathbf{b}_{k} = \mathbf{b}_{k-1} + \mathcal{N}\!\bigl(\mathbf{0},\;\sigma_{\mathrm{rw}}^{2}\,\Delta t\;\mathbf{I}\bigr)\]

\[\tilde{\mathbf{m}}_{k} = \mathbf{m}_{k} + \mathbf{b}_{k} + \mathcal{N}\!\bigl(\mathbf{0},\;\sigma_{w}^{2}\;\mathbf{I}\bigr)\]

The four XML parameters are:

Parameter	Default	Description
`angular_velocity_white_noise_std_noise`	`2e-4`	Gyroscope white noise σ (rad/s)
`linear_acceleration_white_noise_std_noise`	`0.017`	Accelerometer white noise σ (m/s²)
`angular_velocity_random_walk_std_noise`	`0`	Gyroscope bias random walk σ (rad/s/√s)
`linear_acceleration_random_walk_std_noise`	`0`	Accelerometer bias random walk σ (m/s²/√s)

Note

The legacy parameter names angular_velocity_std_noise and linear_acceleration_std_noise are still accepted and map to the corresponding *_white_noise_std_noise parameters.

Example — a noisy tactical-grade IMU with bias drift:

<include file="$(ros2 pkg prefix mvsim)/share/mvsim/definitions/imu.sensor.xml"
  sensor_x="0.0" sensor_y="0.0" sensor_z="0.0"
  sensor_period_sec="$f{1/200.0}"
  sensor_angular_velocity_white_noise_std_noise="1.7e-4"
  sensor_linear_acceleration_white_noise_std_noise="5.88e-3"
  sensor_angular_velocity_random_walk_std_noise="1.0e-5"
  sensor_linear_acceleration_random_walk_std_noise="3.0e-4"
/>

[Forster2016]

C. Forster, L. Carlone, F. Dellaert, D. Scaramuzza, “On-Manifold Preintegration for Real-Time Visual-Inertial Odometry”, IEEE Transactions on Robotics, vol. 33, no. 1, pp. 1-21, 2016.

2D laser scanner

“Classical” lidars that scan obstacles in a plane only. These includes are available for these sensors:

Generic 2D LIDAR

RPLidar A2

Just like the generic Lidar above, but with a custom visualization for this particular commercial model.

Depth (RGBD) camera

An RGB+D (color plus depth) camera sensor, similar to an Intel RealSense or ASUS Xtion / Astra. It simulates both the RGB and depth channels independently (each with its own intrinsics and clip distances) and can optionally publish to ROS the following topics:

ROS topics published by the RGBD sensor
Topic	Type	Notes
`<label>_image`	`sensor_msgs/Image`	RGB image (always published when `sense_rgb=true`)
`<label>_points`	`sensor_msgs/PointCloud2`	XYZ pointcloud, or XYZRGB if `publish_ros_colored_pointcloud=true`
`<label>_depth/image_raw`	`sensor_msgs/Image`	16UC1 depth image (each pixel = depth in `rangeUnits`, default 1 mm; 0 = invalid). Published when `publish_ros_depth_image=true`
`<label>_depth/camera_info`	`sensor_msgs/CameraInfo`	Depth camera intrinsics. Published when `publish_ros_depth_image=true`

ROS publishing options

publish_ros_depth_image (default: true): When enabled, the sensor publishes the depth channel as a separate sensor_msgs/Image message encoded as 16UC1 on the topic <label>_depth/image_raw, together with a matching sensor_msgs/CameraInfo on <label>_depth/camera_info. This matches the topic layout of real RGBD cameras such as the ASUS Xtion / Astra (/depth/image_raw).
publish_ros_colored_pointcloud (default: false): When enabled and the sensor has sense_rgb=true, the pointcloud published on <label>_points will include per-point RGB color (XYZRGB fields) instead of plain XYZ.

GNSS sensor (“GPS”)

A “GPS sensor” can be attached to a robot with the code shown below. For it to work, the world XML needs to have a georeference tag.