Main Content

Simulating Mobile Robot with System Composer Workflow

Overview

Along with other tools, System Composer™ can help you organize and link requirements, design and allocate architecture models, analyze the system, and implement the design in Simulink®. This example demonstrates the workflow for designing a system architecture using System Composer. This example follows the early phase development for a mobile robot:

  • Setting up the requirements based on market research.

  • Creating architecture models to help organize algorithms and hardware.

  • Creating a Simulink model to simulate realistic behavior of the mobile robot.

This example describes a typical workflow for developing an autonomous mobile robot and conducting system analysis to ensure that the life expectancy of the durable components in the robot meets the customer-specified mean time before repair.

This example follows early workflow steps from Model-Based Design with Simulink.

Organize and Link Requirements

The first step in model-based design is to set up requirements. In this example, there are three sets of requirements.

  1. Stakeholder needs - a set of end-user needs.

  2. System requirements - an organized set of requirements that are linked closely with the system-level design.

  3. Implementation requirements - a detailed set of requirements that specify the model's subsystems.

By linking one requirement set to another, each high-level requirement can be traced all the way to implementation. For more information on requirement links, see Requirement Links (Simulink Requirements).

Link Stakeholder Requirements to Technical Requirements

Navigate to the example folder. To open scMobileRobotStakeholderNeeds.slreqx, scMobileRobotRequirements.slreqx, and scMobileRobotSubsystemRequirements.slreqx, double-click each file or run this code in the MATLAB® Command Window:

load_system('scMobileRobotHardwareArchitecture.slx') % Load systems in memory to view requirement links.
load_system('scMobileRobotFunctionalArchitecture.slx')
open('scMobileRobotStakeholderNeeds.slreqx')
open('scMobileRobotRequirements.slreqx')
open('scMobileRobotSubsystemRequirements.slreqx')

Link stakeholder needs to derived requirements to keep track of high-level goals. Some links are already defined in this example, like the implementation link from STAKEHOLDER-07 to SYSTEM-REQ-09. This information is saved in the file scMobileRobotStakeholderNeeds.slmx.

You can create another link for the Autonomy requirement. The stakeholder's need to relocate an object with a specified tolerance STAKEHOLDER-04 will be implemented by the system requirement SYSTEM-REQ-05. The robot must be able to determine its current position with a specified tolerance. Right-click SYSTEM-REQ-05 and select 'Select for Linking with Requirement'. Then, right-click on STAKEHOLDER-04 and select Create a link from SYSTEM-REQ-05 to STAKEHOLDER-04.

More details on the links can be found under View > Links. Change the type of link to Implements since STAKEHOLDER-04 is implemented by SYSTEM-REQ-05. For more information about link types, refer to Define Custom Requirement and Link Types (Simulink Requirements).

Design Architectural Models

Architecture models describe a system at different levels of abstraction. This example presents three architectures:

  1. Functional architecture describes high-level functions.

  2. Hardware architecture describes the physical hardware or platform needed for the robot.

  3. Logical architecture describes data exchange.

To open the functional architecture, double-click the file or enter the model name into the MATLAB Command Window.

scMobileRobotFunctionalArchitecture

The functional architecture describes functional dependencies: controlling a mobile robot autonomously, localization, path planning, and path following.

Link Requirements to Architecture Models

Requirement traceability involves linking technical requirements to architecture models, thereby allowing the connection between an early requirements phase and system-level design. You can more easily track whether a requirement is met by connecting components back to stakeholder needs. To view requirements, open the Requirements Manager by accessing Apps > Requirements Manager.

The 'Self Localization Sensor Fusion' component in functional architecture implements the 'Localization' requirement SYSTEM-REQ-05. To show or hide linked requirements, click the linked icon on the top-right corner of a component.

You can add links by dragging requirements to a component.

Open the hardware architecture model. To open the model, double-click the file or enter the model name in the MATLAB Command Window.

scMobileRobotHardwareArchitecture

The hardware architecture model describes the hardware components — the sensor, actuators, and embedded processor — and their connections. The colors and icons indicate the stereotypes used for each element.

You can view the requirements linked to the hardware architecture model in the Requirement Manager.

Only requirements related to 'Life Expectancy' are shown. Link other requirements by dragging and dropping from the Requirements Editor. For more information about requirements, see Link and Trace Requirements.

Link Functional to Hardware Architecture Using Allocations

You can allocate functional architecture to hardware architecture using the Allocation Editor.

To open the Allocation Editor, click Modeling > Allocation Editor, or enter the following into the Command Window.

