Project 1 (Mini Project on Vehicle Direction Detection

Vehicle Direction Detection

Aim:

Distinguishing the course of the vehicle in view of the camera input.and further study (vehicle_Direction_Detection)

General Overview:

Identifying the bearing of the vehicle is one of the significant and different highlights of Autonomous driving and Advanced Driver Assistance Features. This specific sub-element of recognizing the course of the vehicle is distinguishing where the vehicle is taking in light of the camera input.

The camera peruses the street signs and stores them into its memory with exceptional qualities for a left turn, right turn, and straight drive.

Contingent upon where it is taken, the last sign is given to the driver - as a sign in the event that he is driving in the suggested course or not.

Vehicle Direction Determination can likewise be coupled close with highlights like GPS frameworks to distinguish whether the vehicle is arriving at its objective in an improved way.

This sub-component can likewise be utilized alongside Lane Detection, Highway Warning, Ramp Entry/Exit in Wrong Way Detection, and so forth.

The objective 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 is fine.
3. MBD compliant changes, Data Dictionary creation & code generation is added advantage, and that is not the 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.

Requirement – 2:-

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

2: 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 outputs is compared against the camera input signal,

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

Theory

1: The ultimate goal of ADAS feature development is to make our roads safer and better suited for fully autonomous vehicles in the long run.

2: Still, manufacturers and buyers shouldn’t underestimate the importance of ADAS for meeting current automotive challenges.

3: The most significant impact of advanced driver assistance systems is in providing drivers with essential information and automating difficult and repetitive tasks. This increases safety for everyone on the road.

4: ADAS vision systems and ADAS safety systems require lots of fused sensors to monitor the vehicle’s surroundings and what’s going on inside the car.

5: The most commonly used ADAS sensors today are lidar, radar, and ultrasonic. Software for self-driving cars featuring ultrasonic sensors usually consists of multiple sensors located in the front and rear bumpers and side-view mirrors.

5: They transmit short sound waves and measure the time it takes for them to travel to a target object and return to the receiver.

6: An ADAS safety system can rely on ultrasonic sensor technology for low-speed and short-range applications such as blind-spot detection, self-parking, and parking assistance.

7: Radar and lidar are both used by ADAS engineers for object detection, collision prevention, and interaction with traffic management systems.

8: Still, there are differences between these technologies. Lidar is the best solution for real-time detection, but it’s unpleasantly expensive for mass deployment.

9: Radar sensors, especially long-range ones, are reliable enough and cheaper but lack precision when detecting small objects.

This is the main model subsystem that has two inputs SteeringWheel_YawDegreeInput and CameraInput_RoadSign entering into the Vehicle_Direction_Detection subsystem and one output Vehicle_Direction_Indicator. Two requirements are designed in two separate subsystems.

With Harness 1 & 2

Requirement 1 (Setting is not Working for word)

Above is the subsystem for the requirment_1 we need to hide the content preview of the subsystem as per the model-based development guidelines. Inside this subsystem, there is our logic for requirement 1

• Directing wheel input as yaw rate (Signal name: SteeringWheel_YawDegreeInput) is the contribution to this framework.
• This is looked at against 3 rakish qualities, one each for a left turn, right turn, and straight drive (Calibration Values: Right_Turn_AngularLimit, Left_Turn_AngularLimit, Straight_Drive_Steering_Angle) to say which explicit heading the directing wheel is turning towards.
• For looking at guiding wheel input as yaw rate with the alignment upsides of for arrive at left, right, straight drive we utilized the social administrator '==' This is currently contrasted against three rakish qualities with say which explicit heading the directing wheel is turning towards.
• For this situation, the result of the social administrator '==' is equivalent to 1 just when the 'SteeringWheel_YawDegreeInput' matches the adjustment esteem precise cutoff determined in Right_Turn_AngularLimit, Left_Turn_AngularLimit, or Straight_Drive_Steering_Angle. If the upsides of SteeringWheel_YawDegreeInput == Right_Turn_AngularLimit, Left_Turn_AngularLimit, or Straight_Drive_Steering_Anglethen it will show the result in boolean as 1. Three switch blocks are utilized for the if-else explanation.
• To the principal input port (Input 1) of the switch block alignment block is associated and after that to the subsequent info block (input 2) yield from the social administrator, the block is associated it is given as the condition contributed to the switch block. The switch will pass input1 (adjustment esteem) when the condition (input2~=0) condition is fulfilled, else input3 (yield from the following switch block) is passed as a result.
• The sign 'Vehicle_Turn_Status' got at the result of the principal switch will be an alignment precise worth (Right_Turn_AngularLimit OR Left_Turn_AngularLimit, OR Straight_Drive_Steering_Angle). On the off chance that none of the circumstances get satisfied, zero is passed as the output from the last switch. The signal 'Vehicle_Turn_Status' is fed to the outport of subsystem 'Requirement1'.

Requirement_2

Above is the Requirment_2 subsystem inside this subsystem we have the camera input and our requirement 1 logic this is the input for the requirement_2 Subsystem. And Vehicle_Direction_Indicator is the output for this subsystem.

• Keep this prerequisite as a different subsystem. Contributions to this prerequisite are a nearby sign from necessity 1 (Signal Name: Vehicle_Turn_Status) and an info signal from the camera (Signal Name: CameraInput_RoadSign), utilizing the social administrator '==', which affirms the event of a street sign.
• Signal Vehicle_Turn_Status is analyzed against adjustment values (Calibration Values: RightTurn_RoadSign, LeftTurn_RoadSign, Straight_RoadSign), in the event that every one of them is found equivalent, every one of the three relating yields is looked at against the camera input signal.
• which affirms the event of a street sign utilizing AND Operator. Utilizing a legitimate administrator block, only one among them is at last given as a result signal (Signal Name: Vehicle_Direction_Indicator). The boolean result signal got from every one of the three 'AND' blocks is taken care of to the outport 'Vehicle_Direction_Indicator' to demonstrate the vehicle course.
• The result 'Vehicle_Direction_Indicator' will be a three-aspect signal having three boolean components, with the principal component to specify 'Right Turn', the second component to designate 'Left Turn', and the third component to designate 'Straight Drive'.

Requirements Tagging of Simulink Model

Prerequisite Tagging Of Simulink Model:- every one of the necessities are labeled for better understandability, any individual who is surveying the model or who is attempting to refresh the model can find out about what rationale is utilized in the framework. from the necessity director, we can see what are all are labeled and the depiction

1)Firstly I composed all prerequisites in a word document then I select my most memorable necessity then I return to the model choosing my most memorable subsystem to right-tap on it then goto prerequisites and connection to determination in word then my subsystem box is featured and connected. along these lines, I connect my second subsystem with prerequisite 2.

