Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

490 remodel acc concept #516

Merged
merged 13 commits into from
Dec 5, 2024
Binary file added doc/assets/research_assets/ACC_FLC_Example_1.PNG
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
85 changes: 85 additions & 0 deletions doc/research/paf24/planning/ACC.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# ACC

## General
The main goal of an ACC (Adaptive Cruise Control) is to follow a car driving in front while keeping a safe distance to it. This can be achieved by adjusting the speed to the speed of the car in front.
In general, classic ACC systems are designed for higher velocity (e.g. > 40 km/h). Apart from that, there are Stop & Go systems that support lower velocites (e.g. < 40 km/h). In our case, both systems might be needed and it might be reasonable to develop two different systems for ACC and Stop & Go.
Vroni27 marked this conversation as resolved.
Show resolved Hide resolved
There are basically three different techniques that can be used to implement an ACC: PID Control, Model Predictive Control and Fuzzy Logic Control. Another option is CACC (Cooperative Adaptive Cruise Control) but this is not relevant for our project since it requires communication between the vehicles.

### PID Control

### Model Predictive Control (MPC)
It calculates the current control action by solving an online, iterative and finite-horizon optimization of the model.
Procedure:
1. Prediction of future system states based on current states
2. Computation of the cost function for a finite time horizon in the future
3. Implementation of the first step of the solved control sequence
4. Application of the feedback control loop to compensate for the predictive error and model inaccuracy
5. Sampling of new current states and repitition of the process

### Fuzzy Logic Control (FLC)
Provides a unified control framework to offer both functions: ACC and Stop & Go.


![Example of a FLC control algorithm](../../../assets/research_assets/ACC_FLC_Example_1.png)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me this link does not work. This might be the github preview however.
Maybe this image should also be directly included.
Especially because here some formula symbols are explained.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can I embed an image directly?

Vroni27 marked this conversation as resolved.
Show resolved Hide resolved

## Discussion

- When should the ACC be used? Only when driving straight forward?
- How to test adaptations of the ACC? Create test scenarios?
- Which output should be transfered to the Acting component? Only the desired speed?
- Which input do we get from the Perception component? The distance and velocity of the car in front?

Vroni27 marked this conversation as resolved.
Show resolved Hide resolved
Vroni27 marked this conversation as resolved.
Show resolved Hide resolved
## ACC Algorithm

### Current implementation

- General behaviour:
checks for obstacle distance < safety distance

calculates new speed based on obstacle distance

else keep current speed

- publishes speed to acc_velocity
- safe distance calculation is currently not correct, uses speed + (speed * 0.36)² which results in wrong distances
- if car in front of us ignores speed limits we ignore them as well
Vroni27 marked this conversation as resolved.
Show resolved Hide resolved
- some parts of unstuck routine are in ACC and need to be refactored
- same goes for publishing of current waypoint, this should not be in ACC

Vroni27 marked this conversation as resolved.
Show resolved Hide resolved
Comment on lines +54 to +58
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Critical: Address safety distance calculation and architectural issues

Several critical issues require immediate attention:

  1. Safety distance calculation is incorrect and unsafe
  2. Component responsibilities are mixed:
    • Unstuck routine in ACC
    • Waypoint publishing in ACC

Proposed actions:

  1. Create a dedicated SafetyDistance class with physics-based calculations
  2. Move unstuck routine to a behavior module
  3. Implement waypoint management in planning component
  4. Add comprehensive unit tests

Would you like me to help draft the SafetyDistance class implementation?

In summary, the current implementation is not sufficient and needs major refactoring.

### Concept for new implementation

The new concept for the ACC is to take the trajectory, look at all or a limited subset of the next points and add a target velocity and the current behaviour to each point.
This way the Acting has more knowledge about what the car is doing and can adjust accordingly in a local manner.
For this a new trajectory message type was implemented in #511.

