NXP Model-Based Design Tools Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Model-Based Design Tools Knowledge Base

Discussions

Sort by:
General Installer and Setup  External mode External mode example wouldn't compile after update  Others MPC57xx MBD Toolbox not appears in Simulink Library Browser  Peripherals Apps Motor Control BMS Request for HSD/LSD/MSDI Communication Examples for MPC5775B BMS and VCU Reference Design 
View full article
This page summarizes all Model-Based Design Toolbox videos related to BMS. Speed-Up BMS Application Development with NXP's High-Voltage Battery Management System Reference Design and Model-Based Design Toolbox (MBDT) Link to the recording here  This webinar shows how to design and develop Battery Management Systems, with NXP's High-Voltage BMS Reference Design and Model-Based Design Toolbox for S32K3xx, with Simulink® and Embedded Coder. During this webinar, we will introduce the ASIL D High Voltage Battery Management System Reference Resign that comprises a Battery Management Unit (BMU), Cell Monitoring Units (CMU), and a Battery Junction Box (BJB). NXP's HV-BMS Reference Design is a robust and scalable solution including hardware designs, production-ready software drivers, and safety libraries, as well as extensive ISO 26262 Functional Safety documentation. The design significantly reduces the development effort and enables an improved time to market with the latest chipset innovations. Speed Up Electrification Solutions Using NXP Tools Link to the recording here  This video provides an overview of the NXP Software and Tools solutions, designed to help customers to speed up application development with design, simulation, implementation, deployment, testing, and validation. During this session, you will learn about all the steps required to build complete solutions like battery management systems with NXP in-house solutions and NXP Model-Based Design Toolbox with simulation and code generation.
View full article
1.  Introduction The NXP i.MX RT1xxx Toolbox enables automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s i.MX RT 117x, 106x & 101x Series of crossover MCUs. The toolbox can be installed from Matlab add-ons page:   The novelty of this NXP toolbox is the integration with MCUX Configuration Tool for platform initialization. This configuration tool is being leveraged for pins settings, clock configuration and peripheral initialization. The toolbox is also integrated with the MCU SDK and will use the SDK API for code generation. This article details the steps to start building new models and deploy them on the i.MX RT106x, i.MX RT1010 & i.MX RT 117x MCU, showcasing also the integration with the MCUX Configuration Tool. 2.  Start creating your model Below are the steps to start creating a Simulink model that will be deployed on the i.MX RT1xxx boards. Step 1: Better to start on clean so first lets create folder to be used as workspace and switch MATLAB current folder to point to this workspace location:   Step 2: Create a Simulink Blank Model.   Step 3: Save and name your new model (E.g. mytest.slx). Step 4 : Choose the NXP IMXRT hardware board from the Model Settings in the MODELING tab.         Step 4.1: Open  Model Settings -> Hardware Implementation menu         Step 4.2: Select the NXP target from Hardware Board. This selection should match the             evaluation kit you plan to test the code for. After the selection is made, press the Apply button. After the target is set, the workspace will be populated with new files and folders: A file with extension <model_name>Config.mex – this is the file created with MCUX Configuration Tool that is used for pins, clock, and peripherals initialization. This configuration file will have enabled the peripherals that are supported by the toolbox. Starting from this, the user can change the default configuration for any of the peripheral instances (add new instances, disable instances, etc.) and also any of the configured pins.   A folder with naming pattern <model_name>Config -  this folder will have a structure that is similar to the MCUXpresso IDE projects, and will contain the SDK files that are needed to build the model and generate a binary application that will run on the board. The user can now add Simulink blocks in the model from the NXP i.MXRT1xxx Simulink library from Simulink Library Browser:   Choose the desired block to add to the model:   Alternatively, if the user will add in his/her model a peripheral block without configuring the target, a default one will be set that the user can change it afterwards.  3.  Modify default platform initializations and settings values As mentioned at the beginning of this article, the platform initialization, including pins, clock and peripherals settings is done using the MCUX Configuration Tool. As seen in the previous chapter, when a Simulink model is being created with one of the NXP IMXRT targets, the workspace will be populated with a file having the extension .mex – this is the configuration file that will be used in the initialization code of the platform. The user has the option to modify the default selections found in the .mex file. For this, open any peripheral block within the model and press the Configure button. This action will open the MCUX Configuration Tool.   From MCUX Configuration Tool, the user can change default settings of the peripherals – enable or disable instances, from Pins view, it can configure/update pins settings of the platform. After the user is done with configuration in MCUX Configuration Tool, he/she must go back in Simulink and press the Update button in the same block, for the changes to be visible in Simulink also. The new initialization settings, will be included in the Build Model step. The Toolbox will trigger a code generation starting from the .mex file. The generated files will be saved in the <model_name>Config folder, in board folder.   Note, that is not a prerequisite for the user to have MCUX Configuration Tool installed, the toolbox incorporates all the tools that are need for the user to create, configure,  build and deploy the model.  The default MCUX Configuration Tool used can be changed from Model Settings/Hardware Parameters / Tools Path, and the user can provide his/her own installation of the tool. Same approach is used with the SDK platform. The toolbox incorporates the release version of the SDK for the IMXRT1xxx targets. Also this path can be changed by the user, but it must consider possible integration issues of the toolbox with the user specified SDK.     4.  Deploy on NXP Hardware After the Simulink model is completed, follows the build and deployment of the model on the target board. Before Build and Deploy, the user must set the download method of the application. Step 1: Select the Download method from Hardware Implementation in Model Settings.   The default Download method (without the need for additional software and/or hardware probes) is OpenSDA. For this, the user must select the Drive on his/her machine where the OpenSDA firmware of the board is mapped after the NXP evaluation board is plugged in via USB. Step 2: Build & Deploy Model Step 3: After the code is generated and downloaded on the board a window will pop up and tell you to restart the evaluation board. Restart the board and then press OK. Congratulations! You have successfully created and deployed your Simulink model to the hardware.
View full article
          Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.1.0 RTM     Austin, Texas, USA December 20, 2021 The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.1.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K344 and S32K312 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A battery cell controller (& MC33664PHY). In this release, we have also added 2 new motor control applications (for both PMSM and BLDC), as well as updated FreeMASTER, AMMCLib, and GCC compiler to the latest versions. The product comes with over 100 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=12920897   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K344 S32K312   Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A battery cell controller & MC33664PHY The toolbox provides support for the MC33775A and MC33664. The MC33775A is a lithium-ion battery cell controller IC designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33664 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high speed isolated communication network. The ready-to-run example provided with the MBDT for S32K3 shows how to communicate between the S32K344 and the MC33775A via the MC33664 transceiver. The MCU configures the battery cell controller to perform Primary and Secondary chains conversion, reads the cell voltages conversion results from the MC33775A, and displays the values to the user over the FreeMaster.     Added new motor control examples The toolbox provides examples for both 3-shunt PMSM and BLDC motor control applications. Each of them has a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization.     Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.     Support for AUTOSAR blockset (SW-C deployment) Updated to the latest version of RTD (v1.0.0) and GCC(v10.2) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32Configuration Tool or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.26: All functions in the Automotive Math and Motor Control Functions Library v1.1.26 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2020a R2020b R2021a R2021b   S32Design Studio Integration We provide a simple mechanism to let users the opportunity to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.     Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 100 examples, including: Motor control applications (PMSM and BLDC) Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode   For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.1.0 is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.1.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt    
