Project 1 (Mini Project on Vehicle Direction Detection

MINI PROJECT-VEHICAL DIRECTION DETERMINITATION

Aim:

• Development of MATLAB Simulink model as per requirement.

• Tag the requirements to the simulink model; tagging requirement 1 & requirement 2 to their corresponding subsystems is fine.
• MBD compliant changes, Data Dictionary creation & code generation is added advantage, and that is not the scope of this project.
• 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.
• Choose sample time for all signals as 0.01s

General Overview :

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 the 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 & the output of this requirement is a local signal (Signal Name: Vehicle_Turn_Status).

Requirement – 2:

• Keep this requirement as a separate subsystem. Inputs to this requirement are a local signal from requirement 1 (Signal Name: Vehicle_Turn_Status) & an input signal from the 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).

• 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	-	-

  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 the vehicle is identifying the direction the vehicle is taking based on the camera input.

  The camera reads the road signs & stores them into its memory with unique values for the left turn, right turn & straight drive. Depending on the direction it is taking, the 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 alongside 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.

  PROCEDURE:

1. The first step in building the model is the understand the requirements and select the right blocks. We will be building a subsystem satisfying the Requirement-1 objectives. We give an input named 'SteeringWheel_YawDegreeInput' which is nothing but the yaw rate of the steering wheel. This value will be compared with 3 angular values for the left turn, right turn, and straight drive to say which specific direction the steering wheel is turning towards and we use the switch blocks to achieve this. This subsystem is shown below.

From the above image, we can see that the yaw rate input is compared with the 'Right_Turn_AngularLimit' which is 30. If the input is equal to or greater than 30, then the Right-Turn value will be passed. If not the output of the second switch will be passed. Now, if the input is less than 30, it passes to the second switch condition, here if the input is not equal to 0, then the Left_Turn value is passed, or else the Straight_Drive value will be passed.

2. We will now build a subsystem satisfying the Requirement-2 objectives. The output of the first subsystem 'Vehicle_Turn_Status' is given as an input along with the 'CameraInput_RoadSign' to the second subsystem. First, the 'Vehicle_Turn_Status' will be compared with calibration values RightTurn_RoadSign, LeftTurn_RoadSign, Straight_RoadSign using the 'compare to constant blocks'. The output of each of these comparison values will go through logical operators 'AND' which will give us the final output called the 'Vehicle_Direction_Indicator'. The subsystem is shown below.

From the above image, we can see that the input from the previous subsystem will be compared with 3 'compare to constant blocks' and the output of which will be compared with the camera input using the logical operators. The AND signal will give us the selected output required and it will be collected using the 'Mux' block. The output can be displayed using the display block.

The final model of the 'Vehicle_Direction_Detection' is shown below.

3. The second objective of the project is to, tag the requirements in the model with the requirement datasheet. We have created an MS word document containing both the 2 requirements as shown below.

Requirement-1: Steering Wheel Action Logic

• 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 the left turn, right turn & straight drive (Calibration value: Right_Turn_AngularLimit ,Left_Turn_AngularLimit, Straight_Drive_Steering_Angle) to say which specific direction the steering wheel is turning towards.
• Use switch block to compare & develop this requirement.Keep this requirement in a subsystem & output of this requirement is a local signal(Signal Name: Vehical_Turn_Status).

Requirement-2:Vehical Direction Detection Logic

• Keep this requirement as a separate sub system. Inputs to this requirement are a local signal from requirement 1 (Signal Name: CameraInput_RoadSign), Which confirms the occurrence of a road sign.
• Signal Vehical_Turn_Status is compared against calibration Value: 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 logical operator block , only one among them is finally given as output signal (Signal Name :Vehical_Direction_ Indicator).

Now, we select the statement that needs to be linked and right-click on the required subsystem shown below. Go to requirements and then click on the 'Link to selection in Word'. A new .slmx file will be created in the path selected and the links will be stored in that file.

The subsystems tagged with their requirements are shown below.

Requirement - 1 is tagged with the Steering_Wheel_Action_Logic subsystem as shown below.

Requirement - 2 is tagged with the Vehicle_Direction_Detection_Logic subsystem as shown below.

4. Now, we need to create an SLDD file for the same model. The table consisting of all the details regarding the signals and calibration values is given above. We need to first link the model to a data dictionary. We create a new file as shown below.

We then open the link and add the given input, output signals and then add the calibration values. The Data dictionary created for the model is shown below.

Now that the SLDD file has been created, we can resolve the signal name to the Simulink signal object as shown below.

Doing this will allow the model to take the signal values during the simulation. The signal is shown below.

We do the same for all the required signals before running the simulation.

5. Now, we generate a code for the model which can help us generate an S-function block which is helpful in the testing of the model. We first change the format of the model from grt. tlc to ert. tlc as shown in the image below.

Now, we can go to the 'APPS' tab and click on the 'Build' option to generate code and model to get our C-code for the Vehicle_Direction_Detection model. The code is shown below.

>> /*
* File: ert_main.c
*
* Code generated for Simulink model 'Vehicle_Direction_Determination'.
*
* Model version : 1.29
* Simulink Coder version : 9.3 (R2020a) 18-Nov-2019
* C/C++ source code generated on : Fri Oct 15 19:58:02 2021
*
* 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_Determination.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_Determinat_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_Determination_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_Determination_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_Determinat_M) == (NULL)) {
/* Perform other application tasks here */
}

/* Disable rt_OneStep() here */

/* Terminate model */
Vehicle_Direction_Determination_terminate();
return 0;
}

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

With this, we can simulate the model and verify the results. The results are shown below.

RESULTS-

1. Right-Turn

The initial value of the signal 'SteeringWheel_YawDegreeInput' is given as 30 (value for the right turn) as shown below.

The initial value of the signal 'CameraInput_RoadSign' is given as 1 (To confirm the right turn of the vehicle) as shown below.

2. Left-Turn

The initial value of the signal 'SteeringWheel_YawDegreeInput' is given as -120 (value for the left turn) as shown below.

We will keep the value of 'CameraInput_RoadSign' as 1 to confirm the left turn of the vehicle.

3. Straight Drive

The initial value of the signal 'SteeringWheel_YawDegreeInput' is given as 0 (value for the straight drive) as shown below.

The initial value of the signal 'CameraInput_RoadSign' is given as 1 (To confirm the right turn of the vehicle) as shown below.

We will keep the value of 'CameraInput_RoadSign' as 1 to confirm the straight drive of the vehicle.

4. Negative Result -

All the above results confirm the working of the model. We will now see the result when the camera input negates the steering yaw rate. We will input the initial value for 'SteeringWheel_YawDegreeInput' as 30 and then input the value of 'CameraInput_Road negate the decision which is shown below.

With this, we can say that the Vehicle Direction Detection model has been created as per the requirements.

CONCLUSION -

We have created a model as per the requirements, requirement tagging has been done accordingly. The C code has been generated and the report has been attached. With this, we can say that the Vehicle Direction Detection has been successfully created.