374 Research: Why does the car hit obstacles #409
Conversation
WalkthroughThe document Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
doc/research/paf24/perception/Obstacle_detection.md (1)
1-9: Fix Markdown formatting issues in the document header section.The document structure is good, but there are some formatting issues to address:
-# Research: Why does the car hit obstacles +# Research: Why does the car hit obstacles? + ## Summary of current obstacle detection in perception -: - [Object detection](#Object-detection) - [Distance calculation](#Distance-calculation) - [Publishing of Outputs](#Publishing-of-Outputs) + For more details, please refer to the current documentation.🧰 Tools
🪛 Markdownlint
3-3: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
3-3: Punctuation: ':'
Trailing punctuation in heading(MD026, no-trailing-punctuation)
4-4: null
Lists should be surrounded by blank lines(MD032, blanks-around-lists)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
doc/research/paf24/perception/Obstacle_detection.md(1 hunks)
🧰 Additional context used
🪛 Markdownlint
doc/research/paf24/perception/Obstacle_detection.md
37-37: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
38-38: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
39-39: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
40-40: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
22-22: Expected: 0 or 2; Actual: 1
Trailing spaces
(MD009, no-trailing-spaces)
23-23: Expected: 0 or 2; Actual: 1
Trailing spaces
(MD009, no-trailing-spaces)
3-3: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines
(MD022, blanks-around-headings)
10-10: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines
(MD022, blanks-around-headings)
19-19: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines
(MD022, blanks-around-headings)
28-28: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines
(MD022, blanks-around-headings)
3-3: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
10-10: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
28-28: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
33-33: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
42-42: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
4-4: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
12-12: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
16-16: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
20-20: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
29-29: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
🔇 Additional comments (3)
doc/research/paf24/perception/Obstacle_detection.md (3)
10-18: Clarify sensor classification and capabilities.
The distinction between "active" and "inactive" sensors needs more context:
- Why are certain sensors classified as inactive?
- What are the implications of this classification for obstacle detection?
- What are the specific capabilities and limitations of each sensor type?
This information is crucial for understanding the system's detection capabilities and potential blind spots.
🧰 Tools
🪛 Markdownlint
10-10: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines
(MD022, blanks-around-headings)
10-10: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
12-12: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
16-16: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
19-27: Address critical safety implications in distance calculation.
Several concerning issues need further investigation:
- The use of "infinity" for missing distance values could be dangerous. Consider:
- How does the control system handle these infinity values?
- What fallback mechanisms exist?
- The LIDAR flickering issue presents a significant safety risk:
- What is the minimum acceptable resolution?
- How frequently does flickering occur?
- Are there compensatory mechanisms in place?
Would you like me to help create a detailed test plan to validate these scenarios?
🧰 Tools
🪛 Markdownlint
22-22: Expected: 0 or 2; Actual: 1
Trailing spaces
(MD009, no-trailing-spaces)
23-23: Expected: 0 or 2; Actual: 1
Trailing spaces
(MD009, no-trailing-spaces)
19-19: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines
(MD022, blanks-around-headings)
20-20: null
Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
33-41: Verify independence claims with empirical data.
The document states that obstacle detection is independent of:
- Vehicle speed
- Obstacle size
- Obstacle type
- Dynamic/static nature
These claims seem counterintuitive and need validation. For example:
- Higher speeds typically affect sensor data quality
- Smaller obstacles are generally harder to detect
- Moving obstacles present different detection challenges
Please provide:
- Test data supporting these independence claims
- Detection success rates under various conditions
- Confidence intervals for each scenario
Also fix the list indentation:
- Are all obstacles detected? No
- Does successful object detection depend on:
- - Speed of the car? No
- - Size of obstacles? No
- - Type of obstacle? No
- - Dynamic/static obstacle? No
+ - Speed of the car? No
+ - Size of obstacles? No
+ - Type of obstacle? No
+ - Dynamic/static obstacle? No🧰 Tools
🪛 Markdownlint
37-37: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
38-38: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
39-39: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
40-40: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
33-33: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
| ## Important aspects found during research: | ||
|
|
||
| - Sometimes objects are not detected (sometimes e.g.: cyclists, construction site signs, open car doors) | ||
| - Most object that are hit are detected | ||
| - Sometimes distance calculation is incorrect (distance is set to infinity just before the collision) | ||
| - Distance in x is alway > ~0.5 (is that a problem?), sometimes distance to a collided car is greater than the distance to a parked car on the side of the road | ||
| - Significant issues in dead-end situations: -> 1.2 seconds of reversing -> the car often immediately collides with the obstacle again |
There was a problem hiding this comment.
Critical safety issues require immediate attention and mitigation strategies.
The research findings reveal several serious safety concerns:
-
Undetected Objects:
- Cyclists and construction signs being missed is a critical safety issue
- Need to specify detection success rate and conditions
-
Distance Calculation Issues:
- The minimum distance of ~0.5m needs investigation
- Incorrect infinity values before collision indicate a systemic problem
- Inconsistent distance measurements could lead to accidents
-
Dead-end Behavior:
- The 1.2-second reverse-and-collide cycle indicates a fundamental logic issue
- Need to implement proper obstacle avoidance strategy
Consider:
- Implementing redundant detection systems for critical objects (cyclists, construction elements)
- Adding safety margins to distance calculations
- Developing a more sophisticated reversing strategy with proper obstacle tracking
- Adding sensor fusion to improve reliability
Would you like assistance in designing specific test scenarios or mitigation strategies for these issues?
🧰 Tools
🪛 Markdownlint
42-42: Punctuation: ':'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
…/github.com/una-auxme/paf into 374-research-why-does-the-car-hit-obstacles
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (1)
doc/research/paf24/perception/Obstacle_detection.md (1)
1-10: Consider adding research methodology details.The document would benefit from additional context about:
- Research timeframe and conditions
- Test scenarios conducted
- Data collection methods
- Success criteria used
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
doc/research/paf24/perception/Obstacle_detection.md(1 hunks)
🔇 Additional comments (1)
doc/research/paf24/perception/Obstacle_detection.md (1)
13-21: Clarify sensor activation status and capabilities.
Please provide:
- Reasons why certain sensors are inactive
- Impact of inactive sensors on detection capabilities
- Whether activating additional sensors could improve detection reliability
This is particularly important given the detection issues mentioned later in the document. Consider implementing sensor fusion to improve reliability.
| - The vision_node receives depth-images from the lidar_distance_node for the specified camera angle | ||
|
|
||
| - According to the distance-to-objects documentation, the LIDAR sensor's 3D values are projected onto a 2D image that matches the exact dimensions of the camera image. | ||
| Numpy formulas are used to reconstruct the depth image, with distances in meters represented as pixel values (grayscale image). | ||
| If no distance is found in the depth image, “infinity” is returned for this bounding box. | ||
|
|
There was a problem hiding this comment.
Critical: Address distance calculation reliability issues.
The current implementation has several concerning aspects:
- Returning "infinity" when no distance is found could lead to unsafe behavior
- No mention of error handling or fallback mechanisms
- No validation of depth image reconstruction accuracy
Consider implementing:
- Bounded distance values instead of infinity
- Confidence scores for distance measurements
- Error handling for missing or invalid depth data
| - Sometimes objects are not detected (sometimes e.g.: cyclists, construction site signs, open car doors) | ||
| - Most objects that are hit are detected | ||
| - Sometimes distance calculation is incorrect (distance is set to infinity just before the collision) | ||
| - Distance in x is alway > ~0.5 (is that a problem?), sometimes distance to a collided car is greater than the distance to a parked car on the side of the road | ||
| - Significant issues in dead-end situations: -> 1.2 seconds of reversing -> the car often immediately collides with the obstacle again |
There was a problem hiding this comment.
Urgent: Implement specific technical mitigations for identified issues.
The research has identified critical safety issues that require immediate technical solutions:
-
For undetected objects (cyclists, construction signs):
- Implement redundant detection methods
- Add specific detection models for vulnerable road users
- Consider adding object persistence tracking
-
For distance calculation issues:
- Investigate the 0.5m minimum distance limitation
- Implement sanity checks for distance values
- Add temporal smoothing of distance measurements
-
For dead-end behavior:
- Implement a proper state machine for reversing
- Add obstacle memory to prevent repeated collisions
- Consider path planning with multiple waypoints
Would you like assistance in designing specific implementations for any of these solutions?
| ## Important aspects found during research | ||
|
|
||
| - Sometimes objects are not detected (sometimes e.g.: cyclists, construction site signs, open car doors) | ||
| - Most objects that are hit are detected | ||
| - Sometimes distance calculation is incorrect (distance is set to infinity just before the collision) | ||
| - Distance in x is alway > ~0.5 (is that a problem?), sometimes distance to a collided car is greater than the distance to a parked car on the side of the road | ||
| - Significant issues in dead-end situations: -> 1.2 seconds of reversing -> the car often immediately collides with the obstacle again |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Document mitigation strategies and timeline.
While the research findings are valuable, the document should be expanded to include:
- Prioritized list of issues based on safety impact
- Proposed technical solutions for each issue
- Implementation timeline and milestones
- Success criteria for validating fixes
This will help track progress and ensure all critical issues are addressed systematically.
Description
Provides a quick overview of the current object detection and some issues related to collisions with obstacles
Fixes # (374)
Type of change
Please delete options that are not relevant.
Does this PR introduce a breaking change?
No
Most important changes
changes file /doc/research/paf24/perception/Obstacle_detection.md
Checklist:
Summary by CodeRabbit
Obstacle_detection.mddocument to provide a structured overview of obstacle detection methodologies in vehicle perception systems.