Challenge

Project 2 Adaptive Cruise Control

VVineela Mathangi2 Sept 2023

MATLAB

ANS:

AIM OF THE PROJECT:

To develop an Adaptive Cruise Control feature as per the Requirement Document using MATLAB Simulink.

SOFTWARE USED:

MATLAB 2023a Version.

STEP-1:REQUIREMENT ANALYSIS

In this project we have three requirements.

Requirement 1– Lead Vehicle:

Lead Vehicle is a vehicle which is driving in the road ahead of our drive vehicle. Two input signals (Signal Name: CameraInput_LeadVehicle & RadarInput_LeadVehicle).
Ideally sensor fusion techniques will be deployed to process & analyze data from camera & radar. For complexity reasons, let’s not adapt to any such algorithms.
We can simply add both the radar & camera inputs & the corresponding output is read as Speed profile output (Signal Name: LeadVehicle_Speed).
Speed data of the lead vehicle is critical in implementing the Adaptive Cruise Control algorithm.

Requirement 2 – Drive Vehicle:

Drive Vehicle is the vehicle driven by the user & this is the vehicle which has ACC algorithm in it.
Like the Lead Vehicle, Drive Vehicle algorithm also has 2 input signals (Signal Name: CameraInput_DriveVehicle, RadarInput_DriveVehicle) & one signal coming as an Input to this subsystem (Signal Name: Acceleration_Mode) – three inputs into this requirement in total.
Like the above requirement, sensor fusion techniques will also be deployed here, for complexity reasons we are ignoring them.
Two output signals come from this subsystem (Signal Name: DriveVehicle_Speed & LeadVehicle_Detected).
Signal DriveVehicle_Speed is summation of three input signals mentioned above & LeadVehicle_Detected is renamed from Input Signal RadarInput_DriveVehicle by mere use of Signal Conversion block.

Requirement 3 – Adaptive Cruise Control Algorithm:

Adaptive Cruise Control feature has 3 major modes of operation: OFF Mode, STANDBY Mode & ON Mode. This particular requirement has to be implemented as state machine logic in Simulink.
The input signals to this state machine system are (Signal Name: Time_Gap, Set_Speed, Set_Gap, CruiseSwitch, SetSwitch).
Also, the output signals (Signal Name: DriveVehicle_Speed & LeadVehicle_Detected) from requirement-2 is fed back as an input signal into this state machine block.
Additionally, output signal (Signal Name: LeadVehicle_Speed) from requirement-1 is given as an input signal to this state machine block as well.
Output from this subsystem is a signal (Signal Name: Acceleration_Mode) which governs the vehicular speed of the drive vehicle which automatically adjusts its speed & velocity to match the lead vehicle.

Requirement 3a – ACC OFF MODE state logic:

This is the default state inside state machine logic. Output signal Acceleration_Mode is at value 0 in this state.
This state is governed by input signal CruiseSwitch.
If CruiseSwitch is equal to 1, state ACC STANDBY mode will get activated. If CruiseSwitch is equal to 0, state ACC OFF mode will get activated, from either ACC ON mode or ACC STANDBY mode

Requirement 3b – ACC STANDBY MODE state logic:

This is the second activated state inside state machine logic. Output signal Acceleration_Mode is at value 1 in this state.
This state is governed by both input signals CruiseSwitch & SetSwitch.
If CruiseSwitch is equal to 1, state ACC STANDBY mode will get activated. If CruiseSwitch is equal to 0, state ACC OFF mode will get activated, from either ACC ON mode or ACC STANDBY mode
If SetSwitch is equal to 1, state ACC ON mode will get activated. If SetSwitch is equal to 0, state ACC STANDBY mode will get activated.

Requirement 3c – ACC ON MODE state logic:

This state will be activated when input signal SetSwitch is equal to 1. There are 6 sub states to this state logic: They are:

LeadVehicle_Detected_Follow (Default)
LeadVehicle_Not_Detected
LeadVehicle_Detected_Resume
LeadVehicle_Not_Detected_Resume
LeadVehicle_Speed_lessthan_Set_Speed
LeadVehicle_Speed_equal_Set_Speed

Requirement 3c (i) – LeadVehicle_Detected_Follow (ACC ON MODE):

