Project 1 (Mini Project on Vehicle Direction Detection

MINI PROJECT :

Aim of the Project :

To identify the direction of the vehicle based on the camera input .

Objective of the 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 is fine .

3. MBD compliant changes , Data Dictionary creation & code generation is added advantage , and that is not scope of this project .

4. If choosing code generation , Storage class for Input signals : ImportedExtern ; Storage class for Output signal : Export to File ; Storage class for local signals : localizable ; Storage class for calibration signals : Const .

5. Choose sample time for all signals as 0.01 .

General Overview :

Vehicle direction examination plays a vital role in several different application . various such application are Driver Assisatnce sysytem , Electronic Toll collection and Intelligent Parking system . Particularly in wrongdoing anticipation and mischance examination this feature cab be an added advantage . Also as to increase the security level for both the driver and the other vehicle running over the road detection of direction of vehicle is an upperhand to avoid any collision or fatality .

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.

For this project there were several steps taken which are as follows :

• Linking of the Simulink Data Dictionary
• Developement of the Desired model
• Configuration Parameter Setting
• Requirement Tagging
• Signal resolving and Signal Propogation
• Model Advisor Report Generation
• C - code generation

Creation of Simulink Data Dictionary :

Signals & Calibration Data List :

Signal / Calibration Name

Signal Type

Data Type

Dimension

Min

Max

Initial Value

Units

Steering Wheel_YawDegreelnput

Input

Int16

1

-180

180

Deg

Cameralnput_RoadSign

Input

Boolean

1

0

1

Vehicle_Turn_Status

Local

Int16

1

-180

180

Deg

Right Turn_AngularLimit

Calibration

Int16

[ 11 ]

-180

180

30

Deg

Left_Turn_AngularLimit

Int16

[ 11 ]

-180

180

-120

Deg

Straight_Drive_Steering_Angle

Calibration

Int16

[ 11 ]

-180

180

0

Deg RightTurn_RoadSign

Calibration

Int16

[ 11 ]

-180

180

30

Left Turn_RoadSign

Calibration

Int16

[ 11 ]

-180

180

-120

Straight RoadSign

Calibration

Int16

[ 11 ]

-180

180

0

Vehicle Direction_Indicator

Output

Boolean

1

0

1

Same has been updated in the Design data of Vehicle_DirectionSLDD.

Development of the Required Model :

As per the objective of the project the model has benn developed :

Requirement - 1 :

• Steering wheel input as yaw rate ( Signal name : Steering Wheel_YawDegreelnput ) 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 compareand compare to constant block & develop this requirement . Keep this requirement in a subsystem & output of this requirement is a local signal ( Signal Name : Vehicle_Turn_Status ) .

Subsystem is developed by the name of requirement which contain following elemenst :

Here the input which is Steering Wheel_YawDegreelnput is applied over the three to relational operator ( which is having equal to operator ) and then correponding output of the relation operator is applied to the control gate of their corresponding switches . And at last the Outport of the subsystem is named as Vehicle_Turn_Status .

Requirement - 2 :

• 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 : Cameralnput_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 ) .

There are two input in this subsystem which are Vehicle_Turn_Status and Cameralnput_RoadSign and these were applied to the relational operator ( equal to ) and logical AND opertaor as shown in the above image . The ouput of those AND gate are applied to the Mux and then through the signal conversion block the output of the subsystem is named as Vehicle Direction_Indictaor .

Configuration Parameter settings :

Solver Type is changed from variable step to Fixed step and Solver type is selected as Discrete ( No continuous state ) and also sample time is declared as 0.01 sec as per the project requirement . Also under the Code generation option selecting embedded real time as system target file ( ert.tlc ) under target selection option .

Requirement Tagging :

A MS Word file is created which contain all the requirements and necessary information to develop the model appropiately . This Word file is tagged for both the subsystem requirementl and Requirement2 respectively .

Similarily requirement tagging of the Requirement2 has been done :

After Selecting Requirement - 2 : from the above option will take us to the MS word file with Requiremt - 2 :

Signal Resolving and Signal Tagging :

All the input signal are resolved at the root level of the model and propogated accordingly .Output signal of Requirement is resolved at the root level and hen propogated.some is done for the output signal of the Requirement 2.

Model Advisor Report Generation :

To generate the report we have to go over the Modelling tab and then there at Extreme left corner there is a option of Model Advisor and selecting Model Advisor in it .It will ask to select the system for which the report generation is to be taken.

Then under the by task option unselecting all the previously selected option and then selecting the modeling standard for MAB there and in the right box there is option to Run selected check and clicking over there will run the selected checks.The result of the Modeling Standard for MAB .Also a HTML report is generated there after by clicking over the option Generate Report.

Model in Loop ( MIL ) Testing

Model in Loop testing is a systematic method to generate test cases from models based on the Requirement Analysis . It used to evaluate requirements independent of algorithm design and development . Model - based testing involves :

1. Creating a model of system requirements for testing

2. Generating test data from this requirements using MIL Testing

• In model - based testing , we use requirement analysis to generate test cases to verify your design .
• This process also helps automate other verification tasks and streamlines the review process by linking test cases and verification objectives to high - level test requirements .
• By building a simulink model we can analyze traceability between requirements , design , generated code , and test .

3. Verifying the design algorithm with generated test cases

• Using Simulink can manage the test cases and systematically execute them to confirm that your design meets requirements .
• code coverage metrics to assess the completeness of the MIL testing which can identify the missing requirements and functionalities .

Procedure for MIL Testing by generating a test Harness file :

The block parameters of creation of test harness are set as below

Source - Signal Builder

Sink - Output

Harness Creation options - Normal mode as verification mode.

