Merge branch 'main' into 372-feature-extend-the-issue-templates

.github/workflows/build.yml

@@ -88,13 +88,11 @@ jobs:
 
       - name: Save pull request artifact
         if: github.event_name == 'pull_request'
-        env:
-          PR_ID: ${{ github.event.number }}
         run: |
           mkdir -p ./artifact
           printf '{
             "is_pr": true,
-            "pr_id": $PR_ID
+            "pr_id": ${{ github.event.number }}
           }' >> ./artifact/artifact.json
 
       - name: Save merge artifact

doc/dev_talks/paf24/README.md

@@ -9,7 +9,8 @@
 
 - [Mermaid Gantt Chart](./mermaid_paf24.md)
 - [Student Roles](./student_roles.md)
-- [Joker Rules]
+- [Joker Rules](./joker_rules_paf24.md)
+- [Sprint Review Meeting Guidelines](./sprint_review_meeting_guidelines.md)
 
 ## Notes for Sprints
 

doc/dev_talks/paf24/sprint_review_meeting_guidelines.md

@@ -0,0 +1,88 @@
+# Sprint Review Meeting PAF24
+
+**Summary**: This document outlines the process for our sprint review meetings.
+
+- [1. Timeline and Submission Guidelines](#1-timeline-and-submission-guidelines)
+  - [1.1. Pre-Meeting Agenda](#11-pre-meeting-agenda)
+  - [1.2. Meeting Agenda](#12-meeting-agenda)
+- [2. Key Updates](#2-key-updates)
+- [3. Sprint Review Schedule](#3-sprint-review-schedule)
+- [4. Rationale for These Changes](#4-rationale-for-these-changes)
+- [5. Pre-Meeting Checklist](#5-pre-meeting-checklist)
+
+## 1. Timeline and Submission Guidelines
+
+- **Team Configuration**: Work in teams of any size.
+
+### 1.1. Pre-Meeting Agenda
+
+- **Summary Submission**: By **Monday at 11:30 AM** (before the meeting), submit a summary of your work on Digicampus.
+  - TODO A template will be provided.
+  - Upload your document to DigiCampus at [this link](https://digicampus.uni-augsburg.de/dispatch.php/course/files?cid=5b0c38206c78cc03880bc2e71997220f).
+  - Inform us of your group composition and presentation order for our note-taking.
+- **12:00 - 13:30**: Sample Review
+  - Selected students will be reviewed individually, receiving an individual grade separate from the group grade.
+  - A review guideline will be provided in the future.
+- **By 13:30**: Sample Review Feedback
+  - Feedback will be given based on the sample review, allowing you to address any points during your sprint presentation.
+
+### 1.2. Meeting Agenda
+
+- **14:00 - 15:45**: Sprint Presentations
+  - Presenting as a group is recommended for time efficiency.
+  - Not all members need to present; teams can decide on their approach.
+- **15:45**: Grading Discussion and Sprint Planning Refinement
+- **16:30**: Grade Announcement and Feedback
+- **16:50**: Discussion of Your Plan for the Upcoming Sprint
+
+## 2. Key Updates
+
+- The general overview presentation is now removed or partially integrated into the Systems Engineers’ presentation.
+- Grades are assigned based on the group presentation; however, individuals who undergo a sample review may receive a different grade.
+- Presentation time is allocated at **5 minutes per student**:
+  - Example: A team of three has a total of 15 minutes and may allocate time as they see fit.
+  - A unified grade will be given unless individual assessment is warranted.
+- Timeboxing will be strictly enforced: only content shared within the allotted time will be evaluated. Presentations will be stopped at the time limit.
+- TODO The sprint review presentation guideline will be updated.
+
+## 3. Sprint Review Schedule
+
+```mermaid
+gantt
+title Schedule of the Sprint Review on Monday
+dateFormat HH-mm
+axisFormat %H:%M
+tickInterval 15minute
+
+section Before the Meeting
+Text Submission and Group Info: milestone, at, 11-30, 0H
+Sample Review: sr, 12-00, 13-00
+Sample Review Feedback: fb1, 13-00, 30m
+
+section During the Meeting
+Meeting Start: milestone, beginn, 14-00, 0m
+Questions: f, 14-00, 5m
+Group Presentations: p, after f, 100m
+Break: pu, after p, 10m
+Grading Discussion and Sprint Planning: nsp, after pu, 35m
+Feedback: fb2, after nsp, 20m
+Sprint Planning Discussion: spd, after fb2, 25m
+End of Meeting: milestone, ende, 17-15, 0m
+```
+
+## 4. Rationale for These Changes
+
+- To enable individual assessment where feasible.
+- To avoid excessive time requirements, as individual reviews would take approximately 15–20 minutes per student.
+- To keep the meetings on schedule.
+- To track overall project progress.
+- Allow us to provide constructive feedback.
+- Group presentations should allow for a deeper focus on content.
+
+## 5. Pre-Meeting Checklist
+
+- [ ] Submit your "Summary of Work" by 11:30 AM (individual).
+- [ ] Provide group composition details.
+  - [ ] Identify team members.
+- [ ] By 1:30 PM, check if you received individual feedback.
+  - [ ] Consider how to incorporate feedback into your presentation.

doc/development/drive_action.md

@@ -2,19 +2,20 @@
 
 **Summary:** This page explains the GitHub build action we use to evaluate our agent.
 
-- [GitHub actions](#github-actions)
-  - [The drive job](#the-drive-job)
-    - [1. Checkout repository (`actions/checkout@v3`)](#1-checkout-repository-actionscheckoutv3)
-    - [2. Run agent with docker-compose](#2-run-agent-with-docker-compose)
-    - [3. Copy simulation results file out of container](#3-copy-simulation-results-file-out-of-container)
-    - [4. Stop docker-compose stack](#4-stop-docker-compose-stack)
-    - [5. Comment result in pull request `actions/github-script@v6`](#5-comment-result-in-pull-request-actionsgithub-scriptv6)
-  - [Simulation results](#simulation-results)
+- [The drive job](#the-drive-job)
+  - [1. Checkout repository (`actions/checkout@v3`)](#1-checkout-repository-actionscheckoutv3)
+  - [2. Run agent with docker-compose](#2-run-agent-with-docker-compose)
+  - [3. Copy simulation results file out of container](#3-copy-simulation-results-file-out-of-container)
+  - [4. Stop docker-compose stack](#4-stop-docker-compose-stack)
+  - [5. Comment result in pull request `actions/github-script@v6`](#5-comment-result-in-pull-request-actionsgithub-scriptv6)
+- [Simulation results](#simulation-results)
 
 ## The drive job
 
 The `drive` job is executed conditionally on `pull_request`, after the build successfully ran through.
 
+> Warning: Always start the GitHub runner that handles the `drive` action through direct access to the machine. Do not use remote access like `ssh` or `xrdp`.
+
 ### 1. Checkout repository ([`actions/checkout@v3`](https://github.com/actions/checkout))
 
 Same step as in the [build job](#1-checkout-repository--actionscheckoutv3-)

doc/research/paf24/perception/Obstacle_detection.md

@@ -0,0 +1,56 @@
+# 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.
+
+## Object detection
+
+Active sensors:
+
+- Center camera
+- LIDAR
+
+Inactive sensors:
+
+- Cameras: right, left, back
+- Radar
+
+## Distance calculation
+
+- 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.
+
+- The LIDAR sensor may flicker; a higher spin rate of the LIDAR provides fully reconstructed depth images but with lower resolution for the LIDAR points
+
+## Publishing of Outputs
+
+- Class_index
+- Min_X
+- Min_Abs_y
+
+## Dependencies of detected and hit obstacles
+
+- Are all obstacles detected? No
+- Does successful object detection depend on:
+  - Speed of the car?
+  - Size of obstacles?
+  - Type of obstacle?
+  - Dynamic/static obstacle?
+
+-> So far, no dependencies have been found
+
+## 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