Main Content

ROS Simulink Interaction

When using Simulink® to communicate with a ROS network or work with ROS functionality, there are several points to note regarding its interaction with MATLAB® and the ROS network.

MATLAB ROS Information

Simulink uses the functionality built into MATLAB to communicate with the ROS network during simulation. When trying to debug issues in Simulink, you can use MATLAB to view topics or messages available on the ROS master. For more information on ROS topics and messages, see rosnode, rostopic, or rosmsg.

By default, Simulink uses MATLAB ROS capabilities to resolve network information such as the address of the ROS master. This network information can also be specified in Simulink using the Configure ROS Network Addresses dialog.

Simulink ROS Node

Each model is associated with a unique ROS node. At the start of each simulation, Simulink creates the node and deletes it when the simulation is terminated. If multiple models are open and being simulated, each model will get its own dedicated node, but all the nodes will connect to the same ROS master. This is because all the models use the same ROS network address settings.

In simulation, the Simulink ROS node name is <modelName>_<random#>. This takes the model name and adds a random number to the end to avoid node name conflicts.

In generated code, the node name is <modelName> (casing preserved). The model name is also used in the archive used for generated code. Do not rename the tgz file from code generation (e.g. ModelName.tgz). The file name is used to get the ROS package name and initiate the build.

Differences Between Simulation and Generated Code

In simulation, the model execution does not match real elapsed time. The blocks in the model are evaluated in a loop that only simulates the progression of time, and whose speed depends on complexity of the model and computer speed. It is not intended to track actual clock time.

In generated code, the model execution attempts to match actual elapsed time (the Fixed-step size defines the actual time step, in seconds, that is used for the model update loop). However, this does not guarantee real-time performance, as it is dependent on other processes running on the Linux® system and the complexity of the model. If the deployed model is too slow to meet the execution frequency, tasks are dropped. This drop is called an "overrun" and the model waits for the next scheduled task. For more information, see the Tasking Mode section in the Generate a Standalone ROS Node from Simulink example.

You can also modify how your generated code runs for a deployed ROS node using rosdevice. The rosdevice object allows you to connect to a ROS device, run nodes that are deployed, and modify files on the device.

Publishers and Subscribers in Simulink

All publishers and subscribers created using Publish and Subscribe blocks will connect with the ROS node for that model. They are created during the model initialization and topic names are resolved at the same time. The publishers and subscribers are deleted when the simulation is terminated.

NOTE: If a custom topic name is specified for a Subscribe block, the topic is not required to exist when the model is initialized. The Subscribe block will output blank messages until it receives a message on the topic name you specify. This allows you to setup and test models before the rest of the network has been setup.

ROS Model Reference

Simulink supports model reference when using ROS blocks with one limitation. Multiple references to the same model results in an error due to duplicate buses with the same name being created for ROS messages used by the ROS blocks. You can only reference a model once in a parent model.