Vehicle Direction Detection

Title: Mini Project on Vehicle Direction Detection

Aim:

• Development of a Vehicle Direction Detection model in Simulink based on the provided requirement specification document.
• The project only deals with model development.
• All the model subsystems have been correspondingly tagged with their requirement specification document.
• Creation of Simulink Data dictionary and linking it to the model.

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 basically 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 a 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.

Model Development:

For this model, we have taken two Input ports and one output port which is connected to the main system. This is the top layer of the model. From the requirement specification we have taken the inputs and outputs with the following parameters:

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_Direction_Indicator	Output	Boolean	1	0	1	-	-

So, based on the above inputs, I have made the below subsystem. In encapsulates all the other requirements inside it. All the requirements are tagged with their corresponding requirement Id, wherever required. Signals have been resolved at the top level.

Figure 1: Top Layer of the model

Requirement Tagging:

Figure 2: Requirement Tagging

Under the top layer:

Figure 3: Vehicle Direction Detection

For this layer, we have simply propagated the signal from the top layer and then these signals are used as input for the shown subsystems, i.e., Vehicle_Yaw_Calc and Indicator_Logic.

The arrangement is solely based on requirement 1 and requirement 2 for the above-mentioned blocks respectively.

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

Based on these mentioned requirements, I have developed the below subsystem called Vehicle_Yaw_Calc.

Figure 4: Vehicle_Yaw_Calc

In this block, the SteeringWheel_YawDegreeInput value is first checked for a non-zero value. So, if the value is not zero the value of Left_Turn_AngularLimit is passed through the switch block else the value of Straight_Drive_Steering_Angle passes.

The value of SteeringWheel_YawDegreeInput is then again checked if its greater than 30(equal to Right_Turn_AngularLimit). So, if the value exceeds this, then Right_Turn_AngularLimit is passed through the switch block else Left_Turn_AngularLimit/ Straight_Drive_Steering_Angle passes.

Signal / Calibration Name	Signal Type	Data Type	Dimension	Min	Max	Initial Value	Units
Vehicle_Turn_Status	Local	Int16	1	-180	180	-	Deg

This is then stored in a Localizable storage class variable called as Vehicle_Turn_Status.

The output signal is resolved at the deepest layer of the model.

Other Signals used in the subsystems are:

Signal / Calibration Name	Signal Type	Data Type	Dimension	Min	Max	Initial Value	Units
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

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

Based on the above requirements following block has been developed called as Indicator_Logic.

Figure 5: Indicator_Logic

In the above model, the Vehicle_Turn_Status from the previous and the CameraInput_RoadSign have been taken as input.

The value of Vehicle_Turn_Status is then checked for equality with the calibration parameters given in the requirement document.

Parameters have been described below:

Signal / Calibration Name	Signal Type	Data Type	Dimension	Min	Max	Initial Value	Units
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

These values are checked using a compare to constant block and the output is then checked with CameraInput_RoadSign using AND logical operator. So, if Both the values are 1, the AND logical operator outputs 1. The same operation is done for all the other road signs as well. So, the output will give 1, if any of the values turns 1. The output is obtained through the Vehicle_Direction_Indicator.

Simulink Data Dictionary:

To store the data, a Simulink Data Dictionary is created in .sldd format. All the input signal and output signal as well as the local and calibration parameters have been stored in the same .sldd file.

The variables that have been discussed in the earlier part of this report, only those parameters have been used in the model.

Below is the screenshot of the .sldd file.

Figure 5: .sldd file screenshot

Conclusion:

The above model is ready for the further stages of the V-Cycle development. The model can be tested for MIL and SIL by creating a test harness for the model using the functional test cases or by using Simulink built-in Test Harness feature. The same testbed can be used for both the MIL and SIL. To further the process of Model-Based Development, this model is ready for auto code generation and this code can then be used to create the final production-level software for the above-mentioned feature.

The model successfully depicts the behavior of a direction detection module and can be implemented on a vehicle after successful testing.