Requirement 1 Tagging with Subsystem 1:- (not Working)

Creation of SLDD:- A Simulink Data Dictionary (SLDD) file is created that contains input, output signals, and calibration parameters used in the model. SLDD file is created by clicking on Modeling, then ‘Model Properties’, then ‘External Data’, and specifying a file name for the Data Dictionary.

After the creation of SLDD, I put all the design data inside it for all the signals.

all the inputs, outputs, and calibration parameters are saved in SLDD so while simulation the model takes all the values and its parameters from the Simulink Data Dictionary.

SIGNAL RESOLUTION FOR INPUT AND OUTPUT:- The inputs and output signals are resolved so the signals will take the values from SLDD and pass them to the logical blocks. Otherwise, it may take some junk values if it is unresolved.

MODEL UPDATE:-

The model update is done by Ctrl-D. this is done to check for any static errors. If no errors are coming the model is working fine without any errors. SIMULATION:- The model is simulated too for checking for errors and warnings. CONFIGURATION PARAMTERS UPDATE:- Various configuration parameters are updated as per the code generation the solver type should be fixed for code generation

By running the model advisor tool, I can see commonly made modeling errors. 1)I go in modeling and click on model advisor then I select by-task in that I select MAB and run selected check I got the following result is pass successfully

MAB Tool is NOt there

CODE GENERATION:_ For a generation of code, I went to the apps tab and after that selected the embedded coder, and finally, build the C Code out of it.

/*
 * Trial License - for use to evaluate programs for possible purchase as
 * an end-user only.
 *
 * File: Subsystem.c
 *
 * Code generated for Simulink model 'Subsystem'.
 *
 * Model version                  : 1.5
 * Simulink Coder version         : 9.5 (R2021a) 14-Nov-2020
 * C/C++ source code generated on : Thu Jun 23 17:44:14 2022
 *
 * Target selection: ert.tlc
 * Embedded hardware selection: Intel->x86-64 (Windows64)
 * Code generation objectives: Unspecified
 * Validation result: Not run
 */

#include "Subsystem.h"
#include "Subsystem_private.h"

/* Exported data definition */

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

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

/* Real-time model */
static RT_MODEL_Subsystem_T Subsystem_M_;
RT_MODEL_Subsystem_T *const Subsystem_M = &Subsystem_M_;

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

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

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

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

  /* End of Outputs for SubSystem: '<Root>/Subsystem' */
}

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

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

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

CONCLUSION:-

I made the model of vehicle heading assurance according to the given necessities and additionally made SLDD for it. All information yield signals are settled and spread, then I check the blunder with the model counselor report I passed in that report, and my code is created effectively. Along these lines, I did my venture and come by result well.