Project 1 (Mini Project on Vehicle Direction Detection

 

Mini  Project -  Vehicle  Direction  Determination

 

General Overview:

• Identifying the direction of the vehicle is one of the important & diverse features in Autonomous driving & Advanced Driver Assistance Features. This particular sub-feature of identifying the direction of vehicle is basically identifying the direction the vehicle is taking based on the camera input.
• Camera reads the road signs & stores into its memory with unique values for left turn, right turn & straight drive. Depending on the direction it is taking, final indication is given to the driver – as an indication if he is driving in the recommended direction or not.
• Vehicle Direction Determination can also be coupled along - side features like GPS systems to identify whether the vehicle is reaching its destination in an optimized manner. This sub feature can also be used along with Lane Detection, Highway Warning, Ramp Entry / Exit in Wrong Way Detection etc.

 

 

Aim Of Project:-

1. 
   Development of MATLAB Simulink model as per requirement.
   2. Tag the requirements to the simulink model; tagging requirement 1 & requirement 2 to their corresponding subsystems.
   3. Creation of SLDD File
   4. Check for MAB guidelines
   5. Code generation

 

Description-

 

Creation of SLDD FILE-

• 
  Data has been given to create a SLDD file.
  •With the use of following data given, I've created a sldd file.
  •File Created is as shown in the below figure.

 

 

• At first we should open the SIMULINK page and we should go into the modeling section and in design section we should select the 'LINK TO DATA' option ad there we can create a new SLDD file and the procedure is shown in the below image

 

 

• The SLDD file should contain the data which is provided by the user or the client but here in this model the following specifications are provided in above (Signals & Calibration Data List) table  and the data is manually given in the data design, sub folder of the external data folder of the vehicle direction.slx of the model explorer.
• To create the SLDD file, we clicked on modelling tab›drop down menu›select link to data dictionary.

 

 

• To make sure when ever we change any values or any changes are made in the data sheet we should do 'Save changes in external data after saving all the changes we can close the model explorer tab.

 

 

 

Model Creation:

Sub-System Creation :

• After completing the SLDD data adding the go back and on the SIMULINK page open the 'SUBSYSTEM' block and double click on it and inside create another two subsystems in the main subsystem
  •And name that main subsystem as 'Vehicle_ Direction' and open it and create anothe two subsystems in it.

 

 

• We known create the two subsystems in side this vehicle _direction subsystem and name them as a 'Requirement-1 & Requirement-2'. as shown in the below image attached and the given requirement logics can be developed inside those subsystems.

 

 

 

 

 

Requirement - 1 subsystem :

• After creating these subsystems go into the first requirement subsystem and model the given logic in this and now lets see the requirements.

 

Requirement - 1:

Steering wheel input as yaw rate (Signal name: SteeringWheel_YawDegreeInput) is the input for this system.

This is compared against 3 angular values, one each for left turn, right turn & straight drive (Calibration Values: Right_Turn_AngularLimit, Left_Turn_AngularLimit, Straight_Drive_Steering_Angle) to say which specific direction the steering wheel is turning towards.

Use switch blocks to compare & develop this requirement. Keep this requirement in a subsystem & output of this requirement is a local signal (Signal Name: Vehicle_Turn_Status).

• These are the following requirements for the Requirement_l subsystem and as per these requirements the model is developed in the subsystem.
  •Below image represents developed model of 'Requirement_I' in the subsystem.

 

 

• We see we used two compare to zero blocks and one is mentioned with the ">0° " and the other block is mentioned with the "==0''  condition and as per the requirements the three conditions are given and here the two conditions are only given because if those two conditions are not satisfied automatically the model will follow the thire condition and it will be operated according to the conditions.
  •And here thye constant blocks are given and are assigned with ''Right_ Turn_AngularLimit, 'Left_ Turn_.AngularLimit, & 'Straight_ Drive_ Steering. -Angle' and the input for this subsystem is"'SteeringWheel_ YawDegreelnput and the output is 'Vehicle_Turn_ Status, and the signal lines at the output and input are also resolved and propagated as shown in the below image.

 

 

• And we can also tag our Requirement word file for this subsystem by right clicking on this subsystem and selecting on requirements and the link to word file as shown in the below image.

 

 

Requirement – 2:  Subsystem

Keep this requirement as a separate subsystem. Inputs to this requirement are local signal from requirement 1 (Signal Name: Vehicle_Turn_Status) & an input signal from camera (Signal Name: CameraInput_RoadSign), which confirms the occurrence of a road sign.

Signal Vehicle_Turn_Status is compared against calibration values (Calibration Values: RightTurn_RoadSign, LeftTurn_RoadSign, Straight_RoadSign), if each of them is found equal, then each of the three corresponding output is compared against the camera input signal,

Using a logical operator block, only one among them is finally given as output signal (Signal Name: Vehicle_Direction_Indicator).

• These are the following requirements for the Requirement _2' subsystem and as per these requirements the model is developed in the subsystem.
  •Below image represents developed model of 'Requirement _2' in the subsystem

 

 

• Here there are two input signals first input signal is 'Vehicle_ Turn_ Status and the second input signal is 'Cameralnput_ RoadSign' here we used three relational operators as there are three calibration values and they are 'RightTurn_RoadSign', 'LeftTurn_RoadSign', & 'Straight_ RoadSign' and the Vehicle_ Turn_ Status input is given to the first port of the three rational operators and the calibration values to the second port of the relational operators
• In this system we used three AND gates connected to the relational operators output port and signal from the Cameralnput_ Roadsign because if each of them is found equal, then each of the three corresponding output is
  compared against the camera input signal, only one among them is finally given as output signal " and we used the MUX block and signal conversion block as there are three outputs are coming from the model and they must be connected to the.
• One outport, and as there are three outputs are coming the SLDD data also should be modified and Vehicle_Direction_ Indicator dimensions must be changed to 3 from 1 if not the model advisor will not run and all the signals in this subsytem is also resolved and propagated " and we can also tag our Requirement word file for this subsystem by right clicking on this subsystem and selecting on requirements and the link to word file as shown in the above image for requirement _1 subsystem tagging.

 

 

Modeling Settings:

After finishing the subsystems modeling we should change the solver and code generation settings in the modeling section of the SIMULINK
Now ,first look into the solver setting and the below image shows the solver model settings.

 

 

• Keep solver type as Fixed-step and solver as discrete (no continuous states) and keep fixed step size as 0.01
  •After completing the solver settings go into the code generation settings in the same modeling section of the SIMULINK
  •Now look into the code generation setting and the below image shows the code generation model settings.

 

 

Here , if we select browse option in system target file we will get number of options in that we should select 'ert.tic Embedded coder' and keep remianing as it is and there is no need to change.

 

Model Advisor Check:

• 
  After completing with modeling settings change now we shouls perform the model advisor check fot the whole system
  •Now, look into the model advisor check and the below image shows the selection of model advisor check.

 

 

• We observe there will be a 'model advisor' icon at the top left side of the modeling section and after clicking on that icon we will get hierarchy window in that we should select the vehicle _direction system to perform the check for whole system.

 

 

• After selecting the whole system in hierarchy window then press ok and the we will get check list page and the window is opend as shown in the below image.

 

 

• We should deselect all and we should only select 'modeling standards for MAB' option and with that only all the sub folders are selected for the advisor check.
• 
  MathWorks Advisory Board (MAB) Guidelines are a set of modeling guidelines developed by an independent industry working group for the usage of MATLAB, Simulink, Stateflow and Embedded Coder.
• 
  After selecting a particular MAB folder there will be an option at the top right of the page 'Run selected checks' by clicking it the advisor check will start and the obtained check results are shown in the below image.

 

 

 

• If we observe the summary of the results there is pass, fail, warnings and not run. these are the parameters of the results
  •If we observe my test reults there is no fail cases and warnings are 13 and pass cases are 131 and not run is zero
• Those warnings are not considered, as 10 - 15 warnings are negligible we can avoid them and we should only consider fail cases if any.

 

 

 

C-code generation for the model: 

• After finishing the model advisor check and if there are no fail cases then go to Apps section in the above options ribbion for the process of code generation as shown in the below image.

 

 

• 
  If we press on 'Embedded coder' app in the above apps list then the C Code section will open as shown in the below image

 

 

• In this C Code generation we can see the build block and if we click on that Build block the C Code for the entire model will be generated in C Language>

 

• 
  As we click the build button the C code is generated at the right side window in the SIMULINK page itself and we can observe it in below image.

 

 

 

• See as we discussed the C CODE for the entire model is generated and with this the 'vehicle_ direction _ert_rtw' file is also automatically created in the folder where the model path is existing in the folder in our system.

 

 

• For opening the C CODE in the MATLAB go into the vechile _direction_ert_rtw file and select the .C file which is named as 'vehicle direction.c' and the C CODE of the model is opend in MATLAB.

Below i am inserting the C CODE of the model for the detailed clarification. 

 * File: ert_main.c

 * Code generated for Simulink model 'Vehicle_Direction'.

 * Model version                  : 1.8

 * Simulink Coder version         : 9.3 (R2020a) 18-Nov-2019

 * C/C++ source code generated on : Sun May 15 15:54:17 2022

 * Target selection: ert.tlc

 * Embedded hardware selection: Intel->x86-64 (Windows64)

 * Code generation objectives: Unspecified

 * Validation result: Not run

 

#include

#include               /* This ert_main.c example uses printf/fflush */

#include "Vehicle_Direction.h"         /* Model's header file */

#include "rtwtypes.h"

 

/*

 * Associating rt_OneStep with a real-time clock or interrupt service routine

 * is what makes the generated code "real-time".  The function rt_OneStep is

 * always associated with the base rate of the model.  Subrates are managed

 * by the base rate from inside the generated code.  Enabling/disabling

 * interrupts and floating point context switches are target specific.  This

 * example code indicates where these should take place relative to executing

 * the generated code step function.  Overrun behavior should be tailored to

 * your application needs.  This example simply sets an error status in the

 * real-time model and returns from rt_OneStep.

 */

void rt_OneStep(void);

void rt_OneStep(void)

{

  static boolean_T OverrunFlag = false;

 

  /* Disable interrupts here */

 

  /* Check for overrun */

  if (OverrunFlag) {

    rtmSetErrorStatus(Vehicle_Direction_M, "Overrun");

    return;

  }

 

  OverrunFlag = true;

 

  /* Save FPU context here (if necessary) */

  /* Re-enable timer or interrupt here */

  /* Set model inputs here */

 

  /* Step the model */

  Vehicle_Direction_step();

 

  /* Get model outputs here */

 

  /* Indicate task complete */

  OverrunFlag = false;

 

  /* Disable interrupts here */

  /* Restore FPU context here (if necessary) */

  /* Enable interrupts here */

}

 

/*

 * The example "main" function illustrates what is required by your

 * application code to initialize, execute, and terminate the generated code.

 * Attaching rt_OneStep to a real-time clock is target specific.  This example

 * illustrates how you do this relative to initializing the model.

 */

int_T main(int_T argc, const char *argv[])

{

  /* Unused arguments */

  (void)(argc);

  (void)(argv);

 

  /* Initialize model */

  Vehicle_Direction_initialize();

 

  /* Attach rt_OneStep to a timer or interrupt service routine with

   * period 0.01 seconds (the model's base sample time) here.  The

   * call syntax for rt_OneStep is

   *

   *  rt_OneStep();

   */

  printf("Warning: The simulation will run forever. "

         "Generated ERT main won't simulate model step behavior. "

         "To change this behavior select the 'MAT-file logging' option.\n");

  fflush((NULL));

  while (rtmGetErrorStatus(Vehicle_Direction_M) == (NULL)) {

    /*  Perform other application tasks here */

  }

 

  /* Disable rt_OneStep() here */

 

  /* Terminate model */

  Vehicle_Direction_terminate();

  return 0;

}

 

/*

 * File trailer for generated code.

 *

 * [EOF]

 */

Authorised :

 

 

MIL & SIL Testing for the model :

• 
  Now lets conduct SIL and MIL testing for the obtained model
• 
  MIL Testing :

To create a MIL testing right click on the vehicle_direction subsystem then we will get a window in that select the test harness option and select create for vehicle direction.

 

• And change the inport to signal builder and keep outport as same and no need to change other parameters as shown in below image.

 

 

• And in advanced properties settings keep verification mode as normal for MIL testing and click on OK

 

 

• After clicking OK the basic MIL harness model is created and the signal builder must be modified according to the test case data.

 

• To change signals in signal builder we should import the data from the test case sheet by the procedure shown in the below image.

 

 

• Select the Test_Signals.xlsx from the file exploler which we have made in MS excel  as shown : 

 

 

 

• After importing the TEST signal files click the buttons shown below format :

 

 

 

• After selecting the data from the test case file the signals are arranged in the signal builder block according to the data avilable in the test case and we can observe the signals of signal builder block in the below image.

 

 

• After arranging the signals in signal builder the demux is taken and the outputs are connected to sum block and signal builder output ports are also connected to the sum block and scope - 1 is connected to the sum block three outputs and another scope is also connected before the sum block to observe the difference and we can see the arrangement in the below image.

 

Result: MIL test .

 

• As the time taken in the test case is 4 sec the run time is also for 4 sec and lets see the outputs below.

 

 

• As the model conditions satisfies the output waves are matching with the values of the test case.

 

 

Conclusion : There is no change in the system the expected outputs are generates in scope-2 the scope-1 results are at 0 condition as there is no difference after the sum block.

 

 

SIL Testing :

• 
  To create a SIL testing the model should be treated as a atomic unit so we should change the model as atomic before conducting the SIL testing and it is shown in below image.

 

 

• To create a SIL testing right click on the vehicle_ direction subsystem then we will get a window in that select the test harness option and select create for vehicle_ direction.

 

 

• Change the inport to signal builder and keep outport as same and no need to change other parameters as shown in below image.

 

 

• In advanced properties settings keep verification mode as Software-in-the-loop for SIL testing and click on OK

 

 

• After clicking Ok the basic SIL harness model is created and the signal builder must be modified according to the test case data.

 

 

• To change the signals in signal builder block the procedure is same as in MIL testing.
  • To change signals in signal builder we should import the data from the test case sheet by the same procedure shown in the above image of MIL Testing.

 

 

• After selecting the data from the test case file the signals are arranged in the signal builder block according to the data avilable in the test case and we can observe the signals of signal builder block.

 

• 
  After arranging the signals in signal builder the demux is taken and the outputs are connected to sum block and signal builder output ports are also connected to the sum block and scope - 1 is connected to the sum block three outputs and another scope is also connected before the sum block to observe the difference and we can see the arrangement in the below image.

 

 

Results : For SIL test >

• The time taken in the test case is 4 sec the run time is also for 4 sec and lets see the outputs below

 

 

• The model conditions satisfies the output waves are matching with the values of the test case.

 

 

Conclusion :

• There is no change in the system the expected outputs are generates in scope-2 the scope-1l results are at 0 condition as there is no difference after the sum block.