Project 1 (Mini Project on Vehicle Direction Detection

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.

Objective of Mini 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.01s

Model Development:

The main model outer view is shown above. As per the model development requirement, this model contains two subsystems namely requirement1 and requirement2 inside the vehicle_direction subsystem.

Requirement-Tagging:

Once the subsystem is created and named, the requirement tagging is done. Usually the requirement document is a word file and the rule is to keep both the word document and the '.slx model in the same folder. This is because if the document and the model are not inside the same folder then the requirement tagging can not be done and will show error.

1. Open the word file highlight the Requirement section that needs to be tagged. Only one requirement can be tagged per subsystem to avoid confusion.

2. Rename the subsystem. Right click on the subsystem ---->requirements--->link to selection on word. And the block turns yellow. The same steps are carried out for Requirement-2 tagging.

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).

As told in the document the input to the system is from SteeringWheel_YawDegreeInput and the ouput is named as Vehicle_Turn_Status .

The model uses if-elseif logic to satisfy the requirement.

(Calibration Values: Right_Turn_AngularLimit, Left_Turn_AngularLimit, Straight_Drive_Steering_Angle)

1. The input is given to relational operation block where it compares the values of SteeringWheel_YawDegreeInput against the calibration values individually.
2. The logic is that the vehicle can have only one input at the time: either right turn or left turn or straight drive, so to implement this logic switch blocks are used.
3. Only when the condition is true in relational operation block and it output 1 then that particular switch is activated and it checks for the limit value.
4. If the condition is true then the input given to the first port is sent to the output else the false conditon is executed and the value in the false condition is sent to the output port.

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

Logic:

The input is said to be a local signal or localized input when it is present inbetween two blocks. i.e. output for a block and input for another block. Here the localised input it the Vehicle_Turn_Status. This input is calibrated against the values RightTurn_RoadSign, LeftTurn_RoadSign, and Straight_RoadSign and output is given to the AND logic along with the CameraInput_RoadSign. When both the inputs are 1 the AND logic outputs the value 1 and this is sorted by mux and given to the ouput.

The signal copy or signal conversion block is kept to retain the signal obtained by the mux to the output port.

Now since the model is made the inputs for the model should be given to make the model run and check if it is of correct logic. The signal naming and other properties of the inputs can be specified in sldd(simulink data dictionary).

SIMULINK DATA DICTIONARY:

In model based designing the most important part is creating a sldd file. This is actually similar to how we declare variables in model and base workspace. But the workspace only provide declarations. Unlike initialisation in workspace we can define data related parameters in sldd file and save it. This can be transfered to another model by having the model file and sldd file under the same path directory.

How to access sldd?

To create a sldd for first time or access previously stored files go to modelling--->link to data dictionary, a pop up will be appear as shown below.

click on External data tab the message displayed above appears. To create a new sldd file use New option or click on browse to access previously created files. When either of these steps are completed the file name is displayed below, disable the model access to base workspace and procedd with the confirmation button. By doing this it links the model and the data dictionary.

In general the model explorer will be opened. We can also see that there is external data name on the model hierarchy box with a different icon. This is where we are going to create out sldd file for different types of inputs.

Signals & Calibration Data List:

Signal / Calibration Name	Signal Type	Data Type	Dimension	Min	Max	Initial Value	Units
SteeringWheel_YawDegreeInput	Input	Int16	1	-180	180	-	Deg
CameraInput_RoadSign	Input	Boolean	1	0	1	-	-
Vehicle_Turn_Status	Local	Int16	1	-180	180	-	Deg
Right_Turn_AngularLimit	Calibration	Int16	[1 1]	-180	180	30	Deg
Left_Turn_AngularLimit	Calibration	Int16	[1 1]	-180	180	-120	Deg
Straight_Drive_Steering_Angle	Calibration	Int16	[1 1]	-180	180	0	Deg
RightTurn_RoadSign	Calibration	Int16	[1 1]	-180	180	30
LeftTurn_RoadSign	Calibration	Int16	[1 1]	-180	180	-120
Straight_RoadSign	Calibration	Int16	[1 1]	-180	180	0
Vehicle_Direction_Indicator	Output	Boolean	1	0	1	-	-

Access sldd: click on modelling tab--->design dropdown---->link to data dictionary.

The properties window will pop-up, external data--->new--->name the file--->save--->add path

uncheck the 'enable model access to base workspace'.

This opens the model explorer and provides a space to create these variables for the model.

The sldd file is attached below for reference. Each data differ based on type property their behavioural output. To add inputs in the model explorer on the tool strip click on the icons highlighted below or select Add and from the drop down select the required input. The main point to be noted is to check for the values of resolution, storage class. The resolution reduces the complex calculation errors when prioritized. In case we have to multiply different decimal pointed numbers when having high resolution helps to reduce the error in the answer and gives precise values after decimal point. On the other hand the storage class plays a vital role in code generation, since the file format given there will be used to group those files under the same class and object, when this is not specified properly the model may through an error/ warning or the accuracy of the model itself will be reduced. For complex modelling it is always advised to have resolution and storage class.

Case-i: signal type and boolean data type

The signal is of boolean data type hence the minimum and maximum values can be only 0 and 1. Every detail of the signal is filled according to the requirement and the storage class is given as 'ImportedExtern' since its an input value.

Case-ii: signal type and boolean output data type:

The same steps are followed as discussed in the case-i but when the signal is an output signal it needs to be associated with the header and the definition file. Any names can be given to the header file and the extension should be "filename.h". Similarly for the definition file it is "filename.c". By doing this all the signals and the variables will be grouped under the given file names and easy to access or it might not be classified properly and model might throw an error.

Case-iii Localizable type

The signals as mentioned earlier when it is present inbetween two systems of the entire model it is said to be localizable signal. The steps to define the signal is same as case-i , this need not need header and definition files. The storage class should be selected as localizable.

This goes the same for constant values Every detail of the constant is filled according to the requirement and the storage class is given as 'const' since its an input value.

By doing this we have defined our sldd for the model. Now the model can have their block names and signal names along with the values fed to it by signal resolving and propagation.

Signal Resolving:

Resolving a signal is to ensure that the signal is present in the model and included in the sldd file so that it contains all the values when propogated to other blocks and subsystems.

• Right click on the required signal---->give signal name --->check 'signal name must resolve to simulink signal object' and apply the changes to your model.

you will get the symbol and the signal name on the line as shown below. This process is called signal resolving.

Resolving a signal needs to be done whenever the signal appears for the first time in the model. The resolved signals of out model are: SteeringWheel_YawDegreeInput, CameraInput_RoadSign, Vehicle_Turn_Status, Vehicle_Direction_Indicator.

An error message may pop up or the block will remain in red color highlighted outline when the inputs are not mentioned in the sldd file.

Signal Propagation:

Once the signal is resolved the same value needs to be carried or preserved through out the model when the same input is given to different system, so to carry the signal as the same propagation is used.

To do propagation : right click on signal line--->properties---->check on 'show propagated signals'--->ok.

The propagated signals are shown below :

All the signals that are first resolved are then propogated in the model based designing.

Configuration paramters required to be changed for the model as shown below to generate the c code using the embedded coder.

By default grt.tlc will be present as the target file change it to ert.tlc file as shown below

The toolchain is choosen based one the requirement either auto or specific compiler to build the code.

After the changes are made the model is saved and runned.

MODEL ADVISOR CHECK:

This is done to know if the model is built correctly or not. This have certain guidelines for our models and checks if those are satisfied . Once the advisor check is cleared your model is ready for code generation.

go to Modelling tab--->model advisor (the pop-up shown below appears.)

Once the system is selected the next window opens:

The modelling standards under the "by task" option is checked and the model runs for the selected checks. The following report is generated.

After the model is simulated without any error go to apps--->embedded c coder click on build.

The code is generated for the model along with the header and definition files we created using the sldd.

/*
 * File: vehicle_direction.c
 *
 * Code generated for Simulink model 'vehicle_direction'.
 *
 * Model version                  : 1.13
 * Simulink Coder version         : 9.5 (R2021a) 14-Nov-2020
 * C/C++ source code generated on : Fri Jan 14 01:41:53 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 "vehicle_direction_private.h"

/* 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;

  /* Switch: '<S2>/Switch' incorporates:
   *  Constant: '<S2>/Constant'
   *  Constant: '<S2>/Constant1'
   *  Constant: '<S2>/Constant2'
   *  Inport: '<Root>/SteeringWheel_YawDegreeInput'
   *  RelationalOperator: '<S2>/Relational Operator'
   *  RelationalOperator: '<S2>/Relational Operator1'
   *  RelationalOperator: '<S2>/Relational Operator2'
   *  Switch: '<S2>/Switch1'
   *  Switch: '<S2>/Switch2'
   */
  if (SteeringWheel_YawDegreeInput == Right_Turn_AngularLimit) {
    /* Switch: '<S2>/Switch' incorporates:
     *  Constant: '<S2>/Constant3'
     */
    Vehicle_Turn_Status = Right_Turn_AngularLimit;
  } else if (SteeringWheel_YawDegreeInput == Left_Turn_AngularLimit) {
    /* Switch: '<S2>/Switch1' incorporates:
     *  Constant: '<S2>/Constant4'
     *  Switch: '<S2>/Switch'
     */
    Vehicle_Turn_Status = Left_Turn_AngularLimit;
  } else if (SteeringWheel_YawDegreeInput == Straight_Drive_Steering_Angle) {
    /* Switch: '<S2>/Switch2' incorporates:
     *  Constant: '<S2>/Constant5'
     *  Switch: '<S2>/Switch'
     *  Switch: '<S2>/Switch1'
     */
    Vehicle_Turn_Status = Straight_Drive_Steering_Angle;
  } else {
    /* Switch: '<S2>/Switch' incorporates:
     *  Constant: '<S2>/Constant6'
     *  Switch: '<S2>/Switch1'
     *  Switch: '<S2>/Switch2'
     */
    Vehicle_Turn_Status = 0;
  }

  /* End of Switch: '<S2>/Switch' */

  /* SignalConversion: '<S3>/Signal Conversion' incorporates:
   *  Constant: '<S3>/Constant'
   *  Constant: '<S3>/Constant1'
   *  Constant: '<S3>/Constant2'
   *  Inport: '<Root>/CameraInput_RoadSign'
   *  Logic: '<S3>/AND'
   *  Logic: '<S3>/AND1'
   *  Logic: '<S3>/AND2'
   *  RelationalOperator: '<S3>/Relational Operator'
   *  RelationalOperator: '<S3>/Relational Operator1'
   *  RelationalOperator: '<S3>/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);
}

/* 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]
 */
 */

Conclusion: Thus the model is read and built according to the requirement document. Model simulated without any errors and the code is built for the model from the embedded coder and displayed.