Merge pull request #40 from tier4/sync-upstream

chore: sync upstream

.github/sync-files.yaml

@@ -15,6 +15,14 @@
     - source: .github/workflows/spell-check-differential.yaml
     - source: .github/workflows/sync-files.yaml
     - source: .markdown-link-check.json
+      pre-commands: |
+        sd -s -- \
+        '     "pattern": "^http://localhost"' \
+        '     "pattern": "^https://www\\.autosar\\.org/*"
+            },
+            {
+              "pattern": "^http://localhost"' \
+          {source}
     - source: .markdownlint.yaml
     - source: .pre-commit-config-optional.yaml
     - source: .prettierignore

.github/workflows/github-release.yaml

@@ -26,8 +26,8 @@ jobs:
             REF_NAME="${{ github.ref_name }}"
           fi
 
-          echo ::set-output name=ref-name::"$REF_NAME"
-          echo ::set-output name=tag-name::"${REF_NAME#beta/}"
+          echo "ref-name=$REF_NAME" >> $GITHUB_OUTPUT
+          echo "tag-name=${REF_NAME#beta/}" >> $GITHUB_OUTPUT
 
       - name: Check out repository
         uses: actions/checkout@v3
@@ -39,7 +39,7 @@ jobs:
         id: set-target-name
         run: |
           if [[ "${{ steps.set-tag-name.outputs.ref-name }}" =~ "beta/" ]]; then
-            echo ::set-output name=target-name::"${{ steps.set-tag-name.outputs.ref-name }}"
+            echo "target-name=${{ steps.set-tag-name.outputs.ref-name }}" >> $GITHUB_OUTPUT
           fi
 
       - name: Create a local tag for beta branches
@@ -62,7 +62,7 @@ jobs:
             verb=edit
           fi
 
-          echo ::set-output name=verb::"$verb"
+          echo "verb=$verb" >> $GITHUB_OUTPUT
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 

.github/workflows/pre-commit.yaml

@@ -20,11 +20,6 @@ jobs:
         with:
           ref: ${{ github.event.pull_request.head.ref }}
 
-      - name: Set git config
-        uses: autowarefoundation/autoware-github-actions/set-git-config@v1
-        with:
-          token: ${{ steps.generate-token.outputs.token }}
-
       - name: Run pre-commit
         uses: autowarefoundation/autoware-github-actions/pre-commit@v1
         with:

.markdown-link-check.json

@@ -1,6 +1,9 @@
 {
   "aliveStatusCodes": [200, 206, 403],
   "ignorePatterns": [
+    {
+      "pattern": "^https://www\\.autosar\\.org/*"
+    },
     {
       "pattern": "^http://localhost"
     },
@@ -9,9 +12,6 @@
     },
     {
       "pattern": "^https://github.com/.*/discussions/new"
-    },
-    {
-      "pattern": "^https://www\\.autosar\\.org/*"
     }
   ],
   "retryOn429": true,

.pre-commit-config-optional.yaml

@@ -1,6 +1,6 @@
 repos:
   - repo: https://github.com/tcort/markdown-link-check
-    rev: v3.10.3
+    rev: v3.11.1
     hooks:
       - id: markdown-link-check
-        args: [--config=.markdown-link-check.json]
+        args: [--quiet, --config=.markdown-link-check.json]

docs/contributing/coding-guidelines/languages/cpp.md

@@ -13,7 +13,7 @@ Follow the guidelines below if a rule is not defined on this page.
 3. <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>
 
 Also, it is encouraged to apply Clang-Tidy to each file.
-For the usage, see [Applying Clang-Tidy to ROS packages](../../../how-to-guides/applying-clang-tidy-to-ros-packages.md).
+For the usage, see [Applying Clang-Tidy to ROS packages](../../../how-to-guides/others/applying-clang-tidy-to-ros-packages.md).
 
 Note that not all rules are covered by Clang-Tidy.
 

docs/contributing/coding-guidelines/ros-nodes/.pages

@@ -5,7 +5,6 @@ nav:
   - directory-structure.md
   - launch-files.md
   - message-guidelines.md
-  - naming.md
   - parameters.md
   - task-scheduling.md
   - topic-namespaces.md

docs/contributing/coding-guidelines/ros-nodes/coordinate-system.md

@@ -16,7 +16,7 @@ In Autoware, coordinate systems are typically used to represent the position and
 
 1. Transformation of sensor data
 
-   In Autoware, each sensor has a unique coordinate system and their data is expressed in terms of the coordinates. In order to correlate the independent datas between different sensors, we need to find the position relationship between each sensor and the vehicle body. Once the installation position of the sensor on the vehicle body is determined, it will remain fixed during running, so the offline calibration method can be used to determine the precise position of each sensor relative to the vehicle body.
+   In Autoware, each sensor has a unique coordinate system and their data is expressed in terms of the coordinates. In order to correlate the independent data between different sensors, we need to find the position relationship between each sensor and the vehicle body. Once the installation position of the sensor on the vehicle body is determined, it will remain fixed during running, so the offline calibration method can be used to determine the precise position of each sensor relative to the vehicle body.
 
 2. ROS TF2
 
@@ -117,12 +117,12 @@ References:
 
 1. Calibration of sensor
 
-   The conversion relationship between every sensor coordinate system and `base_link` can be obtained through sensor calibration technology. How to calibrating your sensors refer to this link [calibrating your sensors](https://autowarefoundation.github.io/autoware-documentation/main/how-to-guides/calibrating-your-sensors/).
+   The conversion relationship between every sensor coordinate system and `base_link` can be obtained through sensor calibration technology. How to calibrating your sensors refer to this link [calibrating your sensors](../../../how-to-guides/integrating-autoware/creating-vehicle-and-sensor-description/calibrating-sensors.md).
 
 2. Localization
 
    The relationship between the `base_link` coordinate system and the `map` coordinate system is determined by the position and orientation of the vehicle, and can be obtained from the vehicle localization result.
 
-3. Georeferencing of map data
+3. Geo-referencing of map data
 
-   The georeferencing information can get the transformation relationship of `earth` coordinate system to local `map` coordinate system.
+   The geo-referencing information can get the transformation relationship of `earth` coordinate system to local `map` coordinate system.

docs/contributing/coding-guidelines/ros-nodes/launch-files.md

@@ -1,5 +1,67 @@
 # Launch files
 
-!!! warning
+## Overview
 
-    Under Construction
+Autoware use ROS2 launch system to startup the software. Please see the [official documentation](https://docs.ros.org/en/humble/Tutorials/Intermediate/Launch/Launch-Main.html) to get a basic understanding about ROS 2 Launch system if you are not familiar with it.
+
+## Guideline
+
+### The organization of launch files in Autoware
+
+Autoware mainly has two repositories related to launch file organization: the [autoware.universe](https://github.com/autowarefoundation/autoware.universe) and the [autoware_launch](https://github.com/autowarefoundation/autoware_launch).
+
+#### autoware.universe
+
+the `autoware.universe` contains the code of the main Autoware modules, and its `launch` directory is responsible for launching the nodes of each module. Autoware software stack is organized based on the [architecture](https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture/#high-level-architecture-design), so you may find that we try to match the launch structure similar to the architecture (splitting of files, namespace). For example, the `tier4_map_launch` subdirectory corresponds to the map module, so do the other `tier4_*_launch` subdirectories.
+
+#### autoware_launch
+
+The `autoware_launch` is a repository referring to `autoware.universe`. The mainly purpose of introducing this repository is to provide the general entrance to start the Autoware software stacks, i.e, calling the launch file of each module.
+
+- The `autoware.launch.xml` is the basic launch file for road driving scenarios.
+
+  As can be seen from the content, the entire launch file is divided into several different modules, including _Vehicle_, _System_, _Map_, _Sensing_, _Localization_, _Perception_, _Planning_, _Control_, etc. By setting the `launch_*` argument equals to `true` or `false` , we can determine which modules to be loaded.
+
+- The `logging_simulator.launch.xml` is often used together with the recorded ROS bag to debug if the target module (e.g, _Sensing_, _Localization_ or _Perception_) functions normally.
+
+- The `planning_simulator.launch.xml` is based on the Planning Simulator tool, mainly used for testing/validation of _Planning_ module by simulating traffic rules, interactions with dynamic objects and control commands to the ego vehicle.
+
+- The `e2e_simulator.launch.xml` is the launcher for digital twin simulation environment.
+
+```mermaid
+graph LR
+A11[logging_simulator.launch.xml]-.->A10[autoware.launch.xml]
+A12[planning_simulator.launch.xml]-.->A10[autoware.launch.xml]
+A13[e2e_simulator.launch.xml]-.->A10[autoware.launch.xml]
+
+A10-->A21[tier4_map_component.launch.xml]
+A10-->A22[xxx.launch.py]
+A10-->A23[tier4_localization_component.launch.xml]
+A10-->A24[xxx.launch.xml]
+A10-->A25[tier4_sensing_component.launch.xml]
+
+A23-->A30[localization.launch.xml]
+A30-->A31[pose_estimator.launch.xml]
+A30-->A32[util.launch.xml]
+A30-->A33[pose_twist_fusion_filter.launch.xml]
+A30-->A34[xxx.launch.xml]
+A30-->A35[twist_estimator.launch.xml]
+
+A33-->A41[stop_filter.launch.xml]
+A33-->A42[ekf_localizer.launch.xml]
+A33-->A43[twist2accel.launch.xml]
+```
+
+### Add a new package in Autoware
+
+If a newly created package has executable node, we expect sample launch file and configuration within the package, just like the recommended structure shown in previous [directory structure](https://autowarefoundation.github.io/autoware-documentation/main/contributing/coding-guidelines/ros-nodes/directory-structure/) page.
+
+In order to automatically load the newly added package when starting Autoware, you need to make some necessary changes to the corresponding launch file. For example, if using ICP instead of NDT as the pointcloud registration algorithm, you can modify the `autoware.universe/launch/tier4_localization_launch/launch/pose_estimator/pose_estimator.launch.xml` file to load the newly added ICP package.
+
+## Parameter management
+
+Another purpose of introducing the `autoware_launch` repository is to facilitate the parameter management of Autoware. Thinking about this situation: if we want to integrate Autoware to a specific vehicle and modify parameters, we have to fork `autoware.universe` which also has a lot of code other than parameters and is frequently updated by developers. By intergrating these parameters in `autoware_launch`, we can customize the Autoware parameters just by forking `autoware_launch` repository. Taking the localization module as an examples:
+
+1. all the “launch parameters” for localization component is listed in the files under `autoware_launch/autoware_launch/config/localization`.
+2. the "launch parameters" file paths are set in the `autoware_launch/autoware_launch/launch/components/tier4_localization_component.launch.xml` file.
+3. in `autoware.universe/launch/tier4_localization_launch/launch`, the launch files loads the “launch parameters” if the argument is given in the parameter configuration file. You can still use the default parameters in each packages to launch `tier4_localization_launch` within `autoware.universe`.

docs/contributing/coding-guidelines/ros-nodes/topic-namespaces.md

@@ -11,7 +11,7 @@ ROS allows topics, parameters and nodes to be namespaced which provides the foll
 
 This page focuses on how to use namespaces in Autoware and shows some useful examples. For basic information on topic namespaces, refer to [this tutorial](https://design.ros2.org/articles/topic_and_service_names.html).
 
-## How topics should be named in Node
+## How topics should be named in node
 
 Autoware divides the node into the following functional categories, and adds the start namespace for the nodes according to the categories.
 
@@ -30,7 +30,7 @@ In general, topics should be namespaced based on the function of the node which
 
 Classify topics as input or output topics based on they are subscribed or published by the node. In the node, input topic is named `input/topic_name` and output topic is named `output/topic_name`.
 
-Configure the topic in the node's launch file. Take the `joy_controller` node as an example, in the following example, set the input and output topics and remap topics in the `joy_controller.luanch.xml` file.
+Configure the topic in the node's launch file. Take the `joy_controller` node as an example, in the following example, set the input and output topics and remap topics in the `joy_controller.launch.xml` file.
 
 ```xml
 <launch>
@@ -92,7 +92,7 @@ Configure the topic in the node's launch file. Take the `joy_controller` node as
     create_publisher<tier4_debug_msgs::msg::StringStamped>("~/debug/calculation_time", 1);
    ```
 
-   The launch configurated namespace will be add the topics before, so the topic names will be as following:
+   The launch configured namespace will be add the topics before, so the topic names will be as following:
 
    `/planning/scenario_planning/lane_driving/motion_planning/obstacle_avoidance_planner/debug/marker /planning/scenario_planning/lane_driving/motion_planning/obstacle_avoidance_planner/debug/calculation_time`
 

docs/contributing/pull-request-guidelines/index.md

@@ -50,6 +50,26 @@ Use this workflow as a reference when you contribute to Autoware.
 
 #### Example
 
+There are two types of templates. Select one based on the following condition.
+
+1. [Standard change](https://github.com/autowarefoundation/autoware/blob/main/.github/PULL_REQUEST_TEMPLATE/standard-change.md):
+   - Complexity:
+     - New features or significant updates.
+     - Requires deeper understanding of the codebase.
+   - Impact:
+     - Affects multiple parts of the system.
+     - Basically includes minor features, bug fixes and performance improvement.
+     - Needs testing before merging.
+2. [Small change](https://github.com/autowarefoundation/autoware/blob/main/.github/PULL_REQUEST_TEMPLATE/small-change.md):
+   - Complexity:
+     - Documentation, simple refactoring, or style adjustments.
+     - Easy to understand and review.
+   - Impact:
+     - Minimal effect on the system.
+     - Quicker merge with less testing needed.
+
+##### Steps to use an appropriate pull request template
+
 1. Select the appropriate template, as shown in [this video](https://user-images.githubusercontent.com/31987104/184344710-2adee239-799f-4fdf-bfab-be76345bfac1.mp4).
 2. Read the selected template carefully and fill the required content.
 3. Check the checkboxes during a review.

docs/datasets/index.md

@@ -68,7 +68,7 @@ $ aws s3 ls s3://autoware-files/collected_data/2022-08-22_leo_drive_isuzu_bags/
 aws s3 sync s3://autoware-files/collected_data/2022-08-22_leo_drive_isuzu_bags/all-sensors-bag1_compressed/ ./all-sensors-bag1_compressed  --no-sign-request
 ```
 
-### AutoCore.ai - lidar ROS2 bag file and pcap
+### AutoCore.ai - lidar ROS 2 bag file and pcap
 
 This dataset contains pcap files and ros2 bag files from Ouster OS1-64 Lidar.
 The pcap file and ros2 bag file is recorded in the same time with slight difference in duration.