chore: rename from autoware.universe to autoware_universe (#655)

Author: youtalk

docs/autoware-competitions/index.md

@@ -6,7 +6,7 @@ This page is a collection of the links to the competitions that are related to t
 | :-----------------------------------------------------------: | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | <img src="images/autoware_challenge_2023.png" width = 640px > | Ongoing  | **[Autoware / TIER IV Challenge 2023](https://autoware.org/autoware-challenge-2023)** <br> **Date:** May 15, 2023 - Nov. 1st, 2023 <br><br> As one of the main contributors of Autoware, TIER IV has been facing many difficult challenges through development, and TIER IV would like to sponsor a challenge to solve such engineering challenges. Any researchers, students, individuals or organizations are welcome to participate and submit their solution to any of the challenges we propose.                                                                                                                                                                                                                     |
 |    <img src="images/ai_challenge_2023.png" width = 640px >    | Finished | **[Japan Automotive AI Challenge 2023 (Integration)](https://www.jsae.or.jp/jaaic/2023_summary.php)** <br> **Registration:** June 5, 2023 - July 14, 2023 <br>**Qualifiers:** July 3, 2023 - Aug. 31, 2023 <br>**Finals:** Nov. 12, 2023<br><br> In this competition, we focus on challenging tasks posed by autonomous driving in factory environments and aim to develop Autoware-based AD software that can overcome them. The qualifiers use the [digital twin autonomous driving simulator AWSIM](https://tier4.github.io/AWSIM/) to complete specific tasks within a virtual environment. Teams that make it to the finals have the opportunity to run their software on actual vehicles in a test course in Japan. |
-| <img src="images/ai_challenge2023-racing.jpg" width = 640px > | Ongoing  | **[Japan Automotive AI Challenge 2023 (Simulation)](https://www.jsae.or.jp/jaaic/2023_simulation.php)** <br> **Registration:** Nov 6, 2023 - Dec 28, 2023 <br>**Date:** Dec 4, 2023 - Jan. 31, 2024 <br><br> This contest is a software development contest with a motorsports theme. Participants will develop autonomous driving software based on [Autoware.Universe](https://github.com/autowarefoundation/autoware.universe), and integrate it into a racing car that runs in the End to End simulation space (AWSIM). The goal is simple, win the race while driving safely!                                                                                                                                        |
+| <img src="images/ai_challenge2023-racing.jpg" width = 640px > | Ongoing  | **[Japan Automotive AI Challenge 2023 (Simulation)](https://www.jsae.or.jp/jaaic/2023_simulation.php)** <br> **Registration:** Nov 6, 2023 - Dec 28, 2023 <br>**Date:** Dec 4, 2023 - Jan. 31, 2024 <br><br> This contest is a software development contest with a motorsports theme. Participants will develop autonomous driving software based on [Autoware Universe](https://github.com/autowarefoundation/autoware_universe), and integrate it into a racing car that runs in the End to End simulation space (AWSIM). The goal is simple, win the race while driving safely!                                                                                                                                        |
 
 ## Proposing New Competition
 

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

@@ -8,15 +8,15 @@ Autoware use ROS 2 launch system to startup the software. Please see the [offici
 
 ### 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 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
+#### 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.
+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` 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.
 
@@ -56,12 +56,12 @@ A33-->A43[twist2accel.launch.xml]
 
 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.
+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 integrating these parameters in `autoware_launch`, we can customize the Autoware parameters just by forking `autoware_launch` repository. Taking the localization module as an examples:
+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 integrating 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`.
+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/parameters.md

@@ -57,7 +57,7 @@ As there is no _default_value_ provided, the function throws an exception if a p
 
 The table has been derived from [Parameter Type](https://github.com/ros2/rcl_interfaces/blob/humble/rcl_interfaces/msg/ParameterType.msg) and [Parameter Value](https://github.com/ros2/rcl_interfaces/blob/humble/rcl_interfaces/msg/ParameterValue.msg).
 
-See example: _Lidar Apollo Segmentation TVM Nodes_ [declare function](https://github.com/autowarefoundation/autoware.universe/blob/f85c90b56ed4c7d6b52e787570e590cff786b28b/perception/lidar_apollo_segmentation_tvm_nodes/src/lidar_apollo_segmentation_tvm_node.cpp#L38)
+See example: _Lidar Apollo Segmentation TVM Nodes_ [declare function](https://github.com/autowarefoundation/autoware_universe/blob/f85c90b56ed4c7d6b52e787570e590cff786b28b/perception/lidar_apollo_segmentation_tvm_nodes/src/lidar_apollo_segmentation_tvm_node.cpp#L38)
 
 ## Parameter File
 
@@ -78,7 +78,7 @@ Autoware has the following two types of parameter files for ROS packages:
 
 - **Node parameter file**
   - Node parameter files store the default parameters provided for each package in Autoware.
-    - For example, [the parameter of `behavior_path_planner`](https://github.com/autowarefoundation/autoware.universe/tree/245242cee866de2d113e89c562353c5fc17f1f98/planning/behavior_path_planner/config)
+    - For example, [the parameter of `behavior_path_planner`](https://github.com/autowarefoundation/autoware_universe/tree/245242cee866de2d113e89c562353c5fc17f1f98/planning/behavior_path_planner/config)
   - All nodes in Autoware must have a parameter file if ROS parameters are declared in the node.
   - For `FOO_package`, the parameter is expected to be stored in `FOO_package/config`.
   - The launch file for individual packages must load node parameter by default:
@@ -149,7 +149,7 @@ Autoware has the following two types of parameter files for ROS packages:
 
 The schema file path is `INSERT_PATH_TO_PACKAGE/schema/` and the schema file name is `INSERT_NODE_NAME.schema.json`. To adapt the template to the ROS node, replace each `INSERT_...` and add all parameters `1..N`.
 
-See example: _Image Projection Based Fusion - Pointpainting_ [schema](https://github.com/autowarefoundation/autoware.universe/blob/main/universe/perception/autoware_image_projection_based_fusion/schema/pointpainting.schema.json)
+See example: _Image Projection Based Fusion - Pointpainting_ [schema](https://github.com/autowarefoundation/autoware_universe/blob/main/universe/perception/autoware_image_projection_based_fusion/schema/pointpainting.schema.json)
 
 ### Attributes
 

docs/contributing/coding-guidelines/ros-nodes/topic-message-handling/index.md

@@ -204,4 +204,4 @@ If `rclcpp::Executor` based object, an executor, is programmed to call a callbac
 As of May 2024, the recommended manners are beginning to be used in Autoware Universe.
 See the following PR if you want an example in Autoware Universe.
 
-[_feat(tier4_autoware_utils, obstacle_cruise): change to read topic by polling #6702_](https://github.com/autowarefoundation/autoware.universe/pull/6702)
+[_feat(tier4_autoware_utils, obstacle_cruise): change to read topic by polling #6702_](https://github.com/autowarefoundation/autoware_universe/pull/6702)

docs/contributing/pull-request-guidelines/ai-pr-review.md

@@ -4,7 +4,7 @@ We have [Codium-ai/pr-agent](https://github.com/Codium-ai/pr-agent/tree/main) en
 
 ## The workflow
 
-Workflow: [pr-agent.yaml](https://github.com/autowarefoundation/autoware.universe/blob/main/.github/workflows/pr-agent.yaml)
+Workflow: [pr-agent.yaml](https://github.com/autowarefoundation/autoware_universe/blob/main/.github/workflows/pr-agent.yaml)
 
 ### Additional links for the workflow maintainers
 

docs/contributing/pull-request-guidelines/code-owners.md

@@ -20,16 +20,16 @@ Generally, repository maintainers handle the updates to `CODEOWNERS` files. To p
 
 ### Special case for the Autoware Universe repository
 
-In the [autoware.universe](https://github.com/autowarefoundation/autoware.universe) repository, maintenance of the `CODEOWNERS` file is automated by the CI.
+In the [autoware_universe](https://github.com/autowarefoundation/autoware_universe) repository, maintenance of the `CODEOWNERS` file is automated by the CI.
 
-[This workflow](https://github.com/autowarefoundation/autoware.universe/actions/workflows/update-codeowners-from-packages.yaml) updates the `CODEOWNERS` file based on the `maintainer` information in the `package.xml` files of the packages in the repository.
+[This workflow](https://github.com/autowarefoundation/autoware_universe/actions/workflows/update-codeowners-from-packages.yaml) updates the `CODEOWNERS` file based on the `maintainer` information in the `package.xml` files of the packages in the repository.
 
-In order to change the code owners for a package in the `autoware.universe` repository:
+In order to change the code owners for a package in the `autoware_universe` repository:
 
 1. Modify the `maintainer` information in the `package.xml` file via a PR.
 2. Once merged, the CI workflow runs at midnight UTC (or can be triggered manually by a maintainer) to update the `CODEOWNERS` file and create a PR.
 3. A maintainer then needs to merge the CI-generated PR to finalize the update.
-   - **Example Automated PR:** [chore: update CODEOWNERS #6866](https://github.com/autowarefoundation/autoware.universe/pull/6866)
+   - **Example Automated PR:** [chore: update CODEOWNERS #6866](https://github.com/autowarefoundation/autoware_universe/pull/6866)
 
 ## Responsibilities of code owners
 

docs/contributing/testing-guidelines/integration-testing.md

@@ -56,7 +56,7 @@ Doing so adds smoke tests that ensure that a node can be:
 2. Terminated with a standard `SIGTERM` signal.
 
 For the full API documentation,
-refer to the [package design page](https://github.com/autowarefoundation/autoware.universe/blob/main/common/autoware_testing/design/autoware_testing-design.md).
+refer to the [package design page](https://github.com/autowarefoundation/autoware_universe/blob/main/common/autoware_testing/design/autoware_testing-design.md).
 
 !!! note
 
@@ -70,16 +70,16 @@ The simplest scenario is a single node.
 In this case, the integration test is commonly referred to as a component test.
 
 To add a component test to an existing node,
-you can follow the example of the `lanelet2_map_loader` in the [`autoware_map_loader` package](https://github.com/autowarefoundation/autoware.universe/tree/main/map/autoware_map_loader)
-(added in [this PR](https://github.com/autowarefoundation/autoware.universe/pull/1056)).
+you can follow the example of the `lanelet2_map_loader` in the [`autoware_map_loader` package](https://github.com/autowarefoundation/autoware_universe/tree/main/map/autoware_map_loader)
+(added in [this PR](https://github.com/autowarefoundation/autoware_universe/pull/1056)).
 
-In [`package.xml`](https://github.com/autowarefoundation/autoware.universe/blob/main/map/autoware_map_loader/package.xml), add:
+In [`package.xml`](https://github.com/autowarefoundation/autoware_universe/blob/main/map/autoware_map_loader/package.xml), add:
 
 ```xml
 <test_depend>ros_testing</test_depend>
 ```
 
-In [`CMakeLists.txt`](https://github.com/autowarefoundation/autoware.universe/blob/main/map/autoware_map_loader/CMakeLists.txt),
+In [`CMakeLists.txt`](https://github.com/autowarefoundation/autoware_universe/blob/main/map/autoware_map_loader/CMakeLists.txt),
 add or modify the `BUILD_TESTING` section:
 
 ```cmake
@@ -106,7 +106,7 @@ To create a test,
 either read the [launch_testing quick-start example](https://github.com/ros2/launch/tree/master/launch_testing#quick-start-example),
 or follow the steps below.
 
-Taking [`test/lanelet2_map_loader_launch.test.py`](https://github.com/autowarefoundation/autoware.universe/blob/main/map/autoware_map_loader/test/lanelet2_map_loader_launch.test.py) as an example,
+Taking [`test/lanelet2_map_loader_launch.test.py`](https://github.com/autowarefoundation/autoware_universe/blob/main/map/autoware_map_loader/test/lanelet2_map_loader_launch.test.py) as an example,
 first dependencies are imported:
 
 ```python
@@ -122,7 +122,7 @@ import pytest
 ```
 
 Then a launch description is created to launch the node under test.
-Note that the [`test_map.osm`](https://github.com/autowarefoundation/autoware.universe/blob/main/map/autoware_map_loader/test/data/test_map.osm) file path is found and passed to the node,
+Note that the [`test_map.osm`](https://github.com/autowarefoundation/autoware_universe/blob/main/map/autoware_map_loader/test/data/test_map.osm) file path is found and passed to the node,
 something that cannot be done with the [smoke testing API](#smoke-tests):
 
 ```python
@@ -184,7 +184,7 @@ source install/setup.bash
 Then either execute the component test manually:
 
 ```console
-ros2 test src/universe/autoware.universe/map/autoware_map_loader/test/lanelet2_map_loader_launch.test.py
+ros2 test src/universe/autoware_universe/map/autoware_map_loader/test/lanelet2_map_loader_launch.test.py
 ```
 
 Or as part of testing the entire package:

docs/contributing/testing-guidelines/unit-testing.md

@@ -163,6 +163,6 @@ Total Test time (real) =   7.91 sec
 Loosely described,
 a code coverage metric is a measure of how much of the program code has been exercised (covered) during testing.
 
-In the Autoware repositories, [Codecov](https://app.codecov.io/gh/autowarefoundation/autoware.universe/) is used to automatically calculate coverage of any open pull request.
+In the Autoware repositories, [Codecov](https://app.codecov.io/gh/autowarefoundation/autoware_universe/) is used to automatically calculate coverage of any open pull request.
 
 More details about the code coverage metrics can be found in the [Codecov documentation](https://docs.codecov.com/docs/about-code-coverage).

docs/datasets/index.md

@@ -177,4 +177,4 @@ The pcap file and ros2 bag file is recorded in the same time with slight differe
 
 [Click here to download (~553MB)](https://autoware-files.s3.us-west-2.amazonaws.com/collected_data/2022-04-14_autocore-lidar-bag-pcap/Lidar_Data_220414_bag_pcap.zip)
 
-[Reference Issue](https://github.com/autowarefoundation/autoware.universe/issues/562#issuecomment-1102662448)
+[Reference Issue](https://github.com/autowarefoundation/autoware_universe/issues/562#issuecomment-1102662448)