systemcomposer.allocation.editor

Load the allocation set: scAllocationFunctionalHardware.mldatx in the editor. Click on 'Scenario 1'. Click 'Component' in the Row Filter and Column Filter sections to filter rows and columns by components. The Allocation Editor allows you to link different architecture models to establish traceability for your project. Components of the functional architecture are allocated to components of the hardware architecture.

Click 'Processor' on the Column Filter to filter the allocations further. Since stereotypes are applied only to the hardware architecture in this example, the stereotype filter displays in the Column Filter.

The autonomy of a vehicle is mostly handled by a target machine, which is an embedded computer responsible for processing sensor readings to calculate control inputs. Therefore, many functional components like 'Path Follower', 'Wheel Kinematics', and 'Scan Matching Algorithms' are allocated to the 'Target Machine'.

You can add allocations for ports and connectors as well. Double-click the intersections of the table to allocate or deallocate two elements.For more information on allocation, see Allocate Architectures in a Tire Pressure Monitoring System.

Stereotypes and Analysis

Stereotypes add an additional layer of metadata to components, ports, and connectors. The hardware architecture provides a basis to understand the applied stereotypes. To create a profile, see Define Profiles and Stereotypes.

In this example, the HardwareBaseStereotype is defined as 'Abstract Stereotype' and is extended to connector and component stereotypes. For example, a DataConnector stereotype is a connector stereotype that inherits the HardwareBaseStereotype. Other than properties like name and mass, the DataConnector stereotype has an additional property, TypeOfConnection, that describes which of the three connection types — RS232, Ethernet, or USB — it uses. For more information on setting up profiles, see Use Stereotypes and Profiles.

To focus on expected time before first maintenance, define properties such as 'UsagePerDay', 'UsagePerYear', and 'Life'. Setting these properties allows you to analyze each hardware component to make sure the mobile robot will last until first expected year of maintenance. To open the Profile Editor, go to Modeling > Profiles > Edit.

Once you define stereotypes in the Profile Editor, you can apply them to components and connectors. Apply stereotypes using the Property Inspector. To open the Property Inspector, go to Modeling > Design > Property Inspector.

To add stereotypes to elements, select the element in the diagram. In the Property Inspector, go to Main > Stereotype. Multiple stereotypes can be applied to the same element. Apply the MobileRobotProfile.Sensor stereotype to the Lidar Sensor component to add relevant properties.

Some components are in use for longer periods of time than others. The Lidar Sensor component is used for obstacle avoidance in this scenario so it is always in use except when it is charging. The RGB Camera only aligns the robot to the charging station, so it is in use for a shorter period per day. You can change values for the 'UsagePerDay', 'UsagePerYear', and 'Life' properties to determine the expected maintenance time for components that are each used with different frequency.

The property 'ExceedExpectedMaintenance' is set to 'False' by default. This property will update when you run your analysis.

Architecture Views Gallery

Use the Architecture Views Gallery to review changes you make in the architecture model. Architecture views allow you to create filtered views and thereby focus on few elements of the model, which enables you to navigate a complex model more easily. For example, an electrical engineer might be interested only in the electrical components of the hardware architecture. The engineer could apply a filter to show only components with electrical stereotypes.

In this example, you would apply the filter to view components with regard to the 'Life Expectancy' requirement.

To open the Architecture Views Gallery, go to Views > Architecture Views.

Click New View, then click Select All to select all components for view. Click Apply Query. Select the Hierarchy Diagram view. The hierarchy of the components is flattened to show all subcomponents in one view.

You can add filter logic to view relevant components for the 'Life Expectancy' requirement. Click New View, then click Add Clause.

Note that the default value for the MobileRobotProfile.HardwareBaseStereotype.Life stereotype is 999999. Set the filter to show components with MobileRobotProfile.HardwareBaseStereotype.Life not equal to 999999, which will indicate whether or not the stereotype was set.

Click Apply Query. Go to Hierarchy Diagram to view the components of interest.

For more information about architecture vews, see Create Architecture Views Interactively.

Model Analysis

Analyze the system to check if the components and connectors will last longer than the expected time before first maintenance. This value is set to 2 years in the analysis function. Open the Analysis Viewer under Modeling > Views > Analysis Model.

Select all stereotypes to make them available on the instance model. Choose scMobileRobotAnalysis.m as the analysis function. The iteration order determines in what order the component hierarchy is analyzed. However, since each component is analyzed separately, the order does not matter. Select the default 'Pre-order'.

Click Instantiate to instantiate the model.