![trajectoryMsg](https://github.com/user-attachments/assets/0b452f1a-4c60-45b2-882f-3a50118c9cb9)
Vroni27 marked this conversation as resolved.
Show resolved Hide resolved

Since behaviour is passed as an ID a new enum for behaviours was implemented in utils.py as well.
Vroni27 marked this conversation as resolved.
Show resolved Hide resolved

The general idea for speeds above the 40 km/h mark is to calculate a proper safety distance and a general target velocity. For speeds lower than that a stop and go system needs to be discussed.

For safety distance the old approach can simply be modified. For example, (speed / 10)*3 + (speed / 10)² is a well known formula for calculating the braking distance.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

⚠️ Potential issue

The proposed safety distance formula needs revision based on existing implementation

The proposed formula (speed / 10)*3 + (speed / 10)² differs significantly from the current validated implementation in the codebase. The existing implementation in utils.py uses:

  • Reaction distance = speed
  • Braking distance = (speed * 0.36)²
  • Total safety distance = reaction_distance + braking_distance

The proposed formula would result in less conservative safety margins compared to the existing implementation, which could compromise safety. Stick with the current implementation as it:

  1. Separates reaction distance and braking distance components
  2. Has been tested in the CARLA simulator environment
  3. Includes an emergency braking mode with adjusted calculations
🔗 Analysis chain

Validate the proposed safety distance formula.

The proposed formula (speed / 10)*3 + (speed / 10)² for braking distance should be:

  1. Validated against industry standards
  2. Include additional safety margin
  3. Consider road conditions and vehicle capabilities
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any existing safety distance calculations in the codebase
rg "safety.*distance|braking.*distance" --type cpp --type python

Length of output: 97


Script:

#!/bin/bash
# Search for any existing safety distance calculations in the codebase with correct file extensions
rg "safety.*distance|braking.*distance" -t cpp -t py

# Also search for general distance calculations that might be safety-related
rg "calculateDistance|getDistance|distance.*calculation" -t cpp -t py

# Look for files that might contain safety-related calculations
fd -e cpp -e hpp -e py -e h | grep -i "safety\|distance\|brake"

Length of output: 1159


Script:

#!/bin/bash
# Let's examine the actual implementation of safety distance calculation
cat code/planning/src/local_planner/utils.py

Length of output: 7921

🧰 Tools
🪛 LanguageTool

[uncategorized] ~63-~63: Possible missing comma found.
Context: ...stem needs to be discussed. For safety distance the old approach can simply be modified...

(AI_HYDRA_LEO_MISSING_COMMA)


[style] ~63-~63: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...he old approach can simply be modified. For example, (speed / 10)*3 + (speed / 10)²...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[uncategorized] ~63-~63: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...le, (speed / 10)*3 + (speed / 10)² is a well known formula for calculating the braking dis...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


For a general speed target we need to take the speed and the speed of the car in front into account. In cases where the car in front is substantially slower than the speed limit ACC could inititate overtaking.

With the general speed target and the current distance to the car in front we can calculate the target velocity for each point in the trajectory up to the car in front for example by interpolation. Points further that that will be inititalized with the speed limit at that position.

Vroni27 marked this conversation as resolved.
Show resolved Hide resolved
### Possible next steps
A seperate file for the new ACC should be created to not disturb the system.

The parts that might get cut from ACC like current waypoint and unstuck routine need to be evaluated for necessity and if need be moved to somewhere more fitting.

Implement publisher for new message type.

Start implementing safety distance and general target speed logic. Subscriber logic could be taken from old implementation.

### Requirements:
- obstacle speed
- obstacle distance
Comment on lines +103 to +104
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Expand system requirements with specific metrics

The requirements section needs quantitative metrics:

  1. Obstacle Detection:
    • Detection range
    • Speed measurement accuracy
    • Position accuracy
    • Update rate
  2. System Performance:
    • Control loop frequency
    • Response time
    • Speed control accuracy
  3. Safety Requirements:
    • Minimum time gap
    • Maximum deceleration
    • Fail-safe behavior

Would you like me to help draft detailed requirements specifications?


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Expand requirements section with specific criteria.

The requirements section needs significant expansion to include:

  1. Safety requirements (minimum safe distances, maximum deceleration rates)
  2. Performance requirements (response times, accuracy)
  3. System constraints (sensor limitations, processing delays)
  4. Integration requirements with other systems
🧰 Tools
🪛 Markdownlint (0.35.0)

78-78: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


78-78: Punctuation: ':'
Trailing punctuation in heading

(MD026, no-trailing-punctuation)


79-79: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)



## Sources
https://www.researchgate.net/publication/335934496_Adaptive_Cruise_Control_Strategies_Implemented_on_Experimental_Vehicles_A_Review
Loading