Project 1 (Mini Project on Vehicle Direction Detection

Vehicle Direction Detection:

In this mini-project, we have to develop a Matlab Simulink model for Vehicle Direction Detection.

Overview:

Identifying the direction of the vehicle is one of the important and diverse features in Autonomous driving and Advance 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 and stores them into its memory with unique values for a left turn, right turn, and 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.

Advanced Driver Assistance Systems (ADAS):

Advanced driver assistance systems (ADAS) are groups of electronic technologies that assist drivers in driving and parking functions. Through a safe human-machine interface, ADAS increase car and road safety. ADAS use automated technology, such as sensors and cameras, to detect nearby obstacles or driver errors, and respond accordingly. As most road accidents occur due to human error, ADAS are developed to automate, adapt, and enhance vehicle technology for safety and better driving. ADAS is proven to reduce road fatalities by minimizing human error. Safety features are designed to avoid accidents and collisions by offering technologies that alert the driver to problems, implementing safeguards, and taking control of the vehicle if necessary. Adaptive features may automate lighting, provide adaptive cruise control, assist in avoiding collisions, incorporate satellite navigation and traffic warnings, alert drivers to possible obstacles, assist in lane departure and lane centering, provide navigational assistance through smartphones, and provide other features.

Concept, History, and Development:

ADAS was first being used in the 1950s with the adoption of the anti-lock braking system. Early ADAS include electronic stability control, anti-lock brakes, blind spot information systems, lane departure warning, adaptive cruise control, and traction control. These systems can be affected by mechanical alignment adjustments or damage from a collision. This has led many manufacturers to require automatic resets for these systems after a mechanical alignment is performed.

Technical concepts

The reliance on data that describes the outside environment of the vehicle, compared to internal data, differentiates ADAS from driver-assistance systems (DAS). ADAS relies on inputs from multiple data sources, including automotive imaging, Lidar, Radar, image processing, computer vision, and in-car networking. Additional inputs are possible from other sources separate from the primary vehicle platform, including other vehicles (Vehicle-to-Vehicle or V2V communication) and infrastructure (Vehicle-to-Infrastructure or V2I communication). Modern cars have ADAS integrated into their electronics; manufacturers can add these new features. ADAS are considered real-time systems since they react quickly to multiple inputs and prioritize the incoming information to prevent accidents. The systems use preemptive priority scheduling to organize which task needs to be done first. The incorrect assignment of these priorities is what can cause more harm than good.

ADAS levels

ADAS are categorized into different levels based on the amount of automation, and the scale provided by The Society of Automotive Engineers (SAE). ADAS can be divided into five levels. In level 0, ADAS cannot control the car and can only provide information for the driver to interpret on their own. Some ADAS that are considered level 0 are: parking sensors, surround-view, traffic sign recognition, lane departure warning, night vision, blind spot information system, rear-cross traffic alert, and forward-collision warning. Levels 1 and 2 are very similar in that they both have the driver do most of the decision-making. The difference is level 1 can take control over one functionality and level 2 can take control over multiple to aid the driver. ADAS that are considered level 1 are: adaptive cruise control, emergency brake assist, automatic emergency brake assist, lane-keeping, and lane centering. ADAS that are considered level 2 are: highway assist, autonomous obstacle avoidance, and autonomous parking. From level 3 to 5, the vehicle's amount of control increases; level 5 is where the vehicle is fully autonomous. Some of these systems have not yet been fully embedded in commercial vehicles. For instance, highway chauffeur is a Level 3 system, and automatic valet parking is a level 4 system, both of which are not in full commercial use yet. In this mini-project, we are developing a Simulink model of Vehicle direction detection, a feature of ADAS. Here, in the model, we are comparing the inputs from the steering wheel and camera input. Input from the steering wheel means that if we have to turn right, we rotate the steering wheel to the right side. The input from the steering wheel is taken as yaw rate as a yaw rotation is a movement around the yaw axis of a rigid body that changes the direction it is pointing to the left or right of its direction of motion. A car's yaw rate or yaw velocity is the angular velocity of this rotation or rate of change of the heading angle when the aircraft is horizontal. It is commonly measured in degrees per second or radians per second. The yaw rate value determines how many degrees the vehicle has turned to either right or left. This value is compared with the image of the roadsigns captured by the camera which is present in front of the car. So, our model compares these two inputs and the result of the comparison is shown or displayed to the user.

Steps For Requirement-I:

• Create input as steering wheel yaw (inport) name as SteeringWheel_YawDegreeInput.
• Then by using switch blocks in Simulink, we use them to connect inputs Right_Turn_AngularLimit, Left_Turn_AngularLimit, and Straight_Drive_Steering_Angle. The switch blocks are used for comparing the steering wheel yaw input and the angle limits of the right turn, left turn, and straight drive instead of using the relational operators.
• Finally, the output from the switch block is named the Vehicle_Turn_Status (Outport).
• Then convert the schematic diagram into a subsystem block.

Given below in figure (1) is the schematic diagram for requirement-I.

Steps for Requirement-II:

• Here, according to requirement-II, we have to create two inputs namely, Vehicle_Turn_Status (Inport) and CameraInput_RoadSign (Inport).
• Now we have to check the input values pass to the right, left, and straight so we use the relational operator for comparing the Vehicle_Turn_Status value with the corresponding CameraInput_RoadSign and connect to a logical operator (OR) and connect to the final output block.
• We need only one output result for the entire system, so we use the mux block to convert as one result output while changing the values.
• Then we convert the whole schematic diagram into a subsystem block.

Given below in figure (2) is the schematic diagram for requirement-II.

Now as per requirement-I and requirement-II, the input is SteeringWheel_YawDegreeInput and CameraInput_RoadSign at the top level and the output is Vehicle_Direction_Indicator. Figure (3) shows the final model for Vehicle Direction Determination.

Simulink Data Dictionary:

A data dictionary is a persistent repository of data that is relevant to our model. We can also use the base workspace to store design data that are used by our model during simulation. However, a data dictionary provides more capabilities. The dictionary stores design data, which define parameters and signals, and includes data that define the behavior of the model. The dictionary does not store simulation data, which are inputs or outputs of model simulation that enter and exit Inport and Outport blocks.

Steps for creating Simulink Data Dictionary (SLDD):

1. In the Simulink window, click on the option Modeling as shown in figure (4).
2. In the Modeling option, click on the option Link to Data Dictionary. This is shown in figure (5).
3. After clicking on Link to Data Dictionary, a dialog box appears. In the External section, click on the option New for creating a new SLDD as shown in figure (6).
4. A new window will appear for entering data to the SLDD. For adding signals or parameters, go to the Add option, or for signals and parameters, direct options are provided on the window itself as shown in figure (7).
5. Now we can add signals and parameters. Change the signal and parameter data as per the requirement given in the project. The final view of the SLDD after adding all the signals and parameters is shown in figure (8).

Requirement Tagging:

All the requirements are tagged for better understandability, anyone who is reviewing the model or who is trying to update the model can get a clear idea of what logic is used in the system. From the requirement manager, we can see what are all tagged and the description. This is shown in figure (9). For linking the requirement document, which is in a word document, follows the following steps:

• As we all know, we have created a requirement in a word document as per the given requirements in the problem statement.
• Then we right-click on the top-level of the model as shown in figure (10). Then click on the option Requirements>Link to Selection in Word.
• For linking the requirement documents we need to open the word document and select the word which is to be linked which the name should be the same as the block diagram which is shown in figure (11).

The following figures (12), (13), and (14) show the requirement tagging process.

The model advisor report is also attached below after applying coverage settings as shown in figures (15), (16), and (17).

Configuration Parameter Update:

Various configuration parameters are updated as per the code generation the solver type should be fixed for code generation. The sample time for the system is updated as per the project objective and this is shown in figure (18). Figure (19) and (20) shows the screenshot of the model advisor report being generated.

Conclusion:

The Vehicle Direction Detection model has been created with the help of a requirement document and the Simulink data dictionary was created and the model advisor report has been attached.