Interacting with the Rover using Simulink

Simulink is a crucial software tool in the automotive realm, offering engineers a visual platform to model vehicle systems via block diagrams. Engineers leverage this versatile software to simulate and refine control algorithms for engines, transmissions, and critical vehicle functions like suspension and braking. Its integration with Hardware-in-the-Loop (HIL) setups allows real hardware testing alongside simulated components, aiding in the validation of electronic control units (ECUs). In the context of electric vehicles and autonomy, Simulink proves particularly useful in modeling battery systems, motor controls, and self-driving algorithms.

This post delves into a practical example of using Simulink to communicate with the Rover via the Vehicle Network Toolbox. We’ll focus on sending and receiving CAN messages and implementing a control system for a steering servo within the Rover, which we can simulate in real-time. It’s assumed the reader has a basic understanding of Simulink, control theory, and CAN.

An important point to note is that the servo we’re using already incorporates a controller within its internal circuitry. In practice, we’re not directly manipulating the servo motor itself; instead, we’re controlling its internal controller. Therefore, for the sake of this example, we’ll consider the servo as a plant with an unknown transfer function.

Most digital servos feature three pins for Pulse Width Modulation (PWM) control. Here, we’ll use a specialized servo that provides position feedback on a fourth pin, connecting it to a servo board found in the Demo Rover. Our objective is to design a closed-loop control system where the input is a steering angle and the output is a pulse width to control the servo. The position feedback helps measure and compensate for errors. Here’s a simplified version of the control system:

And here’s the final diagram in Simulink:

The final Simulink diagram showcases three main steps from left to right:

CAN message reception and decoding.
Control algorithm with signal conversion.
CAN message encoding and transmission.

The CAN blocks in steps 1 and 2 are provided by the Vehicle Network Toolbox, requiring a CAN interface to communicate with the Rover’s CAN bus. We employ a Kvaser USBcan 2, although any device compatible with Simulink should suffice. This interface, along with the toolbox, enables sending, receiving, encoding, and decoding CAN messages within Simulink. Consequently, we can extract values from a CAN message and utilize them as input in our Simulink model, then use the model’s output to transmit a CAN message to the servo board.

In this example, we use two messages:

ID 0x30D, containing the actual servo position in degrees.
ID 0x100, where we send the output pulse width to the servo board.

The Vehicle Network Toolbox provides Simulink blocks facilitating the filtering of these messages and their decoding/encoding. The CAN configuration block configures the Kvaser CAN interface with the correct bitrate of 125 kbit/s. For message reception, the CAN Receive block connects to a CAN Unpack block to decode signals for Simulink use. For transmission, the CAN Pack block encodes signals in a CAN message, and the CAN Transmit block sends the message on the bus. These blocks are configurable with CAN Database (DBC) files, allowing message selection from a drop-down list, where we utilize the Rover’s DBC file.

The servo control logic sits between the CAN reception and transmission logic. We generate a reference signal for controlling the servo via a sine wave generator, moving the servo from left to right by 45 degrees in each direction with a frequency of 1.5 rad/s. To visualize the sine wave, we send it to a scope block named “Signal viewer” along with the position feedback obtained from the CAN bus. This way we can gauge the control system’s response. We calculate the error in degrees by subtracting the position signal from the reference signal, converting it to a pulse width in microseconds before inputting it to the PID controller.

The PID controller’s output signal is limited to a pulse width between -1000 and 1000 microseconds. Since digital servos operate within a pulse width range of 1000 to 2000, with 1500 representing a neutral position, we add an offset of 1500 microseconds to the PID controller’s output before sending the signal to the CAN message encoder. The PID controller is configured in discrete-time mode, and we obtain its parameters by manual tuning: P=0.1, I=3.9, and D=0.005.

To run the simulation on real hardware, initial setup of simulation pacing parameters is crucial. Refer to the below images for these settings.

Upon connecting the servo board to the servo and the CAN interface to the servo board, the simulation can be executed. Here are the results:

As we can see, the actual position of the servo nicely follows the sine wave with a constant phase difference due to the simulation speed.

In summary, utilizing Simulink in conjunction with the Vehicle Network Toolbox allows for a hands-on exploration of Rover communication, focusing on CAN message handling and the implementation of a steering servo control system. This example illustrates the intricate steps, from decoding and encoding messages to interfacing with real hardware. The simulation effectively demonstrates the servo’s response to a sine wave input, showcasing its tracking capability. Overall, this practical demonstration underscores the Rover’s versatility and its utility for simulating and verifying models in a real-world context.

our other blogs

CanEduDev formally partners with Kvaser

Unlocking the Future with CanEduDev Rover and ROS2 Integration

CanEduDev Partners with KTH and Telenor on Advanced Autonomous Driving Project

CanEduDev Rover: Progress Report on System Integration and Architecture