View full article
In this video we discuss about practical implementation of the motor phase commutation algorithm and how to validate and test such algorithm using different approaches in Model Based Design.    We discuss about: - How to build the commutation table starting from the hall sensor measurement experiment; - How to implement the Software Look Up Tables for rotating the motor in clockwise (CW) or counter clockwise (CCW) directions; - Simulink model that implement the commutation algorithm;   NOTE: Chinese viewers can watch the video on YOUKU using this link 注意:中国观众可以使用此链接观看YOUKU上的视频
View full article
Are you interested in such demo? You can see it live in June during Mathworks Expo in Munich, Germany on June 27th See how we built it here. If you want more details - leave a comment below
View full article
  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K1xx – version 4.3.0 Austin, Texas, USA - September 13, 2022   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K1xx version 4.3.0. This release supports automatic code generation for S32K1xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K1xx Automotive Microprocessors. This new release adds support for RDDRONE-772B  Battery Management Systems (support for MC3377xC), Code deployment directly from Simulink via JTAG/SWD (OpenSDA, PeMicro Probe, or SEGGER JLink), SIL/PIL support for the latest MATLAB versions, new community and customer requested features (Enhanced support for SBC, FCAN Blocks, UART Blocks, I2C Blocks) and many other various new functionalities to help customers with rapid prototyping with NXP S32K1xx microcontrollers.   FlexNet Location: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Activation link: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Technical Support: NXP Model-Based Design Toolbox for S32K1xx issues are tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation based on S32K SDK 4.0.0 RTM drivers from MATLAB® for NXP all S32K1xx derivatives: S32K142W MCU Packages with 48/64 LQFP (*updated) S32K144W MCU Packages with 48/64 LQFP (*updated) S32K116 MCU Packages with 32QFN and 48LQFP (*updated) S32K118 MCU Packages with 48/64 LQFP (*updated) S32K142 MCU Packages with 48/64/100LQFP (*updated) S32K144 MCU Packages with 48/64/100LQFP and 100BGA (*updated) S32K146 MCU Packages with 64/100/144LQFP and 100BGA (*updated) S32K148 MCU Packages with 144/176LQFP and 100BGA/QFP (*updated) Multiple options for packages and clock frequencies are available via Model-Based Design Toolbox S32K Simulink Main Configuration Block       Added Support for RDDRONE-BMS772         We added examples for the RDDRONE-BMS772. This is a standalone BMS reference design suitable for mobile robotics such as drones and rovers, supporting 3 to 6-cell batteries. MBDT examples cover applications like BMS, LCD, CAN and SBC.       Battery Management System (BMS) support for MC3377xC – examples, documentation and FreeMASTER UI are available Special Simulink Blocks have been added to simplify the way a user can initialize such a controller, read vital parameters (like cell voltage, stack voltage, temperature, current), and manage the whole system. The entire suite of blocks is easily integrated within the new Battery Management Toolbox from Mathworks, so users can leverage these algorithms on top of our blocks.       Enhanced FCAN Support We improved the FCAN communication support by addressing the following: FCAN communication is now fully functional when external SBC is configured (for both UJA113x and UJA1169) The user is able to retrieve the ‘Error Status’ of an ongoing transfer and abort it in case something is wrong. The ‘Receive’ and ‘Send’ blocks for FCAN now allow the user to specify when the initialization for the message buffers should be executed (during Model Initialization, at each execution of the block, or none). If the ‘NONE’ option is selected, a newly added block ‘FCAN_MBConfig’ can be used to configure the message buffer. The FCAN messages ID can also be provided via an input port for both ‘Send’ and ‘Receive’ operations.   Multiple S32K1xx peripheral support. The peripheral coverage for each of the S32K1xx derivatives is shown below:   S32K116 S32K118       S32K142   S32K144         S32K146 S32K148       Added support for JTAG deployment directly from Simulink We added support for deployment over JTAG directly from Simulink. In the main Config block, under Target Connection, the JTAG option must be selected. Following this action, the JTAG Interface selection becomes active. Here is the following selection: OpenSDA Embedded Debug – the EVB Embedded Debugger is used. USB Multilink PEmicro – an external PEmicro probe is used. SEGGER JLink – this action requires the external selection of the SEGGER JLink     Extended support for MATLAB versions We extended support for our toolbox to cover a wider range of MATLAB releases – starting from R2016a and going up to R2022a. This way we want to avoid locking out users that have constraints regarding MATLAB versions.   New community-requested features In our efforts to make  NXP’s Model-Based Design Toolbox for S32K1xx version 4.3.0 fit the needs of the users, we have added the following requested features/updates: Added OSIF Time Delay Block Added Code Size Report Added NONE option for the SPI SIN/SOUT pins Enabled support for more than one ADC Interleave Block Updated Profiler functionality Updated FCAN Blocks Updated I2C Blocks Updated LPUART Blocks Fixed Registers dropdowns not displaying options on some machines   100% S32K1xx supported peripheral coverage with examples. Approximately 300 examples are available as part of the toolbox that exercises all the functionalities supported.     For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K1xx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for S32K1xx Online Installer Guide Add-on allows users to install the NXP solution directly from the MathWorks website or directly from MATLAB IDE. The Support Package provides a step-by-step guide for installation and verification. NXP Model-Based Design Toolbox for S32K1xx version 4.3.0 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples:       Target Audience This release (4.3.0) is intended for technology demonstration, evaluation purposes, and prototyping for S32K116, S32K118, S32K142, S32K144, S32K146, S32K148, S32K142W, and S32K144W MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      