This is the default sub state inside ACC ON MODE state. Output signal Acceleration_Mode is equal to 2.
Condition to transit from LeadVehicle_Detected_Follow to LeadVehicle_Not_Detected; Input signal condition LeadVehicle_Detected == 0.
Condition to transit from LeadVehicle_Detected_Follow to LeadVehicle_Speed_lessthan_Set_Speed; Input Signals condition (LeadVehicle_Detected == 1) && (LeadVehicle_Speed < Set>.

Requirement 3c (ii) – LeadVehicle_Not_Detected (ACC ON MODE):

Output signal Acceleration_Mode is equal to 1.
Condition to transit from LeadVehicle_Not_Detected to LeadVehicle_Detected_Follow; Input signals condition [(LeadVehicle_Detected==1) && (DriveVehicle_Speed == Set_Speed) && (LeadVehicle_Speed >= Set_Speed) && (Time_Gap >= Set_Gap)]
Condition to transit from LeadVehicle_Not_Detected to LeadVehicle_Speed_lessthan_Set_Speed; Input signals condition [(LeadVehicle_Detected == 1) && (LeadVehicle_Speed < Set>

Requirement 3c (iii) – LeadVehicle_Detected_Resume (ACC ON MODE):

Output signal Acceleration_Mode is equal to 3.
Condition to transit from LeadVehicle_Detected_Resume to LeadVehicle_Detected_Follow; Input signals condition [(DriveVehicle_Speed == Set_Speed) && (LeadVehicle_Speed >= Set_Speed) && (Time_Gap >= Set_Gap)]
Condition to transit from LeadVehicle_Detected_Resume to LeadVehicle_Not_Detected_Resume; Input signal condition LeadVehicle_Detected==0.
Condition to transit from LeadVehicle_Detected_Resume to LeadVehicle_Speed_equal_Set_Speed; Input Signal condition [(DriveVehicle_Speed < Set> DriveVehicle_Speed) && (Time_Gap >= Set_Gap)]

Requirement 3c (iv) - LeadVehicle_Not_Detected_Resume (ACC ON MODE):

Output signal Acceleration_Mode is equal to 1.

Requirement 3c (v) - LeadVehicle_Speed_lessthan_Set_Speed (ACC ON MODE):

Output signal Acceleration_Mode is equal to 4.
Condition to transit from LeadVehicle_Speed_lessthan_Set_Speed to LeadVehicle_Not_Detected; Input signal condition [(LeadVehicle_Detected == 0) && (DriveVehicle_Speed == Set_Speed)]
Condition to transit from LeadVehicle_Speed_lessthan_Set_Speed to LeadVehicle_Speed_equal_Set_Speed; Input signals condition [((LeadVehicle_Speed*1.25>=DriveVehicle_Speed) && (LeadVehicle_Speed * 0.75<=DriveVehicle_Speed)) && (DriveVehicle_Speed < Set Time_Gap<=1.25*Set_Gap)>=0.75*Set_Gap))]

Requirement 3c (vi) - LeadVehicle_Speed_equal_Set_Speed (ACC ON MODE):

Output signal Acceleration_Mode is equal to 5.
Condition to transit from LeadVehicle_Speed_equal_Set_Speed to LeadVehicle_Not_Detected_Resume; Input signal conditions is [(LeadVehicle_Detected == 0) || (DriveVehicle_Speed <= Set_Speed)]
Condition to transit from LeadVehicle_Speed_equal_Set_Speed to LeadVehicle_Detected_Resume; Input signal conditions [(DriveVehicle_Speed < Set> DriveVehicle_Speed) || (Time_Gap >= Set_Gap)]
Condition to transit from LeadVehicle_Speed_equal_Set_Speed to LeadVehicle_Speed_lessthan_Set_Speed; Input signals conditions [(LeadVehicle_Speed

Signals & Calibration Data List:

Signal / Calibration Name	Signal Type	Data Type	Dimension	Min	Max	Initial Value	Units
CameraInput_LeadVehicle	Input	Uint8	1	0	255	-	-
RadarInput_LeadVehicle	Input	Uint8	1	0	255	-	-
CameraInput_DriveVehicle	Input	Uint8	1	0	255	-	-
RadarInput_DriveVehicle	Input	Uint8	1	0	255	-	-
Time_Gap	Input	Uint8	1	0	255	-	-
Set_Speed	Input	Uint8	1	0	255	-	-
Set_Gap	Input	Uint8	1	0	255	-	-
CruiseSwitch	Input	Boolean	1	0	1	-	-
SetSwitch	Input	Boolean	1	0	1	-	-
Acceleration_Mode	Output	Uint8	1	0	255	-	-
LeadVehicle_Speed	Output	Uint8	1	0	255	-	-
DriveVehicle_Speed	Output	Uint8	1	0	255	-	-
LeadVehicle_Detected	Output	Uint8	1	0	255	-	-

STEP-2: MODEL DEVELOPMENT

This is the main model of the system:

We have three subsystems namely: 1.Drive vehicle,2.Lead Vehicle, 3. ACC Algorithm

1.Lead Vehicle:

Requirement 1– Lead Vehicle:

Lead Vehicle is a vehicle which is driving in the road ahead of our drive vehicle. Two input signals (Signal Name: CameraInput_LeadVehicle & RadarInput_LeadVehicle).
Ideally sensor fusion techniques will be deployed to process & analyze data from camera & radar. For complexity reasons, let’s not adapt to any such algorithms.
We can simply add both the radar & camera inputs & the corresponding output is read as Speed profile output (Signal Name: LeadVehicle_Speed).
Speed data of the lead vehicle is critical in implementing the Adaptive Cruise Control algorithm.

2.Drive Vehicle:

Requirement 2 – Drive Vehicle:

Drive Vehicle is the vehicle driven by the user & this is the vehicle which has ACC algorithm in it.
Like the Lead Vehicle, Drive Vehicle algorithm also has 2 input signals (Signal Name: CameraInput_DriveVehicle, RadarInput_DriveVehicle) & one signal coming as an Input to this subsystem (Signal Name: Acceleration_Mode) – three inputs into this requirement in total.
Like the above requirement, sensor fusion techniques will also be deployed here, for complexity reasons we are ignoring them.
Two output signals come from this subsystem (Signal Name: DriveVehicle_Speed & LeadVehicle_Detected).
Signal DriveVehicle_Speed is summation of three input signals mentioned above & LeadVehicle_Detected is renamed from Input Signal RadarInput_DriveVehicle by mere use of Signal Conversion block.

The model looks like below,

3. ACC Algorithm:

Adaptive Cruise control feature has 3 major modes of operation: OFF Mode, STANDBY Mode & ON Mode. This particular requirement has to be implemented as state machine logic in Simulink.
The input signals to this state machine system are (Signal Name: Time_Gap, Set_Speed, Set_Gap, CruiseSwitch, SetSwitch).
Also, the output signals (Signal Name: DriveVehicle_Speed & LeadVehicle_Detected) from requirement-2 is fed back as an input signal into this state machine block.
Additionally, output signal (Signal Name: LeadVehicle_Speed) from requirement-1 is given as an input signal to this state machine block as well.
Output from this subsystem is a signal (Signal Name: Acceleration_Mode) which governs the vehicular speed of the drive vehicle which automatically adjusts its speed & velocity to match the lead vehicle.

This is the main chart, subsystem-3:

STEP-3: CREATION OF SLDD (SIMULINK DATA DICTIONARY).

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

->After creating of SLDD file link the SLDD file with model.

STEP-4: SIGNAL RESOLVING & RESOLUTION:

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.

STEP-5: MODEL UPDATE:-

The model update is done by Ctrl-D. this is dne to check for any static errors. if there are no errord coming the model is working fine without any erros.

STEP-6: CONFIGURATION PARAMETERS UPDATE:

Various configuration parameters are updated as per the code generation the solver type should be fix for code generation.

STEP-7: REQUIREMENT TAGGING:

All the requirements are tagged in order 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 are tagged and the description.

In thi smodel we have 3 requirement tagging.

STEP-8:MODEL ADVISOR CHECKS:

By runnning the model advisr tool, we can see commonly mode modelling errors.

STEP-9: CODE GENERATION:

Build model for generating code. click on build to generate code.

CODE:-

CODE GENERATION:

* Event Support License -- for demonstration use and event support. Not

* for government, research, commercial, or other organizational use.

* File: ert_main.c

* Code generated for Simulink model 'Adaptive_cruise_cntrl'.

* Model version : 1.45

* Simulink Coder version : 9.9 (R2023a) 19-Nov-2022

* C/C++ source code generated on : Sat Sep 2 15:42:41 2023

* Target selection: ert.tlc

* Embedded hardware selection: Intel->x86-64 (Windows64)

* Code generation objectives: Unspecified

* Validation result: Not run

#include

#include /* This example main program uses printf/fflush */

#include "Adaptive_cruise_cntrl.h" /* Model header file */

* 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(Adaptive_cruise_cntrl_M, "Overrun");

return;

}

OverrunFlag = true;

/* Save FPU context here (if necessary) */

/* Re-enable timer or interrupt here */

/* Set model inputs here */

/* Step the model */

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

Adaptive_cruise_cntrl_initialize();

/* Attach rt_OneStep to a timer or interrupt service routine with

* period 0.01 seconds (base rate of the model) 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(Adaptive_cruise_cntrl_M) == (NULL)) {

/* Perform application tasks here */

}

/* Terminate model */

Adaptive_cruise_cntrl_terminate();

return 0;

}

* File trailer for generated code.

* [EOF]

RESULT:

The adaptive cruise cntrol is modelled as per the requirement, all the signals are defined in Simulink data dictionary. All input and output signals are resolved and propagated. Updated the model to check for static errors. Run the model advisor tool to see any errors. since there are no errors in Model Advisor Report. Code has been generated using Embedded Coder.

Conclusin:

Hence, The Adaptive Cruise Control feature is developed as per the Requirement Document using MATLAB Simulink.

Project 2 Adaptive Cruise Control

Ship work like this
in your own course.

Talk to a career counsellor

Ship work like thisin your own course.

Talk to a career counsellor

Ship work like this
in your own course.