Merge branch 'main' into 420-feature-execute-catkin_make-on-docker-co…

…mpose-up

.github/ISSUE_TEMPLATE/BUG.yml

@@ -1,24 +1,74 @@
 name: 🐞 Bug
 title: "[Bug]: "
-description: Something doesn't behave as it should.
+description: A bug that requires attention.
 labels: ["bug"]
 body:
   - type: textarea
     id: current
     attributes:
       label: Current Behavior
-      placeholder: The car doesnt see a traffic light on Map1.
+      description: Describe the current, unexpected behavior.
+      placeholder: The car doesn’t detect the traffic light on Map1.
 
   - type: textarea
     id: expected
     attributes:
       label: Expected Behavior
-      placeholder: The car does see the traffic light on Map1.
+      description: Describe the expected, correct behavior.
+      placeholder: The car should detect the traffic light on Map1.
 
   - type: textarea
     id: reproduce
     attributes:
-      label: How to reproduce the issue
+      label: Steps to Reproduce
+      description: Provide steps to reproduce the issue.
       placeholder: |
-        * Start the simulation with Map1 
-        * after 600m the car won't stop at the traffic light.
+        * Start simulation on Map1.
+        * After 600m, the car should stop at the traffic light.
+
+  - type: textarea
+    id: definition_of_done
+    attributes:
+      label: Definition of Done
+      description: Criteria to consider this issue resolved.
+      placeholder: |
+        - The car detects traffic lights on Map1 correctly.
+        - The issue no longer occurs in similar scenarios.
+
+  - type: input
+    id: effort_estimate
+    attributes:
+      label: Effort Estimate
+      description: Approximate effort required (e.g., hours).
+      placeholder: Enter effort estimate.
+
+  - type: textarea
+    id: testability
+    attributes:
+      label: Testability
+      description: Describe how to test the fix.
+      placeholder: Describe testing steps for verification.
+
+  - type: textarea
+    id: dependencies
+    attributes:
+      label: Dependencies
+      description: List any dependent tasks or issues.
+      placeholder: Link dependencies here (e.g., \#123).
+
+  - type: markdown
+    attributes:
+      value: |
+        **Add Priority Label**:
+        - p1: Immediate attention
+        - p2: High priority
+        - p3: Standard priority
+        - p4: Low priority
+
+        **Add Group Label**:
+        - perception: Related to sensor processing and scene understanding
+        - planning: Related to path planning and decision making
+        - acting: Related to vehicle control and actuation
+        - system: Related to the general behavior of the system
+        - research: Related to research and experimentation
+        - infrastructure: Related to system infrastructure and setup

.github/ISSUE_TEMPLATE/FEATURE.yml

@@ -1,20 +1,58 @@
 name: 💡 Feature
 title: "[Feature]: "
-description: Something we should implement.
+description: A new feature to be implemented.
 labels: ["feature"]
 body:
   - type: textarea
-    id: desc
+    id: description
     attributes:
-      label: Description
-      description: Short description about what to do.
-      placeholder: The vehicle should detect traffic lights and it's states.
+      label: Feature Description
+      description: Provide a summary of the feature.
+      placeholder: The vehicle should detect traffic lights and their states.
 
   - type: textarea
-    id: dod
+    id: definition_of_done
     attributes:
       label: Definition of Done
-      description: What is required to mark the issue as done?
+      description: Completion criteria for the feature.
       placeholder: |
-        - 90% of the traffic lights are detected
-        - 90% of the traffic light states are detected correctly"
+        - Detects 90% of traffic lights.
+        - Correctly identifies 90% of traffic light states.
+
+  - type: input
+    id: effort_estimate
+    attributes:
+      label: Effort Estimate
+      description: Approximate effort required (e.g., hours).
+      placeholder: Enter effort estimate.
+
+  - type: textarea
+    id: testability
+    attributes:
+      label: Testability
+      description: How will the feature be tested?
+      placeholder: Describe test cases and success criteria.
+
+  - type: textarea
+    id: dependencies
+    attributes:
+      label: Dependencies
+      description: List any dependencies on other issues.
+      placeholder: Link dependencies here (e.g., \#456).
+
+  - type: markdown
+    attributes:
+      value: |
+        **Add Priority Label**:
+        - p1: Immediate attention
+        - p2: High priority
+        - p3: Standard priority
+        - p4: Low priority
+
+        **Add Group Label**:
+        - perception: Related to sensor processing and scene understanding
+        - planning: Related to path planning and decision making
+        - acting: Related to vehicle control and actuation
+        - system: Related to the general behavior of the system
+        - research: Related to research and experimentation
+        - infrastructure: Related to system infrastructure and setup

.github/ISSUE_TEMPLATE/ISSUE.yml

@@ -1,78 +1,55 @@
-name: "Issue Template"
-description: "Template for creating issues"
-labels: []
-assignees: []
+name: "General Issue"
+title: "[General]: "
+description: Template for general issues.
+labels: ["general"]
 
 body:
-  - type: markdown
-    attributes:
-      value: |
-        ## Please fill out all relevant fields:
-
   - type: textarea
     id: description
     attributes:
-      label: "Detailed Description"
-      description: "Describe the issue in detail"
+      label: Detailed Description
+      description: Describe the issue in detail.
       placeholder: |
-        Enter description here
+        Enter description here:
         - What is the problem?
-        - What is the expected behavior?
-        - What is the actual behavior?
+        - What is the expected outcome?
 
   - type: textarea
     id: definition_of_done
     attributes:
-      label: "Definition of Done"
-      description: "What needs to be completed for the task to be considered done?"
+      label: Definition of Done
+      description: Criteria for considering the task complete.
       placeholder: |
-        Example criteria:
-        - [ ] Implementation completed and tested
-        - [ ] Documentation updated
-        - [ ] Code review passed
-        - [ ] All tests passing
+        - Implementation completed and tested
+        - Documentation updated
+        - Code review passed
+        - All tests passing
 
   - type: input
     id: effort_estimate
     attributes:
-      label: "Effort Estimate"
-      description: "Estimate the effort required (e.g., in hours)"
-      placeholder: "Enter effort estimate here"
+      label: Effort Estimate
+      description: Approximate effort required (e.g., hours).
+      placeholder: Enter effort estimate.
 
   - type: textarea
     id: testability
     attributes:
-      label: "Testability"
-      description: "How can the implementation be tested?"
-      placeholder: "Enter testing methods here"
+      label: Testability
+      description: How to verify the issue's resolution.
+      placeholder: Enter test methods and validation criteria.
 
   - type: textarea
     id: dependencies
     attributes:
-      label: "Dependencies"
-      description: "Are there dependencies on other tasks or systems?"
-      placeholder: |
-        Enter dependencies here
-        - Task A must be completed before this task can start
-        - Link issues here with #<issue number>
+      label: Dependencies
+      description: List dependencies, if any.
+      placeholder: Link dependencies here (e.g., the issue \#789).
 
   - type: markdown
-    id: prioritization
     attributes:
       value: |
-        Add a priority label to this issue (p1 to p4) based on the following criteria:
-        - p1: Critical issue that needs immediate attention
-        - p2: Important issue that should be addressed soon
-        - p3: Issue that should be addressed in the near future
-        - p4: Issue that can be addressed later
-
-  - type: markdown
-    id: labels
-    attributes:
-      value: |
-        Add any relevant labels to this issue:
-
-        standard labels:
+        **Add Standard Label**:
         - bug: Something isn't working
         - enhancement: New feature or request
         - help wanted: Extra attention is needed
@@ -81,9 +58,16 @@ body:
         - question: Further information is requested
         - wontfix: This will not be worked on
 
-        project-specific labels:
+        **Add Priority Label**:
+        - p1: Immediate attention
+        - p2: High priority
+        - p3: Standard priority
+        - p4: Low priority
+
+        **Add Group Label**:
         - perception: Related to sensor processing and scene understanding
         - planning: Related to path planning and decision making
         - acting: Related to vehicle control and actuation
+        - system: Related to the general behavior of the system
         - research: Related to research and experimentation
         - infrastructure: Related to system infrastructure and setup

.github/workflows/build.yml

@@ -123,5 +123,5 @@ jobs:
           rm -rf /tmp/.buildx-cache/cache/latest
           mv /tmp/.buildx-cache/cache-new/latest /tmp/.buildx-cache/cache/latest
       
-      - name: Prune all images older than 1 days from self-hosted runner
+      - name: Prune all images older than 1 day from self-hosted runner
         run: docker image prune -a -f --filter "until=24h"

code/acting/launch/acting_debug.launch

@@ -0,0 +1,40 @@
+<!--
+This launch file starts acting as well as the debug node.
+-->
+<launch>
+    <arg name="role_name" default="hero" />
+    <arg name="control_loop_rate" default="0.05" /> 
+    <arg name="show_rqt_plots_automatically" default="true" />
+
+    <include file="$(find acting)/launch/acting.launch">
+        <arg name="control_loop_rate" value="$(arg control_loop_rate)"/>
+        <arg name="role_name" value="$(arg role_name)"/>
+    </include>
+
+    <node pkg="acting" type="Acting_Debug_Node.py" name="Acting_Debug_Node" output="screen">
+        <param name="control_loop_rate" value="$(arg control_loop_rate)"  />
+        <param name="role_name" value="$(arg role_name)" />
+    </node>
+
+
+    <node pkg="perception" type="kalman_filter.py" name="kalman_filter_node" output="screen">
+        <param name="control_loop_rate" value="$(arg control_loop_rate)" />
+        <param name="role_name" value="$(arg role_name)" />
+    </node>
+
+    <node pkg="perception" type="position_heading_publisher_node.py" name="position_heading_publisher_node" output="screen">
+        <param name="control_loop_rate" value="$(arg control_loop_rate)" />
+        <param name="role_name" value="$(arg role_name)" />
+        <param name="pos_filter" value="Kalman" />
+        <param name="heading_filter" value="Kalman" />
+    </node>
+
+    <group if="$(arg show_rqt_plots_automatically)">
+    <!-- If you want a live rqt_plots to show up automatically, 
+    include them like following example-plot for Velocity-Controller-Testing -->
+        <node pkg="rqt_plot" type="rqt_plot" output="screen" name="velocity_test" 
+            args="/carla/hero/Speed /paf/hero/target_velocity /paf/hero/throttle /paf/hero/brake"/>
+    </group>
+
+    <node type="rviz" name="rviz" pkg="rviz" args="-d $(find agent)/config/rviz_config.rviz" />
+</launch>

code/acting/src/acting/Acting_Debug_Node.py

@@ -178,6 +178,17 @@ def __init__(self):
         self.__vehicle_steers = []
         self.positions = []
 
+        # Initialize agent position
+        self.x = 0
+        self.y = 0
+        self.z = 0
+
+        # For visual purposes we set the trajectory height to vehicle heigt.
+        # The trajectory z coordinated do not affect steering or else.
+        # There is quite some confusion about visual height an actual height
+        # This parameter might needs adustment
+        self.z_visual = 0
+
         # Generate Trajectory as selected in TRAJECTORY_TYPE
         self.path_msg = Path()
         self.path_msg.header.stamp = rospy.Time.now()
@@ -286,7 +297,7 @@ def updated_trajectory(self, target_trajectory):
             pos.header.frame_id = "global"
             pos.pose.position.x = wp[0]
             pos.pose.position.y = wp[1]
-            pos.pose.position.z = 704  # needed for visuals
+            pos.pose.position.z = self.z_visual
             # currently not used therefore zeros
             pos.pose.orientation.x = 0
             pos.pose.orientation.y = 0

doc/acting/acting_testing.md

@@ -2,26 +2,27 @@
 
 **Summary:** This page shows ways to test and tune acting components and to verify that they work as intended.
 
-- [How to test/tune acting components independedly](#how-to-testtune-acting-components-independedly)
-  - [Acting\_Debug\_Node](#acting_debug_node)
-    - [Setup for Testing with the Debug-Node](#setup-for-testing-with-the-debug-node)
-    - [Operating the Debug-Node](#operating-the-debug-node)
+- [Acting\_Debug\_Node](#acting_debug_node)
+  - [Setup for Testing with the Debug-Node](#setup-for-testing-with-the-debug-node)
+  - [Operating the Debug-Node](#operating-the-debug-node)
 
 ## Acting_Debug_Node
 
 The [Acting_Debug_Node](../../code/acting/src/acting/Acting_Debug_Node.py) allows you to tune/test/verify all acting components independently of Planning-Inputs and also lets you easily output the data needed to plot/verify the tuning/testing you have done.
 
+There is a dedicated [acting_debug.launch](../../code/acting/launch/acting_debug.launch) file which starts the acting component **as well as the necesarry perception components** automatically. It is recommended to first test the [Acting_Debug_Node](../../code/acting/src/acting/Acting_Debug_Node.py)
+with an empty road scenario. The following guide provides instructions on how to launch this setup.
+
 ### Setup for Testing with the Debug-Node
 
-To use the [Acting_Debug_Node](../../code/acting/src/acting/Acting_Debug_Node.py) you first have to edit a few files in your current branch:
+To use the [Acting_Debug_Node](../../code/acting/src/acting/Acting_Debug_Node.py) you first have to edit a few files in your current branch: \\
+**! Make sure to revert these changes when pushing your branch!**
 
-- In the [acting.launch](../../code/acting/launch/acting.launch) file, you need to un-comment the ```Acting_Debug_Node```-node.
-- Disable Planning from sending *trajectory*, *target_velocity*, *unstuck* or *emergency* Messages.
-The easiest way to achieve this is to go to the [planning.launch](../../code/planning/launch/planning.launch) and just comment-out every active node.
-- As the Perception-nodes use alot of processing power and ressources and you most likely do not need them, you can disable them, again commenting-out unwanted nodes in the [perception.launch](../../code/perception/launch/perception.launch) file.
-**IMPORTANT:** As you need the **position_heading_publisher_node** and most likely the **kalman_filter** for the GNSS/IMU data, do keep those 2 active!
-- There is a developer-enviroment ready to use, if you want to test your components on an empty road.
-To switch to this, go to [docker_compose.yml](../../build/docker-compose.yml), where you will find which enviroment is currently chosen in lines 64-66. Uncomment the ```dev_launch``` and comment-out the ```leaderboard_evaluator``` if you want to use this developer-enviroment.
+- In [dev.launch](../../code/agent/launch/dev.launch) the [agent.launch](../../code/agent/launch/agent.launch) file is included. Change this to include [acting_debug.launch](../../code/acting/launch/acting_debug.launch) from the **acting** package.
+As mentioned above this includes everything we need.
+- In [docker-compose.devroute.yaml](../../build/docker-compose.devroute.yaml) change the command to 'bash -c "sleep 10 && roslaunch agent/launch/dev.launch"'
+- You can now 'docker compose up' the [docker-compose.devroute.yaml](../../build/docker-compose.devroute.yaml).
+  This should result in an empty road scenario with rviz and rqt.
 
 To now decide whether to work on noisy sensor data, with or without the kalman-filter, here is how to change this:
 
@@ -30,6 +31,8 @@ To now decide whether to work on noisy sensor data, with or without the kalman-f
 If you want to test a component on ideal sensor data (position/heading/both), go to the [dev_objects.json](../../code/agent/config/dev_objects.json) and find the ```GNSS```(position) and the ```IMU```(heading) sensors (lines 142-173) and set their noise-attributes to 0.
 It is then also recommended to set the ```pos_filter``` and ```heading_filter``` of the **position_heading_publisher_node** to None (as filtering ideal sensor data will make them inaccurate again).
 
+In [acting_debug.launch](../../code/acting/launch/acting_debug.launch) you can also set up different plot configurations for the rqt-window.
+
 ### Operating the Debug-Node
 
 When you open the [Acting_Debug_Node](../../code/acting/src/acting/Acting_Debug_Node.py) you will see, that alot of Testing-Options are selectable via Global Variables.