Other parameters are set to inheritly,by setting the above parameters , a Test Harness file is created for MIL Testing.Fix the errors displayed by Diagnostic viewer and also check model advisor tool.

Build a new model of Test Harness now we open signal builder block and inport the excel data file. Now we take 3 sum block and connect to subsystem output and signal builder output line and all 3 sum block output line connect to a scope. A other scope connect to subsystem output and check the actua output result.

Test Harness Output :

The scope is used to plot the Left_Turn , Head_Straight and Right_turn form Vehicle Direction_Indicator to show how the system is responding to the inputs After building the simulink model in order to determine the correctness of the model which is build a Model In Loop Testing is done first with the defined functional test cases . If the result found satisfactory then it is send to further higher stages for Software in Loop Testing and Hardware in Loop Testing . Here in this model our Aim is to generate a code not to do SIL Testing .

Code Generation :

The code generation is made by going over the app tab and selecting the Embedded Coder .Now clicking over the build option will create the C code .

Code :

/*
 * File: Vehicle_Direction.c
 *
 * Code generated for Simulink model 'Vehicle_Direction'.
 *
 * Model version                  : 1.5
 * Simulink Coder version         : 9.7 (R2022a) 13-Nov-2021
 * C/C++ source code generated on : Mon Jun 13 14:42:49 2022
 *
 * Target selection: ert.tlc
 * Embedded hardware selection: Intel->x86-64 (Windows64)
 * Code generation objectives: Unspecified
 * Validation result: Not run
 */

#include "Vehicle_Direction.h"
#include "rtwtypes.h"
#include "Vehicle_Direction_private.h"

/* Exported data definition */

/* Definition for custom storage class: ExportToFile */
boolean_T Vehicle_Direction_Indicator[3];/* '/Signal Conversion' */

/* Const memory section */
/* Definition for custom storage class: Const */
const int16_T LeftTurn_RoadSign = -120;/* Referenced by: '/Constant1' */
const int16_T Left_Turn_AngularLimit = -120;/* Referenced by: '/Constant1' */
const int16_T RightTurn_RoadSign = 30; /* Referenced by: '/Constant' */
const int16_T Right_Turn_AngularLimit = 30;/* Referenced by: '/Constant' */
const int16_T Straight_Drive_Steering_Angle = 0;/* Referenced by: '/Constant2' */
const int16_T Straight_RoadSign = 0;   /* Referenced by: '/Constant2' */

/* Real-time model */
static RT_MODEL_Vehicle_Direction_T Vehicle_Direction_M_;
RT_MODEL_Vehicle_Direction_T *const Vehicle_Direction_M = &Vehicle_Direction_M_;

/* Model step function */
void Vehicle_Direction_step(void)
{
  /* local block i/o variables */
  int16_T Vehicle_Turn_Status;

  /* Outputs for Atomic SubSystem: '/Vehicle_Direction' */
  /* Switch: '/Switch' incorporates:
   *  Constant: '/Constant'
   *  Constant: '/Constant'
   *  Inport: '/SteeringWheel_YawDegreeInput'
   *  RelationalOperator: '/Compare'
   *  RelationalOperator: '/Compare'
   *  Switch: '/Switch1'
   */
  if (SteeringWheel_YawDegreeInput > 0) {
    /* Switch: '/Switch' incorporates:
     *  Constant: '/Constant'
     */
    Vehicle_Turn_Status = Right_Turn_AngularLimit;
  } else if (SteeringWheel_YawDegreeInput == 0) {
    /* Switch: '/Switch1' incorporates:
     *  Constant: '/Constant2'
     *  Switch: '/Switch'
     */
    Vehicle_Turn_Status = Straight_Drive_Steering_Angle;
  } else {
    /* Switch: '/Switch' incorporates:
     *  Constant: '/Constant1'
     *  Switch: '/Switch1'
     */
    Vehicle_Turn_Status = Left_Turn_AngularLimit;
  }

  /* End of Switch: '/Switch' */

  /* SignalConversion: '/Signal Conversion' incorporates:
   *  Constant: '/Constant'
   *  Constant: '/Constant1'
   *  Constant: '/Constant2'
   *  Inport: '/CameraInput_RoadSign'
   *  Logic: '/AND'
   *  Logic: '/AND1'
   *  Logic: '/AND2'
   *  RelationalOperator: '/Relational Operator'
   *  RelationalOperator: '/Relational Operator1'
   *  RelationalOperator: '/Relational Operator2'
   */
  Vehicle_Direction_Indicator[0] = ((Vehicle_Turn_Status == RightTurn_RoadSign) &&
    CameraInput_RoadSign);
  Vehicle_Direction_Indicator[1] = ((Vehicle_Turn_Status == LeftTurn_RoadSign) &&
    CameraInput_RoadSign);
  Vehicle_Direction_Indicator[2] = ((Vehicle_Turn_Status == Straight_RoadSign) &&
    CameraInput_RoadSign);

  /* End of Outputs for SubSystem: '/Vehicle_Direction' */
}

/* Model initialize function */
void Vehicle_Direction_initialize(void)
{
  /* (no initialization code required) */
}

/* Model terminate function */
void Vehicle_Direction_terminate(void)
{
  /* (no terminate code required) */
}

/*
 * File trailer for generated code.
 *
 * [EOF]
 */

Justification :

• This simulink model is based on vehicle direction of car.this model have three subsystem ( vehicle direction , requirement1 , requirement2 ) .requireme based on ' else if ' model , either road sign is right turn then RightTurn_AngularLimit showing as output.and requirement2 subsystem show the output is Right Turn_RoadSign .
• when Road sign is left then LeftTurn _AngularLimit is output.otherwise car show the StraightDrive as output.Requirement2 block show the vehicle turn status . camera catch the road sign give the operating blocks ( AND gate ) .as inupt show the output sign .