View full article
1. Introduction This article discusses various algorithms for controlling trajectory and speed for an autonomous vehicle.  The car is built with S32K144 and the NXP's Cup car chassis as explained in depth in this article: https://community.nxp.com/docs/DOC-341984. All software used for programming the car is done using MATLAB/Simulink toolbox called Model-Based Design Toolbox for S32K1xx - NXP Support Package S32K1xx - File Exchange - MATLAB Central. The goal of achieving imposed performances for this system is approached in a classical manner using a PID (Proportional Integral Derivative) controller and also by using modern control algorithms: LQG (Linear Quadratic Gaussian), LTR (Loop Transfer Recovery), H2 and H∞.   2. Vehicle Dynamics Model A logical way of creating a formal representation of the physical system is described in the following section. The significant contribution of such representation is outlined in the control algorithms design process. Validation of these algorithms in a simulation environment, where a mathematical model approximates the real system, is a procedure which is going to be undertaken to ensure rectitude and precision for the developed solutions. Simplifying assumptions must be made to create the context of ease in manipulating such a formal representation, considering the existing numerical algorithms. Therefore, the mathematical model will possesses a certain level of compromise between the simplicity of the representation and accuracy related to the real system. Before starting to model the car’s dynamics, a brief analysis of the system is introduced to offer a clear image on the process. The car can be controlled through three independent inputs, duty cycles which are given as inputs to the Simulink blocks: the duty cycle for the servomotor; the duty cycle for the 1st rear wheel and the duty cycle for the 2nd rear wheel. The output of the process is represented by the image camera sees in front of it, the array Y with the converted values of the analog signal transmitted by the sensor. Hence, a Multiple Input Single Output (MISO) process is modeled in the current section of the paper. The actuators are represented by the three motors, two to ensure traction of the car, and one servomotor responsible for the steering. The plant is represented by the actual vehicle, and the sensor is constituted by the camera which provides the image in front of the car. Thereby, Figure 2.1 illustrates the correspondence between the physical ensemble and the control theory components. Figure 2.1 Actuators, plant, sensor Before exposing the equations that describe the dynamics of the system, a representation of the forces that affect the vehicle is illustrated in Figure 2.2, where: XR and YR define the robot frame, δ represents the turning angle of the front wheels, F is the traction force generated by the two DC motors of the rear wheels, Ff denotes the friction force that the vehicle must overcome during its movement, L is the length of the car, measured from the center of the front wheels to the center of the rear wheels, Cx and Cy reactive forces depending on the movement velocity and ω the angular velocity. Figure 2.2 Forces acting on the vehicle Now, writing Newton’s law for the translation motion and considering the decomposition of the forces on the robot’s frame axis, the motion is described as well as longitudinal as latitudinal by: The traction and resistance forces can be expressed based on the two DC motors parameters: where: ui - voltage applied on the inner wheel motor, uo - voltage applied on the outer wheel motor (related to turning behavior), km - DC motor constant, rw - rear wheels diameter, R - winding resistance, Bv - resistance coefficient for the translation motion, μ - friction coefficient, M - mass of the vehicle, g - gravitational acceleration. When it comes to the rotational motion, the equation which describes the vehicle dynamics is given by: where: MFx - moment of Fx force, Md - moment caused by the difference of speeds on the two rear wheels which triggers the car to change its orientation, MFfx - moment of Ffx force, which opposes to the rotational movement, Cw - reaction dependent to the angular velocity and J - moment of inertia. Considering thus the previous formulas for the traction and friction force, the final equation of the rotational movement is: where all the variables have the same meanings as already specified and more than that, Bw represents the resistance coefficient for the rotational motion.  To express the position of the vehicle on the track, an approach based on angles is going to be used to provide a suitable functional description of the process. Therefore, θ represents the angle between the YR-axis of the robot and the XI-axis of an inertial frame, like in Figure 2.3 The θ angle provides information about the car’s position on the given track, and it represents the variable to be measured to ensure the desired behavior of the vehicle.  Figure 2.3 System output - θ angle Therefore, the differential equations that model the vehicle’s dynamics are written in the inertial coordinate system and obtained considering a Newtonian approach as in: The mathematical representation given by the previous differential equations is characterized by nonlinear dynamics. A linearization procedure is therefore implemented to obtain a state-space representation of the given model. For the particular model developed so far, considering the variables and their signification related to the vehicle’s dynamics, the state array is formed by: x' = [θ vx vy ω], while θ represents the output and u' = [δ ui uo] defines the control signals array. The differential equations of the vehicle dynamics are introduced in the Simulink environment for obtaining the linear system. Input and output ports are used for the controlled and measured variables, while a simple logic of mathematical operations blocks, integrator blocks, and signals connections are implemented. Before using the linmod Matlab function to obtain the linearized model, a static operating point must be chosen. When it comes to this, the following assumptions are made: the car travels a straight road, the front wheels are straight, no turning angle, the rear wheels have equal rotational speed and the car is perpendicular on the X-axis of the inertial system coordinate. All these specifications correspond to a duty cycle equal to 0.03, as mentioned previously. For the two rear wheels, a 10% speed is chosen. However, the transfer from the duty cycles transmitted to the motors and the inputs considered for the system in the current model should also be computed. For the two rear DC motors, the voltage applied is proportional to the duty cycle control signal. A 0% duty cycle (no rotational speed) is equal to a 0V power voltage. While the maximum voltage of the DC motors is 5V, and the maximum duty cycle is 100%, it is easy to determine the proportionality factor, which is equal to 5. When it comes to the conversion between the duty cycle of the servomotor and the turning angle of the front wheels, it must be taken into account that the maximum angle physically achievable for the front wheels is equal to 45 degrees. Therefore, the transfer can be modeled by: With all the transfers modeled and all the model's constants replaced with numerical values, a state-space representation is computed for the entire process and the system is described by the following minimal state-space representation: 3. Control Algorithms 3.1 Experimental PID Position Control The actual position of the car on the track is compared to a defined reference and it is desired to maintain the error between these variables as small as possible, with the purpose mentioned in the previous paragraph. The inputs on the rear motors are given by a constant duty cycle equal to 0.1, which represents 10% of the maximum speed that the car can reach. All these information are represented in a schematic manner in Figure 3.1.1 Figure 3.1.1 Position control loop 3.1.1 Position Computing and Reference Defining Relying on the array of intensities returned by the ADC, the following procedure was undertaken to gain knowledge about what the camera sees. The robot was firstly placed on one side of the track, and connected to the FreeMaster tool for real-time data collecting. The experiment was repeated for different positions of the vehicle, and the results are illustrated in the figures below:                              Figure 3.1.1.1 Exemplification of what camera sees for different positions of the car on the track Noticing how the image in front of the camera changes related to its position, it is desirable for the two dips on the graphics to be equally distant from the center of the array. A position finding algorithm is therefore implemented for searching the edges of the road. 3.1.2 Parameters Tunning Based on the error value, the steering input is computed. Bearing in mind the fact that the duty cycle for the servomotor should be in the range of 0.02 – 0.04, the control signal given to the actuator should be bounded for this particular input range. Thus, a scaling factor is introduced before the error is transmitted to the controller. Considering the error range, a convenient scaling factor is chosen. Irrespective of the correspondence of the errors to left or right halves of the road displacements, the magnitude of the signal should be processed by the controller in the same way. The symmetry has then to be dismissed because different values of the duty cycle should be computed to make the car turn left or right. Therefore, the PID controller can return a control signal which is maximum equal to 0.01, for an maximum error value, which then, based on the sign of the position index algorithm returned value, should be added to 0.03 (wheels not steered) for a movement to the left, or subtracted from 0.03 for a movement to the right. Following all the introduced information, the first step into the procedure of tuning the PID controller is to build a proportional controller. A maximum error value, divided by the scaling factor corresponds to a maximum 0.01 control signal. Moreover, knowing that for a proportional controller, which is discrete considering its use directly on the real process: the proportional parameter of the PID controller is computed from the previous formula. The result of the designed controlled system is now illustrated in Figure 3.1.2.1, extracted from the FreeMaster debug tool in real time, while the car completes multiple laps on the given track.The output of the system is illustrated on the Y-axis, the reference is marked with a black line, and the time scale is represented on the X-axis, in seconds. The dips on the graphical representation of the system’s output correspond to the curvatures of the road, where a significant error triggers the wheels steering to keep the car on the track. The wavy portion is the system’s output on the wavy piece of the road, and the almost straight area is the output provided when the car is on the straight piece of the track. It is noticeable that on the straight part of the track, the reference is not completely followed. Also, on a long straight road, only the proportional component is not able to ensure a steady state error equal to zero.                                          Figure 3.1.2.1 System reference and output with P controller Figure 3.1.2.2 Track components: straight, curve, wavy Rising even more the KR factor value does not solve this problem, because the risk of the system’s instability appears in this scenario. Thus, the integrative component should be used, and now the controller is a PI, with the following control law: The Ti value is chosen experimentally, and satisfying results are illustrated in the following figure:                                 Figure 3.1.2.3 System reference and output with PI controller A derivative component is not necessarily required, considering the form of the track (without sudden changes of direction). Inside the PID block which implements the controller in the Simulink environment, besides the parameters choice and also the upper and lower saturation limits of the control signal, the clamping anti-windup method is also used for preventing the controller output from saturating. The sampling time is left to be inherited, this option allowing the Matlab environment to choose the right sampling period considered regarding the timing in the given Simulink model. 3.2 Experimental PID Speed Control The center of the track is now followed, and the behavior of the vehicle is as desired. On longer tracks, the vehicle movement seems like a crawl, and the particularities of the system allow the control of three different inputs. A speed control algorithm is thus implemented to ensure a reduced time in completing a lap. Like any other car, the robot should be able to adapt its speed depending on the track to be traversed. Acceleration and deceleration features should be implemented into the current application to emulate the behavior of a real-life vehicle. Also depending on the road’s particularities, curvatures, distances, a speed limit should be left to be user’s choice. Intuitively, from a driver perspective, the speed should be reduced at the beginning of the curve and then gradually increased on the second part of the curve, as the car leaves it and heads to a straight piece of the road. Taking into consideration this real life behavior, the graphic evolution of the output of the system controlled with the PID position controller seems to illustrate this exact idea. It is noticeable that inside a curve, the error slowly increases as the car approaches the center of the turn, and then decreases while the exit becomes close. A proportional control signal to the speed of the two wheels can be thus computed to take care of this operating mode.The error signal is consequently fed to a P controller which amplifies it considering, for the beginning, that the maximum speed allowed is equal to 0.15 (15%). Therefore, the control loop is completed, as illustrated in the figure below: Figure 3.2.1 Position and speed control loop Assuming that the imposed speed limit is provided by a duty cycle equal to 0.15, as specified in the previous paragraph, and also that, during a turn, it must be reduced to 0.1, the KR factor of the two controllers, one for each rear wheel is given by: The KR general formula can be modified under the desired speed range (how fast should the car go and how fast should it take turns). The control signal given to the rear motors, uk = KRϵk is subtracted from the imposed speed limit to achieve the desired behavior on the curvatures of the road. The car travels the track faster now, but increasing the speed, even more, causes a side-slip of the vehicle during turns. This shortcoming could be improved by taking advantage of the fact that the two rear wheels can be controlled independently. Hence, inside a turn, the outer wheel should have a bigger rotation speed than the inner one, in the same way, an automobile operates. This differential control of the traction wheels is used to increase the stability of the system, improving, therefore, the performances of the vehicle. However, a way of computing the difference between the speeds of the two rear wheels must be implemented. The overall speed of the moving vehicle is given by the two duty cycle control signals, and it is: The ratio between the outer wheel speed and the inner wheel speed is experimentally chosen based on the formula: The experimental procedure is undertaken for obtaining a suitable value for the speed ratio started by choosing this factor equal to 1. For a speed ratio equal to 1 there is no differential control of the rear wheels, both of them having the same rotation speed. The speed ratio produced satisfactory results for a value equal to 1.3. A 1.4-speed ratio factor is also suitable for the application, but increasing it more could cause unwanted behaviors such as the car turning around its axis. With a 1.3-speed ratio factor, a 20% (0.2) speed limit was achieved, with a lower value of 15% (0.15) during turns. Increasing the speed, even more, 25% (0.25) and keeping the lower value at its previous setting produces, in some cases, side-slips of the vehicle outside the track. By reducing the vehicle turning speed, for example, 10% (0.1) does not solve the side-slip issue. The leading cause of this behavior is related to the oval shape of the track, with short straight segments. As on a winding road, the robot should also limit its speed because sudden acceleration and deceleration actions cause undesired system’s reactions and safety issues are definitely to be considered during control algorithms design. Mixing this way of computing two different duty cycles for the two rear wheels, with the proportional controller introduced in the first part of this subsection, which will provide the overall DT, the vehicle shows more stability during the turns than it did without the differential speed control and a bigger speed can be achieved without losing the position requirements. Figure 3.2.2 Computing the rear wheels control signals 3.3 LQG and LTR Unlike the PID regulator, the LQG and LTR control laws are going to be designed in a theoretical manner, based on the mathematical model of the system, obtained in the previous section. However, before implementing the controllers in the Simulink environment for proper simulation and validation of their results, a short analysis of the open loop system is going to be depicted in the next subsection. 3.3.1 Position Computing and Reference Defining As illustrated in the previous chapter of the thesis, the output of the mathematical representation is the angle θ measured between the Y-axis of the robot frame and the X-axis coordinate of the inertial frame. There are also three inputs of the system given by the values of the duty cycles transmitted to the motors. Thereby, the four matrices,A,B,C and D  are introduced as a state-space block in a newly created model in the Simulink environment. However, the simulation does not recognize the output of the system as an angle. Considering the work in a digital environment, its values are increasing and decreasing following the given inputs. This behavior is as expected, assuming that a constant speed on the rear wheels and a certain angle of the front ones produces a variation of the output, increasing or decreasing its value based on the steering direction. However, the output θ is an angle, so the subsequent processing of the signal is realized. The following assumptions are made: the value of θ is measured trigonometrical; the minimum value for θ is 0 radians, and the maximum value for θ is π. It is natural that for bigger angles than π, the real value of the angle is computed by theta real = theta measured − π. Before applying this verification and then modification of the measured value, it must be made sure that the output of the system is not negative; therefore a Simulink block is used to compute its absolute value. Figure 3.3.1.1 Theta angle conversion As noticeable in the previous figure, the system’s output changes its value when the vehicle is going inside curvature of the road, for example. As assumed during the linearization procedure, the car starts its movement from a position which is perpendicular on the X-axis of the inertial coordinate system, thus leading to a θ equal to π/2 . If the camera spots a dark value in front of the car, which represents a black edge that needs to not be crossed, based on the position where the edge is seen, a deviation angle α will be computed in order to express the fact that the car needs to change its direction, less or more abruptly.  Based on this deviation angle, the reference of the control loop is going to change its value to determine the vehicle to turn when edges are spotted. Therefore the reference of the system will be given by: θ+α, with θ the system’s output. From the way of measuring the α angle, given by the following figure, it can be concluded that a positive α angle determines to steer to the left, while a negative one determines the steering to the right, as explicitly illustrated in the following figure: Figure 3.3.1.2 Deviations regarding the trajectory to be followed 3.3.2 Controller Implementation Firtsly, an LQG controller is implemented in the Simulink environment using the lqg Matlab function: where sys is the state-space representation of the system given by the A,B,C and D matrices. QXU is the penalty matrix considering that the cost function to be minimized by the algorithm is written as: The QWU noise covariance matrix is given by: The control signal u is computed with the help of an LQR (Linear Quadratic Regulator) such that J reaches is minimum value. A Riccati equation depending on the state-space representation of the system and the penalty matrices Q and R is solved with this purpose, but these details are not subject of the current description. However, for obtaining such a controller, a full state array x is required. The feasibility of this assumption is not guaranteed considering that in many control problems, not all the state components are measurable. If moreover, the process is affected by noise, a Kalman filter has to be used. After the Kalman filter estimates the full state of the system, the LQR algorithm computes optimally the control signal, based on the state estimation. This procedure is called the synthesis of a LQG controller.  Considering the penalty of the state deviation which needs to be accomplished and also the control signals limitations required for a safety operation mode, the values of these matrices are chosen conveniently. The returned controller is given by a state-space representation which is introduced into a state-space block in Simulink, and connected to the system considering a classical control loop. However, before doing so, the obtained controller is sampled with a convenient sampling period to ensure the functionality of the given process, using the c2d Matlab command. The control signals given by the discrete controller, before being fed to the system, are added to their linearization values and saturation blocks are also used to prevent the damages a very high control signal can produce on the system’s actuators. The implementation on the real system is illustrated in the figure below, where the deviation based on the array returned from the camera is given to the controller as an error signal, as mentioned previously. Figure 3.3.2.1 LQG control loop on the real system As mentioned previously, LQG controller is formed by a LQR and a Kalman filter.  However, when using a Kalman estimator together with a linear quadratic regulator, the robustness of the designed algorithm deteriorates. To overcome this loss of robustness, the LTR methodology is used in this example, as a second control option, to recover the robustness of the linear-quadratic regulator through a modified computation of this controller.  The same reference defining and position computing apply also for the LTR algorithm as well. No modifications are brought to the control loop, except for the controller, which is now computed using the ltrsyn command: where sys is the state-space representation given by the A,B,C and D matrices in. Kf represents the optimal gain filter matrix, while Qf and Rf are identity noise covariance matrices. The recovery of the full-state feedback linear quadratic loop is thus realized with a gain specified by RHO.  3.4 H2 and H∞ Considering the particularities of the current application, the requirements defined for the H2/H∞ control problem are: small errors in reference tracking; rejection of the disturbances which appear at the system’s output; (Considering that the sensor of the system is the camera, which operates as described in the previous chapters, disturbances on the system’s output can be caused by light fluctuations, shadows, etc.) and bounds for the control signals, knowing their technological limits. These requirements translate into the following transfers between the mentioned signals. ϵ = Sr, u = KSr and y = Sdo. The transfers are written considering a standard control loop as in the following figure: Figure 3.4.1 Standard control loop Computing a controller that satisfies the imposed performances requires the consideration of the system in a generalized form given by: In such a configuration, the partition of the inputs and the outputs has the following signification: u1 - external inputs (disturbances, noises, references); u2 - controlled inputs; y1 - controlled outputs (errors to be minimized, control signals to be bounded); y2 - measured outputs. In the case of the current application, this translates into: The closed-loop system is obtained by connecting the controller to the generalized system as in Figure 3.4.1. Figure 3.4.2 Closed loop system The purpose of the H2/H∞ controller computing can be now expressed as: Given a generalized system T with the corresponding partitions of the inputs and the ouputs, the H2/H∞ algorithms design the controller K which measures the system output y2 and computes suitable commandu2. In the same time, the controller K must be computed in order to ensure a stable closed loop system Ty1u1 and such that it minimizes the H2 norm of the closed loop system; respectively it bounds the H∞ norm of the closed loop system, ||Ty1u1 ||∞ < γ, for a given γ > 0.  Considering the imposed performance requirements the generalized system is written in the following form: T represents the system in the generalized form, 1 stands for the number of outputs to be measured and 3 stands for the number of inputs to be controlled. G denotes the transfer function associated with the state-space representation of the system. A discretization procedure is applied in this case too. All the procedure described explicitly for solving the H2 control problem is applicable for the H∞ suboptimal problem too. The only difference is made by the Matlab command which computes the controller which is now hinfsyn and used as: 4. Results and Conclusions For each of the computed controllers, simulations are realized to validate their functionality on the given system. Each closed loop is analyzed for a step reference signal and the results are illustrated in the figures below:                                           Figure 4.1 Reference tracking and control signals computed by the LQG controller for a step reference                                                         Figure 4.2 Reference tracking and control signals computed by the LTR controller for a step reference                                                     Figure 4.3 Reference tracking and control signals computed by the H2 controller for a step reference                                                                                                     Figure 4.4 Reference tracking and control signals computed by the H∞ controller for a step reference The signals evolution over time, as noticeable in the illustrated graphics, does not highlight significant differences between the designed control algorithms. Control signals evolution over time also reflects with accuracy the real behavior of the car. For a positive error, one of the duty cycles of the rear wheels increases, while the other one decreases. For a negative error, they change their evolution symmetrically, thus differentiating between the two types of turning, to the left, respectively to the right. In the same time, the duty cycle control signal given to the servomotor shows a variation between 0.04 for a positive error and 0.02 for a negative one, keeping its values constant at 0.03 when no error is computed. However, H2 and H∞ algorithms represent powerful tools which do not exhibit their full-capacity advantages due to the low complexity of the system’s model. Therefore, a proportionate effort should be put into solving a real-life problem, considering its complexity and performance requirements. The LQG and LTR can also be interpreted as a particular case of the H2 control problem, as detailed in, this explaining the similarity between the time domain solutions between these two algorithms and H2. When it comes to the H∞ method, no significant advantages are enlightened by the time domain graphical evolution either. What is yet remarkable at this control option is represented by the advantages presented in the case of unstructured perturbations affecting the system’s model. As already mentioned in the paper, the nominal model approximates the real system. Therefore a behavioral uncertainty is present throughout the entire design process. Robustness related to this estimations is achieved with the H∞ control option. However, a statistical comparison is illustrated in the following table, which contains the values of the step-response characteristics, computed for the closed loop systems. Considering that the sampling time used for the simulation is equal to 0.02s, as mentioned in the previous chapter, the results are as in the following table: LQG LTR H2 H∞ RiseTime 0.016s 0.0121s 0.0076s 0.0068s SettlingTime 0.022s 0.0196s 0.015s 0.0144s Table 4.1 Step-response characteristics for the closed loop system The required performances are accomplished both with the classical and modern approaches. As concluded previously from the simulation results, no noticeable differences are in the real behavior of the four algorithms illustrated in the current chapter. The system’s model influences the car behavior slightly, compared to the classical PID perspective. Considering the neglect of some of the forces which affect the system, together with model parameters approximation, these results are as expected. Improved performances can be achieved as a future work by including the model uncertainties in a H∞ controller design procedure.
View full article
1. Introduction   This article demonstrates how to control a 4-wire server fan based on temperature or user input, using the Model-Based Design Toolbox for S32K1 MCUs. The Model-Based Design Toolbox represents a solution which allows the complex applications deployment on NXP hardware directly from Simulink. By incorporating hardware optimized software, such as drivers, libraries, and tools, the Model-Based Design Toolbox allows the users to focus only on the algorithm development, while making such applications hardware-aware is handled by the toolbox. By the integration with the MathWorks ecosystem, the MBDT leverages the model-based design paradigm, thus enabling a programming process based on models - users to not need to write C code for implementing their designs, but create logical diagrams using Simulink blocks performing dedicated functions. In this article, we will demonstrate how this tool can be used for designing and deploying on an S32K146 Evaluation board a fan speed control application. Thus, the steps proposed for achieving this are described thorughout the article, in the following sections: II. Application overview – how the application works and the links between the components; III. Hardware design – the description of the components used and the electrical diagram; IV. Software design – the application execution flow and the model implementation explained in more detail; V. Conclusion – the results of the application.   2. Application overview   The application has 2 operating modes: automatic and manual. To switch between operating modes, we need to press the SW2 button on the S32K146 board. When starting, the application is in automatic operating mode (the RGB LED of the board lights up green): this means the fan adjusts its speed according to temperature. In manual mode (the RGB LED of the board lights up blue), the fan changes its speed depending on the value supplied by the potentiometer. The graphs and values of fan speed, acceleration, ambient temperature will be displayed in FreeMASTER. Block diagram   Figure 1: Block diagram   3. Hardware design   A. Hardware components The required hardware components are:  S32K146 Evaluation board  Thermistor NTC100K  4-wire PC fan   12V power supply AC-DC.   1) S32K146 Evaluation board The S32K146EVB serves as an affordable evaluation and development board designed for a wide range of industrial and automotive uses. The board is the “brain” of the application, as it collects data from various sensors (e.g.: temperature sensor) and uses the algorithm to regulate the actuators (e.g.: the BLDC motors found in fans).  For more information about the board, please read from here.   2) Thermistor NTC100K A thermistor is a resistor whose resistance is dependent on temperature. The temperature value is calculated using the Steinhart-Hart equation. The Steinhart-Hart coefficients A, B, C vary depending on the type and model of thermistor and the temperature range of interest. To find these coefficients, we use three values of resistance data for three known temperatures. For example, from NTC100K Thermistor Datasheet we get for the temperatures of 15℃, 25℃ and 45℃, corresponding resistance values of 156407 Ω, 100000 Ω and 43659 Ω. It results, according to the equation (2), that the coefficients have the following values:  So, the steps to determine the temperature are to get the thermistor resistance using a voltage divider converter along with an analog-to-digital converter (ADC) and calculate the temperature from the resistance.    3) 4-wire PC fan The fan has 4 pins, being used especially for processors with high power consumption. The simplest fan has 2 pins, one for power and one for ground. The 3-wire fan has an extra pin called “tachometer”, which indicates the speed of the fan (one/two impulses are received for each rotation). With 2-wire and 3-wire fans, the speed is controlled by increasing/decreasing the voltage on the power pin. Instead, the 4-wire fan has a control pin and uses PWM (Pulse Width Modulation) to control the speed.  Before using the fan, we must find out information such as the maximum speed, the number of impulses per rotation given by tachometer and the minimum operating speed if necessary. These things can be looked up in the fan’s datasheet or can be determined experimentally if we have an unknown fan, and we cannot find its datasheet.  The values of the fan used as an example in this article were determined experimentally and we got an approximate maximum speed of 300 rotations per second (18000 rpm), two impulses per rotation and a minimum operating speed of 80 rotations per second (4800 rpm).    4) 12V power supply AC-DC The power supply converts alternating current (AC) electrical energy into direct current (DC) electrical energy with an output voltage of 12 volts. In our application, it will supply the power for the fan.   B. Electrical schematic There are multiple hardware configurations for the fan speed control application. We will use, in addition to the hardware components mentioned above (fan, 12V power supply, thermistor), the potentiometer, the SW2 button and the RGB LED of the S32K146EVB.  We propose the following electrical schematic:  Figure 2: Electrical schematic Note! It is important that all components are connected to the same ground.   C. Hardware setup A possible hardware setup may look like in the following picture:  Figure 3: Hardware setup example   4. Software design   A. Prerequisite software To be able to follow the next steps in this article, the following software is necessary: MATLAB ®  and Simulink ®  (2021a or newer), including Stateflow ® , MATLAB ®  Coder TM , Simulink ®  Coder TM , Embedded Coder ® Model-Based Design Toolbox for S32K1xx 4.3.0   B. Flow chart The application execution flow is based on a state machine, according to the following diagram. Figure 4: State machine The architecture of the application is a closed-loop system, which uses a feedback signal to adjust the fan speed. The current fan speed and the fan acceleration update their values with each tachometer pulse. The difference between the reference speed (set using temperature or potentiometer) and the current speed, alias error signal, is the input to the closed-loop control system, such as a proportional-integral-derivative (PID) controller. The PID controller applies a correction based on proportional, integral, and derivative coefficients to a control function, in our case, it determines the PWM duty cycle to control the fan speed.  Figure 5: Application's model   C. Model Overview From top to bottom (Figure 5), we have 4 big sections:  Initialization Switching between operating modes The operating modes which set the reference speed The control algorithm. Let’s take each section to dive further into the details.    1) Initialization  Figure 6: Initialization section We have on the first line, from left to right, the Configuration block for S32K1xx processor family, the FreeMASTER Configuration Block and two ADC Configuration Blocks. On the second line, we have the pull-up resistance on the tachometer pin and two mapping functions from the temperature value and the ADC potentiometer value to the reference speed. Also, there are variables for current operating mode, temperature value, reference speed, current speed, duty cycle and some other auxiliary variables.  The required configurations of the processor configuration block are the default ones, except for the processor model and the download interface (Figure 7).  For the FreeMASTER configuration block, we set the communication interface (e.g.: LPUART1), the baud rate (e.g.: 19200) and long interrupt serial communication. This component provides an interface where relevant data such as current speed, ambient temperature and many others are displayed. In the ADC configurations blocks, used for reading temperature and potentiometer value, we select the ADC converter number and the resolution mode (e.g.: 10-bit conversion).   Figure 7: Configuration block for S32K1xx family of processors   2) Switching between operating modes We configure the pin PTC12 (SW2) to generate a falling edge interrupt on each button press, using the GPI ISR block. Figure 8: Switching mode section When an interrupt is generated, the value of the operation mode variable is toggled and the color of the LED corresponding to the operating mode lights up (automatic mode – green, manual mode – blue). It also enables/disables the PIT (Periodic Interrupt Timer) interrupt which triggers the ADC reading of the temperature sensor at each one second (Figure 10).  Figure 9: The function called when the interrupt is generated.  Figure 10: Enable/disable PIT interrupt for ADC temperature reading; RGB LED in Automatic & Manual mode   3) Operation modes  Figure 11: Operation modes section Depending on the operating mode, the reference speed is set by the temperature value or the ADC value of the potentiometer. a) Automatic mode In this mode, the PIT block is enabled, and the ADC value of the thermistor is read once per second. The resolution of the ADC is 10 bits. So, it can take values between 0 and 1023, which corresponds to voltage values between 0V and 5V. Let’s assume Vout is the output voltage on the pin PTB13. Also, according to the electrical schematic from Figure 2, we have a voltage divider: We can find out the value of thermistor resistance: And then, we can get the temperature value using the Steinhart-Hart equation (1).  Based on the temperature, we can map a value for reference speed. We can define for this mapping a linear function or whatever we need.  Figure 12: Automatic mode   b) Manual mode In manual mode, the ADC value of the potentiometer is read and mapped to reference speed.  Figure 13: Manual mode   4) The control algorithm  Figure 14: The control algorithm section In this section, the closed loop of the system is implemented using the PID (Proportional-Integral-Derivative) controller. We must tune the coefficients of the PID controller (Kp, Ki, Kd) to produce the optimal control function. There are several methods for tuning: manual, Ziegler-Nichols or using software specialized tools. For this application, the Ziegler-Nichols method was used, and, for fine adjustment, manual tunning was applied. After applying this method, we get the following values: KP = 0.003, KI = 0.003, KD = 0.001.  Figure 15: PID controller configuration With the PWM signal from the PID controller, we control the fan speed via the PWM pin, using the FTM PWM Config block. We configure the block as follows:  Figure 16: Parameters of FTM PWM Config block According to the electrical schematic (Figure 2), the pin used to control the fan speed is PTC1, which corresponds to FTM0_CH1. This means we need to configure the channel 1 from the module 0 of FTM (FlexTimer Module). To get the fan current speed, we need to know the period between two pulses from the tachometer. This can be determined using the FTM Input Capture block, which returns the timestamp in microseconds. Remember that there are two pulses per rotation. We measure the speed once every 10 milliseconds. So, the acceleration has the following value:  Figure 17: Calculation of fan speed and acceleration   D. FreeMASTER To visualize the results of the application, you can create a FreeMASTER project. Add the .elf file of the built application to Project – Resource files – “pack” directory setup – MAP Files – Default symbol file. You can add variables to the Variable Watch section, such as operation mode, current speed, reference speed, temperature (Figure 19). Also, you can create a graph, as in Figure 18, using the FreeMASTER oscilloscope with the current speed and reference speed. In the following figure, we can observe that the system is initially in automatic mode: temperature is about 28 Celsius degrees, which corresponds to an approximate reference speed of 110 rotations per seconds. Then, when SW2 button is pressed (at second 685 on the graph), the system goes into manual mode and the reference speed is set about 236 rotations per second, which is mapped according to the value read from the potentiometer. The current speed (red line) is tracking the reference speed imposed (green line).  Figure 18: Graphic with reference speed and current speed Also, we can track values such as operation mode - boolean value (0 for automatic mode and 1 for manual mode), temperature in Celsius degrees, reference speed and current speed measured in rotations per second, acceleration or the PWM duty cycle used for controlling the fan speed.  Figure 19: Variable watch section   5. Conclusion   In conclusion, the application consists in controlling the fan speed depending on the temperature or the potentiometer value, using the Model-Based Design Toolbox for S32K1 MCUs. It combines notions from systems theory, electronics, and embedded systems, representing an academic study on the use of fans for temperature control in different applications like servers, routers, switches, etc.   Useful links:   1. S32K146EVB:   https://www.nxp.com/document/guide/getting-started-with-the-s32k146-evaluation-board-for-general-purpose:NGS-S32K146EVB  2. NTC100K Thermistor: https://www.tme.eu/Document/f9d2f5e38227fc1c7d979e546ff51768/NTCM-100K-B3950.pdf  https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation#Steinhart%E2%80%93Hart_coefficients  3. 4-wire fan:  https://www.electroschematics.com/4-wire-pc-fan/  https://www.nidec.com/en/product/search/category/B101/M111/S100/NCJ-V40S-E5-57/  4. PID coefficients:  https://control.com/textbook/closed-loop-control/p-i-and-d-responses-graphed/  https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller    NXP is a trademark of NXP B.V. All other product or service names are the property of their respective owners. © 2024 NXP B.V. MATLAB, Simulink, and Embedded Coder are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.  
View full article
This page summarizes all Model-Based Design Toolbox topics related to the HCP Product Family. Model-Based Design Toolbox for HCP - Release Notes: Rev 1.3.0 - NXP Model-Based Design Toolbox for High-Performance Computing Platform (HCP) - version 1.3.0 RFP  Rev 1.2.0 - NXP Model-Based Design Toolbox for High-Performance Computing Platform (HCP) - version 1.2.0 RFP  Rev 1.1.0 - NXP Model-Based Design Toolbox for High-Performance Computing Platform (HCP) - version 1.1.0 RFP  Rev 1.0.0 - Model-Based Design Toolbox for High-Performance Computing Platform (HCP) - version 1.0.0 EAR 
View full article
This page summarizes all Model-Based Design Toolbox tutorials and articles related to HCP Product Family.   S32G2 Hybrid Electrical Vehicle (HEV) demo on S32G2 
View full article
Introduction With the latest advances in microcontrollers, they are getting faster and more efficient, being able to successfully run complex algorithms in a reasonable time. One important category are Artificial Intelligence algorithms. Using both NXP ® and MathWorks ® ecosystem, the steps to deploy an AI algorithm to NXP hardware are simplified and straight forward. The article provides guidance on how to implement a State-of-Charge (SoC) estimation algorithm based on a feedforward deep learning network developed by Mathworks' experts (Battery State of Charge Estimation in Simulink Using Deep Learning Network). The algorithm is then deployed on i.MX RT1060 Evaluation Kit using NXP Model Based Design Toolbox for I.MX RT. As the main objective of the article is to demonstrate how to run an AI algorithm on NXP evaluation board, the example is ran in Processor-in-the-Loop (PIL) simulation mode. This type of simulation represents an important step in the validation process of an algorithm, corner cases can be easily replicated as the input data can be directly loaded from MATLAB's workspace. The execution of the algorithm is done on the microcontroller. For a more detailed overview of the execution of the algorithm, code profiling options can be enabled to generate a report which details execution times.   What BMS is Battery Management System (BMS) is a critical component in battery-driven devices, such as electric vehicles. Their main objective is to ensure that the battery pack remains in an optimal and safe operating mode. At the core of the most tasks, the BMS must compute the State-of-Charge (SoC) estimation. To make a precise estimation, the algorithm requires an accurate model of the actual cells, which are difficult to characterize. An alternative to this approach is to create data driven models of the cell using AI methods such as neural networks.   Deep Learning Toolbox The Deep Learning Toolbox™ developed by Mathworks provides a framework for deep neural networks to be used in algorithms. It enables the user to use convolutional neural networks (ConvNets, CNNs) and long short-term memory (LSTM) networks to perform classification and regression on image, time-series and text data. The network and layer graphs are not mandatory to be created in MathWorks ecosystem, as other frameworks can be used, such as TensorFlow™ 2, TensorFlow-Keras, PyTorch ® .   Prerequisite Software To create, build and deploy a Simulink Model onto the i.MX RT RT1060 EVK, the following software is required: MATLAB R2022a Deep Learning Toolbox Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ®  Support Package for ARM Cortex-M Processors i.MX RT MBD Toolbox (version 1.3.0)   Prerequisite hardware The hardware required for this example is i.MX RT1060 Evaluation Kit. The i.MX RT1060 crossover MCUs are part of the EdgeVerse™ edge computing platform. The core of the MCU is a Arm ® Cortex ® -M7 core at 600 MHz. The device is fully supported by NXP’s MCUXpresso Software and Tools, a comprehensive and cohesive set of free software development tools.   Model - Overview The BatterySOCSimulinkEstimation model included in the Deep Learning Toolbox computes the SoC estimation using two methods: first method uses a neural network and the second one uses the extended Kalman filter algorithm. By plotting data generated by these two estimations and comparing it to the true values, it is possible to validate that the FNN predicts the SoC with an accuracy of 3 within a temperature range between -10 C and 25 C.   Note! Before making any modification to the model included in the toolbox, it is recommended to create a backup of the example in order to be able to revert to the original state. For this example, the predictions are done on the i.MX RT1060 evaluation board in PIL mode while the Kalman filter is locally computed on the computer. Referenced Model From the original model, the FNN block must be added in a new blank model. As the newly created model is used in a Referenced model, an input port must be added to received data (make sure the Port dimensions is set to 5), and one output port to return the data computed. The other settings for all these 3 blocks can be left default. Next, in the Model Settings the following changes must be made: Hardware Implementation Hardware Board: NXP MIMXRT1062xxxxA Target Hardware Resources Download Type: OpenSDA OpenSDA drive: Click on browse and select the partition assigned to the IMXRT1060 PIL Communication interface: Serial Interface Hardware UART: LPUART1 Serial port: The COM port assigned to the board (it can be found by using Device Manager or by running serialportlist command in MATLAB Command Window) Baudrate: 115200 Code generation Verification Check Enable portable word sizes   Top model Based on the BatterySOCSimulinkEstimation model included in the Deep Learning Toolbox, the FNN block must be removed (either deleted or commented). A ModelReference subsystem must be added to the model. In the Block Parameters of the ModelReference subsystem, select the model created and configured above. Simulation Mode must be set to Processor-in-the-Loop (PIL). Another modification that must be done is the sample time of the nnInput Data Read Memory block which must be changed from 0 (continuous) to -1 (inherited).   Next, in the Model Settings the following changes must be made: Hardware Implementation Hardware Board: NXP MIMXRT1062xxxxA Target Hardware Resources Download Type: OpenSDA OpenSDA drive: Click on browse and select the partition assigned to the IMXRT1060 PIL Communication interface: Serial Interface Hardware UART: LPUART1 Serial port: The COM port assigned to the board (it can be found by using Device Manager or by running serialportlist command in MATLAB Command Window) Baudrate: 115200 Code generation Verification Check Enable portable word sizes   Deployment and validation Now that both models (top model and referenced model) are configured, SIL/PIL manager can be opened from the APPS tab in Simulink. In the SIL/PIL tab, the simulation must be selected to SIL/PIL only (red rectangle) and the System Under Test to Model Blocks in SIL/PIL mode (blue rectangle). Before the simulation is started, the BatterySOCSimulinkEstimation_ini.m script must be executed to load the necessary data into MATLAB's workspace. The script can be found next to the Simulink Model included in the Deep Learning Toolbox. From the top model, the SOC scope can be opened to display the generated data. The simulation can be started from the RUN button within the scope. Note! Diagnostic Viewer can provide important information if there are any errors within the models. If the simulation is successfully deployed on the target, the data plotted into the scope should look like this:   Code profiling Code profiling is an important tool to validate an algorithm as it provides important information about the execution time. The time is measured by the timer configured in Model Settings -> Hardware Implementation -> Hardware board settings -> Target hardware resources -> Profiling Timers. By default, the PIT timer, channel 0, is used. The Code generation can be enabled from Model Settings -> Code Generation -> Verification -> Code execution time profiling -> Measure task execution time. The generated report can either be Coarse (referenced models and subsystems only) or Detailed (all function call sites). When the simulation is completed, a small window is opened. The Profiling report can be opened by clicking on the view the full code execution profiling report.   Conclusion The NXP and Mathworks ecosystems enable the users to deploy an Artificial Intelligence algorithm onto the NXP hardware. In the end, I strongly recommend the users interested in BMS and Artificial Intelligence to watch the Deploying a Deep Learning-Based State-Of-Charge (SOC) Estimation Algorithm to NXP S32K3 Microcontrollers webinar hosted by Javier Gazzarri (MathWorks) and Marius Andrei (NXP).   EdgeVerse and NXP are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. Arm, Cortex are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. PyTorch, the PyTorch logo and any related marks are trademarks of The Linux Foundation. MATLAB, Simulink, Stateflow and Embedded Coder are registered trademarks and MATLAB Coder, Simulink Coder, Deep Learning Toolbox are trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks. TensorFlow, the TensorFlow logo and any related marks are trademarks of Google Inc.
View full article
General Tip of the day Tip of the day  Model Reference Model referencing in i.MX RT Toolbox  Peripherals FLEXCAN How to set i.MX RT FlexCAN receive message buffer Mask for range of IDs ?   LPI2C How to use LPI2C in transfer mode in i.MX RT  LPUART Questions about i.MX RT LPUART driver  Apps
View full article
This page summarizes all Model-Based Design Toolbox topics related to the DSC Product Family. Model-Based Design Toolbox for DSC- Release Notes: Rev 1.0.0 - NXP Model-Based Design Toolbox for DSC MC56F8x MCUs - version 1.0.0 
View full article
    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.3.0 EAR   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.3.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated S32 Configuration Tools, RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 115 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13957417   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K311 S32K312 S32K314 S32K322 S32K324 S32K341 S32K342 S32K344 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.       Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (v3.0.0 CD04) – only for S32K311, S32K358 and S32K396 New S32 Configuration Tools version supported (v1.6) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.31: All functions in the Automotive Math and Motor Control Functions Library v1.1.31 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.     Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model.     Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 115 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.3.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience This release (1.3.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt                
View full article
    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.0.0 RTM       The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.0.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K344 MCU and part of its peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, GPT). It also adds support for FreeMASTER, AMMCLib, and Simulink simulation modes – Software-in-Loop, Processor-in-Loop, and External mode. Moreover, this release adds the option to configure everything (pins/peripherals/clock) via an external configuration tool - S32 Configuration Tools or EB Tresos. The product comes with over 70 examples, covering everything that is supported, including a motor control application demo. FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=12747097 Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K344 Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI GPT DIO Support for profiling execution times Support for register R\W and memory R\W operations Provides 2 modes of operation: Basic User Mode – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced User Mode – using S32Configuration Tool or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.24 for: All functions in the Automotive Math and Motor Control Functions Library v1.1.24 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2020a R2020b R2021a S32Design Studio Integration We added a simple mechanism to provide users the opportunity to export the generated code from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project, as well as for debugging purposes.   Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode   Examples for every peripheral/function supported: We have added over 70 new examples, including: Motor control application Communication (SPI, CAN) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.0.0 is fully integrated with MATLAB® environment in terms of installation: Target Audience This release (1.0.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.    Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt    
View full article
This page summarizes all Model-Based Design Toolbox tutorials and articles related to DSC MCUs Product Family.
View full article
Introduction This article is going to show how to use the IMXRT117X board in co-simulation mode to run a Deep Learning application of facial recognition. Given that a development board has limited resources, the deployment of a Deep Learning application should be done as efficiently as possible. For now, since the latest version of Matlab (2021a) does not offer support for CNN optimization for Arm Cortex-M processors, we will restrict to developing an application in co-simulation mode. That means that while the data will be provided by the target board, the actual processing will take place in a Matlab environment. By running in co-simulation mode, we will exploit both hardware and the Matlab software capabilities.  The goal of this article is for the user to be able to: use a pre-trained CNN model from Matlab; use the MBDT IMXRT Board Object for co-simulation; develop a standard facial recognition application; Hardware overview For the development of this application, the i.MX RT1170 Evaluation board was used with a MIMXRT1176 CPU, and the attached ON Semiconductor OV5640 camera. Additionally, the RK055AHD091 LCD panel can be used to visualize the frames from the camera. The i.MX RT1170 EVK provides a high-performance solution in a highly integrated board. It consists of a 6-layer PCB with through hole design for better EMC performance at a low cost, and it includes key components and interfaces. Some of the i.MX RT1170 EVK main features are: MIPI camera sensor connector and MIPI LCD connector JTAG connector and On-board DAP-Link debugger Connectivity: 2x Micro-USB OTG connectors, Ethernet (10/100/1000M) connector, Ethernet (10/100M) connector, SIM card slot, CAN transceivers 5V Power Supply connector For a more comprehensive view and a more detailed description regarding hardware specifications and user guides, please check the documentation here. For this example, we are going to make use of the following peripherals and components hence make sure you have all of them available and you are familiar with their intended scope: ON Semiconductor OV5640 camera used for capturing the frames from the board; A CAT-5 ethernet cable will be used for getting video frames from the IMXRT on-board camera to be processed in MATLAB; Mini/micro USB cable for downloading the executable on the target; (Optional, if LCD is used) 5V power supply Software overview Software delivered by MathWorks: MATLAB (version 2021a) (we assume you have already installed and configure this). As a hint, please make sure the MATLAB is installed in a path with empty spaces; MATLAB Embedded Coder is the key component that allows us to generate the C code that will be cross-compiled to be executed on the target; Deep Learning Toolbox allows us to use pre-trained networks or re-train and re-purpose them for other scenarios; Image Processing Toolbox for preprocessing the images before training the network; Computer Vision Toolbox for performing face detection using the Viola-Jones algorithm; Software delivered by NXP: NXP MBDT IMXRT Toolbox as IMXRT embedded target support and plug-in for MATLAB environment to allow code generation and deployment. Make sure you install this toolbox in MATLAB 2021a. Deep Learning – Facial recognition Facial recognition is the process of verifying a person’s identity through their facial features in order to grant access to a service, application, or system. Recognition needs to be performed in 2 steps: 1) face detection – so identifying and isolating the face area from an image and 2) face recognition – analyzing the features of the image and classifying them. In this example, face detection is performed with the CascadeObjectDetector, from the Matlab Computer Vision Toolbox, which is based on the Viola-Jones algorithm, and face recognition will be performed with AlexNet, a pre-trained neural network specialized for object classification. source: https://test.neurohive.io/en/popular-networks/alexnet-imagenet-classification-with-deep-convolutional-neural-networks/ 1.Datasets In order to train the network for our application, custom datasets will need to be generated containing the faces of the people we want to recognize. A challenge that arises regarding the dataset are the changes that occur to a person’s appearance: during the day the mood of a person can change, which may affect their facial expressions; also, the lighting of the room can affect the features, by enhancing or diminishing them; nevertheless, the appearance of a person might vary depending on make-up, hairstyle, accessories, facial hair, etc. Thus, this is something that needs to be taken into consideration when creating the dataset used in training. A recommendation for better performance would be to take samples of a person's appearance multiple times during the day and in different lighting conditions. Another challenge is dealing with the category of unknown people since it is impossible to have and use a picture of every unknown person. A possible approach is to use a threshold value for classifying the pictures so that a person is accepted as “known” only over a certain probability.  Another solution would be to create an additional dataset for the “Unknown” category, which should contain various faces of different people. This way the model should be able to generalize and differentiate between known and unknown people. One of the datasets that can be used for this purpose is the Flickr-Faces-HQ Dataset (FFHQ) which contains over 70,000 images with a high variety in terms of ethnicity, age, emotions, and background. For this example, 6 classes were used, 5 of them representing known people and 1 for unknown people. In order to generate a dataset using the attached OV5640 camera, the Matlab client will connect to the Board Object on the target, it will request frames from the camera and it will save them as BMP files. %% Establish communication with the target board board_imxrt = nxpmbdt.boardImxrt('162.168.0.102', 'Video', 'GET'); %% Request frames from the camera and save them as bmp images count = 0; while (1) % Camera snapshot img = board_imxrt.step(); imwrite(img, [num2char(count) '.bmp']) end The next step is to extract the face area from an image and resize it to 227x227x3 so that it can be given as input to AlexNet. For that, we can create a directory with all the images that we want to train/test the network with and run the following script, which will perform face detection, then crop and resize the images to the desired dimensions. All the scripts and code snippets presented are also included in the attached archive. % Create Face Detector Object faceDetector = vision.CascadeObjectDetector; inputFolder = 'datastorage/to_process'; outputFolder = 'datastorage/processed/'; pictures = dir(inputFolder); for j = 3 : length(pictures) imgName = pictures(j).name; img = imread([inputFolder '/' imgName]); % Perform face detection bboxes = step(faceDetector, img); if(sum(sum(bboxes)) ~= 0) detectedFace = imcrop(img, bboxes(1, :)); % Resize image to fit AlexNet requirements detectedFace = imresize(detectedFace, [227 227]); imwrite(detectedFace, [outputFolder imgName]); end end       2.Training the network For training the network, we need to modify the output layer of the AlexNet network to match the number of classes we use, in this example 6. To improve the results for the case where we might not have enough input data, we can augment the images, and for that, we use the imageDataAugmenter from Matlab, where we set the images to be flipped horizontally and/or vertically, and rotated with a random angle between -90 and 90 degrees. This will help the model to avoid overfitting and generalize better. allImages = imageDatastore('datastorage', 'IncludeSubfolders', true,... 'LabelSource','foldernames'); % Split into train and validation sets [imgSetTrain, imgSetTest] = splitEachLabel(allImages, 0.7, 'randomized'); augmenter = imageDataAugmenter('RandXReflection', true,... 'RandYReflection', true,... 'RandRotation', [-90 90]); augimds_train = augmentedImageDatastore([227 227], imgSetTrain,... 'DataAugmentation', augmenter); augimds_test = augmentedImageDatastore([227 227], imgSetTest,... 'DataAugmentation', augmenter); Set the training options, these can be configured by the user as they wish, for this example, we have used a learning rate of 0.001 and batch size of 64, and have run the model for 7 epochs. opts = trainingOptions('sgdm', 'InitialLearnRate', 0.001,... 'Shuffle', 'every-epoch', ... 'MaxEpochs', 7, 'MiniBatchSize', 64,... 'ValidationData', augimds_test, ... 'Plots', 'training-progress'); trained = trainNetwork(augimds_train, layers, opts); save('trained_50_50_ep7_6classes', 'trained'); Save the trained network into a .mat file. It will be used for classifying the frames received from the camera. 3.Setup For the installation and usage of the MBDT IMXRT Toolbox please refer to this article. Running in co-simulation mode means that the target board is able to communicate with the host (in this case, Matlab) through the TCP/IP protocol, thus exploiting both hardware and Matlab software capabilities. The logic of the application is presented in the following figure: the attached camera will send the captured frames to the computer through an Ethernet connection; there, the frame will be processed using a Matlab script, which will perform Face detection and be further sent to the AlexNet trained classifier, which will return a label and the probability of that label being correct. Then, based on whether the person was recognized or not, a signal will be sent to the IMXRT board to toggle the USER LED. In order to create the executable that will act as the server part of our application, we will create a new Simulink model containing the IMXRT Board Object. For this example, the Board Object is sufficient for creating the co-simulation environment and running the application, for it makes use of both Camera and LWIP functionalities: The next step would be to configure the Board Object in order to be able to communicate with the host: open the Block Parameters window and input the IP address and port number you want to use. In the case of the server, it does not matter whether it is configured in SEND or GET mode, because it will wait for commands from the client. Then the model’s Ethernet parameters need to be configured. Open the Configuration Parameters window from Simulink, select Hardware Implementation from the left menu and then go to the Ethernet tab: here insert the values of the board IP address, subnet mask, and the gateway address.   Connect the board through USB to the computer. Go to the Download tab and select the drive you want to download the executable to. More information about this process is presented here. Also, please make sure that you have selected the NXP MIMXRT117Xxxxxx Hardware Board. The selection of the MIMXRT117X Hardware Board should copy the default ConfigTool MEX file which you can modify, but you can also create or use another MEX file as long as it has the name <model_name>_<core>Config.mex. In the MEX file are configured the peripherals and pins settings, in this case the Camera peripheral and the GPIO User LED. For better performance, we recommend using a low-resolution for the Camera. Build the model and the generated executable will be copied on the target board. Restart the board. Next step is to connect to the target board from Matlab and start receiving frames from the attached camera. For this, we will use a Matlab script that will create a board object configured to request frames from the target. The nxpmbdt.boardImxrt object is the same type as the one used in the previous Simulink model: here we can use it as a function call in a script, so we need to configure it accordingly. For information about how to use the Board Object, use the following command:  The Matlab script that will run in co-simulation and will connect to the target board: load trained_50_50_ep7_6classes.mat trained; faceDetector = vision.CascadeObjectDetector; board_imxrt = nxpmbdt.boardImxrt('162.168.0.102', ... 'Video', 'GET'); while (1) img = board_imxrt.step(); bboxes = step(faceDetector,uint8(img)); if (sum(sum(bboxes)) ~= 0) es = imcrop(img, bboxes(1,:)); es = imresize(es, [227 227]); [label, ~] = classify(trained, es); if ~strcmp(char(label), 'Unknown') board_imxrt.led_on(); else board_imxrt.led_off(); end else board_imxrt.led_off(); end end When running simulation mode from a Matlab script, please make sure that the configuration structure (the script mscripts\target\imxrt_code_gen_config) is configured accordingly with the desired hardware. After the application has received the camera frame from the board, it can start the preprocessing required for classification. We create a face detector object using the CascadeObjectDetector, to which we will input the camera frame and we receive in exchange the margins of the box where it detected a face. In the case a face was detected, we crop the image and resize it to 227x227x3, which is the size the AlexNet network requires, and we classify the image using the loaded model. The USER LED on the board will be switched on if the person was identified. The script also provides a Matlab UI Figure for better visualization.   Conclusions The NXP MBDT Toolbox provides a solution for developing Computer Vision applications targeted for Arm Cortex-M processors. This aims to be a temporary approach until the Matlab support required for generating CNN optimized C code is added.
View full article