Relevant components and connectors with stereotypes are shown. Since all stereotypes are selected, all elements with stereotypes are shown in the instance model. Model analysis will calculate which components and connectors will last longer than the expected 2 years. Click Analyze to perform the calculation.

The analysis function scMobileRobotAnalysis calculates if UsagePerDay*UsagePerYear*ExpectedYearsBeforeFirstMaintenance will exceed Life, which is set to 2 years, for each component and connector. The unchecked boxes indicate that components and connectors will need maintenance within 2 years with the given specification.

To refresh the instance model in the Analysis Viewer, select Overwrite, then click Refresh. This action will retrieve the values back from the source model, in this case, the hardware architecture model. Since ExceedExpectedMaintenance was the only property changed, it will be changed to its default value. Conversely, clicking Update will change the property values in the hardware architecture source according to the instance model. For more on analysis, see Analyze Architecture.

Simulate Architecture Behavior

You can inspect the logical architecture and link to Simulink behavior models to run the simulation.

To open the logical architecture, double-click the file, or enter the file name in the MATLAB Command Window.

scMobileRobotLogicalArchitectureInitial

The structure of the logical architecture is similar to that of a Simulink model because simulation models are designed based on the flow of information. The components of the logical architecture model are linked to behavior models so that the architecture model can be simulated as well. Each component is responsible for one or more functions defined in the functional architecture model. 'Trajectory Follower' is responsible for calculating the wheel speed of the robot based on the path the generator created. The lower level 'Motor Controller' controls the speed of each actuator motor according to the output from the 'Trajectory Follower'.

Note that many components are omitted from this example model. For example, sensor models like Lidar Sensor and RGB Camera are not required in this model because the true value from simulation gets the x-y position and orientation of the robot. For more complex simulations, sensor models like RGB Camera might be added to test different algorithms, such as object recognition. If such a sensor model was added, for example, Lidar Sensor, another behavior component would be required to decipher the sensor data, for example, Scan Matching Algorithm.

Add Simulink Behavior to Architecture Models with Bus Ports

Simulate an architecture model by adding Simulink behavior to a component.

Add a new component that would act as a sensor algorithm. Add two input ports and two output ports.

To create a new Simulink behavior, right-click Create Simulink Behavior.

Click OK. The new Simulink model is saved under the current folder. The component Component is converted to a reference component called Reference Component.

To edit the behavioral model, double-click 'Sensor Algorithm'. Observe that bus element ports are created during the conversion process. For more information on setting bus ports, see Explore Simulink Bus Capabilities.

Any port blocks can be used to connect different components, for example, Inport and Outport. Delete 'Sensor Reading 2' and 'q'. Create a new Inport and Outport.

Connect the inports to the outports.

Note that in al scenario where sensor models such as RGB Camera and Lidar Sensor are added, the algorithm model will include tools like a neural network or scan matching method.

Click the pencil button to open Block Parameters. Set 'Sensor Reading 1' Dimensions to 2.

Set 'Sensor Reading 2' Port dimensions to 4. Each port corresponds to an x-y position and quaternion, respectively.

Return to the logical architecture and connect the components.

The process outlined above is already done in scMobileRobotLogicalArchitecture. Double-click the file to open the model, or enter the name in the MATLAB Command Window.

scMobileRobotLogicalArchitecture

A behavior algorithm is created based on port information only. When designing a logical architecture, you can set the interface of the port in more detail. For example, if you know that a 800 x 600 RGB image with 24 frames per second will be transferred from the camera sensor, you can set the corresponding port interface accordingly to ensure efficient data transfer. For more information about setting interfaces, see Define Interfaces.

Running Simulation from Logical Architecture

Once behavior models are linked, the architecture model can be simulated just like any other Simulink models by clicking Run.

The scope from 'MotorController' shows how well a simple P-gain controller is performing to follow the reference velocity for one of the wheels on the robot.

Run the following script to observe you well the robot follows the waypoints.

out = sim('scMobileRobotLogicalArchitecture.slx');
% waypoints are manually defined in Constant block
waypoints = eval(get_param('TrajectoryGenerator/Manual Waypoints','Value'));

figure
hold on
plot(out.pose.Data(:,1),out.pose.Data(:,2))
plot(waypoints(:,1),waypoints(:,2))
hold off
xlabel('X Position (m)')
ylabel('Y Position (m)')
legend('Actual Trajectory','Commanded Trajectory')

Figure contains an axes. The axes contains 2 objects of type line. These objects represent Actual Trajectory, Commanded Trajectory.

Related Topics