Ranging Sensor Simulation

Simulates a ranging sensor such as a time-of-flight sensor or LIDAR.

Library

Description

The Ranging Sensor Simulation block simulates a ranging sensor such as the RPLIDAR. It sets up a server on the given URI that responds to signals just like the actual sensor. It is intended to be indistinguishable from the actual ranging sensor so that it can be used transparently in place of real hardware.

The Ranging Sensor Simulation block inputs the measured distance(s), the standard-deviation of the distance measurement(s), the heading(s), and an indication of the quality of the measurement(s). For fixed-size inputs, it also takes an input indicating how many of the simulated measurements are valid. The block also supports variable-size inputs, in which case that extra input is not present.

For LIDAR, the dist, sigma, head and quality inputs are typically vectors. In this case, each element represents one measurement within a scan of the environment. LIDAR typically perform a 360 degree scan of the environment, so the headings will contain angles from 0 to 360 degrees (in radians). The distance input at the corresponding element represents the distance to an object detected at that heading. The distance and heading are typically plotted on a polar plot, using the Polar Figure block.

If a measurement cannot be taken because an object is too far away, for instance, then the distance measurement and corresponding quality will be zero.

When the Variable-size inputs parameter is checked then the inputs become variable-size signals whose length reflects the number of simulated samples in one complete scan of the environment. The input will be the same as the fixed-size input case except that all input elements are assumed to be valid because the inputs are variable-size.

The Ranging Sensor Simulation block listens on the URI specified in the dialog parameters. Any clients which connect to that URI will be able to use the simulated device.

To use the simulated ranging sensor from the Ranging Sensor block, simply set the URI to connect as a client to the Ranging Sensor Simulation block, which acts as the server. For example, if the Ranging Sensor Simulation block is listening on URI tcpip://localhost:18001 on a host machine with IP address 192.168.1.5, then a Ranging Sensor block running on another machine could access it using the URI: tcpip://192.168.1.5:18001.

The URI may be specified in the dialog parameters or via an input port. Which option is used is determined by the Source of URI parameter. When the URI is specified via an input, the input is typically driven by a Model Argument block, which allows a model argument to be used to assign the URI at runtime.

Helpful Hints

LIDAR Specifications

Do not confuse the samples per second specification of a LIDAR with the number of samples per revolution. For example, the RPLIDAR A2 LIDAR collects 8000 measurements per second. However, it spins at about 16 revolutions per second. Hence, the number of samples per revolution is about 8000 [samples/second] / 16 [revolutions/second] = 500 samples per revolution. Hence, the input of the Ranging Sensor Simulation block should be about 500 samples because the block inputs should represent one complete 360 degree scan of the environment i.e., the samples from one revolution. Hence, a new scan should be provided to the block about 16 times per second.

Firewall

If remote clients will be communicating with the Ranging Sensor Simulation then be sure to configure the server machine's firewall to allow incoming access on the port being used.

Input Ports

dist

The simulated distance(s) in metres.

sigma

The estimated standard deviation of the simulated distance(s). This input may not be supported by all sensors. In that case, zeros may be provided.

head

The heading(s) in radians. Not all sensors support a heading measurement. In that case, this input may be zero. Heading angles inrease in the positive direction. If 0 is north, then π/2 is east, π is south and 3π/2 is west.

quality

An indication of the quality of the measurement(s). This input should vary between zero and one, with one being the highest quality measurement. For sensors which do not provide quality information, this input should be a binary output - either zero or one, depending on whether the simulated measurement was taken successfully.

#

Indicates the number of elements in the other inputs that are actually valid. This input is only present when the Variable-size inputs option is not checked.

uri

A string specifying the URI upon which to listen and service client connections. The string must be a null-terminated vector of characters represented as a vector of uint8 quantities. It may be variable-sized. This string is typically provided either directly or indirectly by a Model Argument block or String Constant block.

This input is only available if the Source of URI parameter is set to External input port. Refer to the documentation below on the Source of URI parameter for details.

Output Ports

used

An optional boolean output indicating whether the sensor is currently in use by a client application.

err

An int32 value indicating whether an error occurred. On success, it will be zero. If an error occurs then this value is a negative error code. See Error Codes for the different error codes and their values. Use the Compare to Error block rather than the error code itself to check for specific error codes. To check for errors in general use the Compare to Zero block to check whether err output is less than zero.

Data Type Support

This block supports fixed or variable-sized inputs of any of the standard numeric data types. Fixed-point signals are not supported.

Parameters and Dialog Box

Sensor type

Indicates the type of ranging sensor to simulate. Only the sensors in the list are supported. The URI parameter determines how the block communicates with clients using the simulated sensor.

Source of URI

Indicates whether the URI should be determined from the dialog parameters or an input port. If this field is set to Specify via dialog (do not evaluate) then the URI is specified via the URI upon which to listen parameter. In this case, the URI is not evaluated as a MATLAB expression but is interpreted as a literal string. However, format specifiers are recognized. Refer to qc_perform_substitutions for a list of the format specifiers available.

If format specifiers which change frequently, such as '%{time}' or '%{instance}', are used in the URI then the Ranging Sensor Simulation block cannot be placed in a referenced model, because the URI will change from the time the code is built to when the code is run. As a result, Simulink will insist that the code be rebuilt because block parameters in referenced models are inlined. Instead, specify the source of the URI as External input port and pass the URI from the top-level model. Use a String Constant block in the top-level model to generate the URI.

If this field is set to Specify via dialog (evaluate) then the URI is also specified via the URI upon which to listen parameter. However, in this case, the URI is evaluated as a MATLAB expression. This option is convenient for using a variable in the MATLAB workspace for the URI.

If this field is set to External input port then the URI upon which to listen parameter is ignored and an extra input port is provided which determines the URI.

URI on which to listen

The URI identifying the communication protocol and associated parameters to use to listen for clients employing the simulated sensor. For example, tcpip://localhost:18000 listens for client TCP/IP connections on port 18000. Refer to Universal Resource Identifiers for more information about URIs and the communications protocols supported by QUARC.

Sample time (second)

The sampling period (in seconds) at which the sensor data are input to the Ranging Sensor Simulation block. A sample time of 0 indicates that the block will be treated as a continuous time block. A positive sample time indicates that the block is a discrete time block with the given sample time.

A sample time of -1 indicates that the block inherits its sample time.

The default sample time is set to qc_get_step_size * ceil(0.1 / qc_get_step_size), which is a QUARC function that returns the closest multiple of the fundamental sampling time of the model to 0.1 seconds.

Show sensor in use

If this option is checked then the block will have an extra output: used, which will indicate whether the simulated sensor is currently being used by a client.

Variable-size inputs

If this option is checked then the block will accept variable-size signals at its inputs and the # input will not be provided. If it is not checked, then only fixed-size inputs will be provided, but a # input will be available to specify how many elements of those inputs are valid simulated measurements.

Active during normal simulation

If this option is checked then the block will simulate the sensor in normal simulation.

Targets

Copyright ©2024 Quanser Inc. This page was generated 2024-10-17. Submit feedback to Quanser about this page.

Link to this page.