autowarefoundation / autoware.universe

Autoware Universe

Welcome to Autoware Universe

Autoware Universe serves as a foundational pillar within the Autoware ecosystem, playing a critical role in enhancing the core functionalities of autonomous driving technologies. This repository is a pivotal element of the Autoware Core/Universe concept, managing a wide array of packages that significantly extend the capabilities of autonomous vehicles.

Getting Started

To dive into the vast world of Autoware and understand how Autoware Universe fits into the bigger picture, we recommend starting with the Autoware Documentation. This resource provides a thorough overview of the Autoware ecosystem, guiding you through its components, functionalities, and how to get started with development.

Explore Autoware Universe documentation

For those looking to explore the specifics of Autoware Universe components, the Autoware Universe Documentation, deployed with MKDocs, offers detailed insights.

autoware.universe's Issues

Fix calcuation of angle difference

In the function of angle difference calculation, NaN value is returned when the absolute value of inner product is larger than 1.

autoware.universe/map/lanelet2_extension/lib/query.cpp

Lines 38 to 45 in 045009c

	double getAngleDifference(const double angle1, const double angle2)
	{
	Eigen::Vector2d vec1, vec2;
	vec1 << std::cos(angle1), std::sin(angle1);
	vec2 << std::cos(angle2), std::sin(angle2);
	const double diff_angle = std::acos(vec1.dot(vec2));
	return std::fabs(diff_angle);
	}

This is because arg of atd::acos shouldn't be outside the range [-1.0, 1.0] expalined here.
Numerical error happens in some cases so gurad needs to be added.

Fix subscriber qos for route

https://github.com/tier4/autoware.iv/pull/2388

Remove unnecessary messages from Tier IV's proposal messages

Check the dependency and remove unnecessary messages that are replaced by autoware_auto_msgs from messages.

• autoware_control_msgs
• autoware_vehicle_msgs
• autoware_perception_msgs
• autoware_planning_msgs
• autoware_system_msgs
• autoware_lanelet2_msgs

`/vehicle/status/control_mode` is always autonomous with simple planning simulator

It should be MANUAL before autoware engage, the same as the simple planning simulator in autoware.iv

Fix legacy timer creation

https://github.com/tier4/autoware.iv/pull/2302

Rename package name for messages for AutowareArchitectureProposal packages

Currently, names of the messages used for Autoware Architecture Proposal packages could overlap with AutowareAuto msgs.
We will replace the package name with unique packages name (e.g. t4_planning_msgs) after all the merging of packages are done.

Add vehicle_info_params to launch files

Add vehicle_info_params to launch files which use the vehicle_info_utils

Fix ARM build errors of ndt_omp

https://github.com/autowarefoundation/autoware.universe/runs/4412075103?check_suite_focus=true

@harihitode and @KeisukeShima are working on this.
Although it's already fixed here, since it's just a workaround, they're improving this.

Add planning_evaluator package to evaluate planning module performance.

problem

The evaluation infrastructure for planning development is not in place, and degradation checking and performance evaluation depend on humans. This process should be automated and some quantitative indicators need to be defined and the results visualized.
This allows for efficient evaluation of development and comparison between different planners.

suggestion

Using the trajectory generated by the planning module as input, create a node that can evaluate the smoothness of the trajectory, etc.
This node can be activated separately from autoware when you want to evaluate the trajectory.
If you want to evaluate different property, you can add functions to planning_evaluator.

pros and cons

By defining a reasonable index, quantitative evaluation of the trajectory becomes possible, but there is a possibility that the performance of autoware itself will deteriorate if the processing load of the planning_evaluator itself increases.

transition plan

Since there is currently no function that utilizes the output of this node, there is no need to consider it.

Add automatic link checks for Markdown files

It's useful we can detect dead links automatically.

Importing our proposal way can solve this.
https://github.com/tier4/AutowareArchitectureProposal.iv/blob/05c248e52f7ad930e30002d49fb545fc5d568abf/.pre-commit-config-optional.yaml#L16-L20

Remove unnecessary depends from build_depends.repos

https://github.com/autowarefoundation/autoware.universe/blob/272645304e8acda0a13dc4bf9935edbf50c12b32/build_depends.repos

• tier4_ament_lint can be replaced by autoware_common
• rosauth can be removed
• etc.

Before removing them, we have to add a CI for build_depends.repos.

Consider removing `exec_depend` in CI testing

Testing for launch packages is too slow.
https://github.com/autowarefoundation/autoware.universe/runs/4521035044?check_suite_focus=true

Example:
https://github.com/tier4/AutowareArchitectureProposal_launcher/blob/2af084219d0fae7effa46ef1277bb8f2082f19c6/.github/workflows/build_and_test_pr.yml#L35-L38

Making unit tests for each functions

[updated]
Make a unit tests for new feature would be better for reviewers.

Support rolling(humble)

Some modifications are necessary to migrate to ros2 rolling(humble).
#247

Is it OK to have TODO comment in PR code?

as PR title description.

Sometimes unit test fails

Consider using Composite Actions instead of Reusable Workflows in GitHub Actions

Reusable Workflows are very useful, so I introduced here.

However, I found it has a few disadvantages in some use cases.
https://github.community/t/ref-head-in-reusable-workflows/203690/17

Therefore, I'll replace some of the Reusable Workflows with Composite Actions.

[Composite Actions]

• To reuse some steps, not the entire job
• To refer to local actions or files

[Reusable Workflows]

• To reuse the entire job
• To make the task's environment clean or separated

Fix invalid links

There are some invalid links.
#283
https://github.com/autowarefoundation/autoware.universe/runs/4898066823?check_suite_focus=true

Subscriber publishes topic which publisher is not yet established

Unit test for daily health check is unstable

100% tests passed, 0 tests failed out of 6

Label Time Summary:
copyright = 11.92 secproc (1 test)
cppcheck = 1.07 secproc (1 test)
gtest = 1.04 secproc (2 tests)
lint_cmake = 0.71 secproc (1 test)
linter = 15.99 secproc (4 tests)
xmllint = 2.28 secproc (1 test)

Total Test time (real) = 17.04 sec
Finished <<< behavior_velocity_planner [18.3s]

Summary: 1 package finished [19.5s]

usually test passes with 100% CPU stress but it's not in daily Test

rename launch packages

*_launch -> tier4_*_launch

(ex. control_launch -> tier4_control_launch)

Add implementation to arm_cpu_monitor

I fixed a build error on aarch64 (#263), but that only suppressed warnings.
To support aarch64 systems with system_monitor, we need to add an implementation to arm_cpu_monitor.
Now, the following function is unimplemented.
https://github.com/autowarefoundation/autoware.universe/blob/tier4/proposal/system/system_monitor/src/cpu_monitor/arm_cpu_monitor.cpp#L33

I would like to contribute to this feature, but I don't have an aarch64 machine, so implementation is difficult. Therefore, I created an issue.

NOTE: Among the aarch64 machines, Raspberry Pi and Tegra are implemented differently.

• Raspberry Pi seems to have already been implemented.
  https://github.com/autowarefoundation/autoware.universe/blob/tier4/proposal/system/system_monitor/src/cpu_monitor/raspi_cpu_monitor.cpp
• Tegra is not yet implemented.
  https://github.com/autowarefoundation/autoware.universe/blob/tier4/proposal/system/system_monitor/src/cpu_monitor/tegra_cpu_monitor.cpp#L34

Simple planning simulator does not consider vehicle/engage result.

simple planning simulator dropped some features during .universe porting

• /vehicle/engage result is not considered for simulating (Ideally, simulating only when /vehicle/engage result is true)
• default parameter for /vehicle/engage result (current_engage_ variable) was removed and set false by default.

Consider using global_parameter_loader

With our current plan, there will be multiple default_common.param.yaml, but it might increase the maintenance cost, for example when the common parameter gets a new variable.

• https://github.com/autowarefoundation/autoware.universe/blob/c2e79c3a56956f867030b2cbc9675e2e7c7c1339/planning/external_velocity_limit_selector/config/default_common.param.yaml
• https://github.com/autowarefoundation/autoware.universe/blob/c2e79c3a56956f867030b2cbc9675e2e7c7c1339/planning/motion_velocity_smoother/config/default_common.param.yaml

To avoid this, we can consider global_parameter_loader.

autoware.universe/planning/behavior_velocity_planner/launch/behavior_velocity_planner.launch.xml

Line 3 in c2e79c3

<include file="$(find-pkg-share autoware_global_parameter_loader)/launch/global_params.launch.py"/>

https://github.com/autowarefoundation/autoware.universe/blob/c2e79c3a56956f867030b2cbc9675e2e7c7c1339/common/autoware_global_parameter_loader

Without global_parameter_loader

launch.xml:

// planning.launch.xml
<launch>
  <include file="behavior_planner.launch.xml">
    <arg name="common_param_path" value="{path_to_file}" />
    <arg name="vehicle_param_path" value="{path_to_file}" />
  </include>
</launch>


// behavior_planner.launch.xml
<launch>
  // Don't consider the default values here because you can't use them when you debug in the real environment.
  <arg name="common_param_path" />
  <arg name="vehicle_param_path" />

  <node ...>
  </node>
</launch>

How to launch:

// autoware.launch.xml
ros2 launch autoware_launch autoware.launch.xml vehicle_model:={vehicle_name}

// behavior_planner.launch.xml
ros2 launch planning_launch behavior_planner.launch.xml common_param_path:={path_to_file} vehicle_info_param_path:={path_to_file}

With global_parameter_loader

launch.xml:

// planning.launch.xml
<launch>
  <include file="behavior_planner.launch.xml">
    // No arg
  </include>
</launch>

// behavior_planner.launch.xml
<launch>
  <include file="$(find-pkg-share autoware_global_parameter_loader)/launch/global_params.launch.py"/>

  <node ...>
  </node>
</launch>

How to launch:

// autoware.launch.xml
ros2 launch autoware_launch autoware.launch.xml vehicle_model:={vehicle_name}

// behavior_planner.launch.xml
ros2 launch planning_launch behavior_planner.launch.xml vehicle_model:={vehicle_name}

detection area rviz marker is heavy

if huge point cloud is found in detection area some times computation cost becomes larger

Fix spellcheck errors

some packages have spell check errors

Merge packages from autoware.auto repo

This issue aims to merge packages from autoware repo in gitlab. Prefix 'auto' will be added to packages from gitlab to distinguish with those in universe. The current plan is to add most packages except for the ones under src/tools. Please feel free to make any comment or suggestion.

Fix behavior_velocity_planner

Port https://github.com/tier4/autoware.iv/pull/2413 .

• Add margin to isBeforeStopLine #228
• Common parameter with isNearAnyEndLine and isNearAnyEndLine. #228
• Fixed the bool value of isStateTimeout. #228
• Check timeout even after the stop_line by default #228
• Fix findForwardOffsetSegment of detection_area #305
• Fix virtual_traffic_light findBackwardOffsetSegment index #306
• Consider pose for overlapping lanes #306
• Fix virtual_traffic_light state #306
• Add instrument information to logger #328

Add common packages and tool packages of autoware.auto

Add common packages and tool packages of autoware.auto for the dependencies of the autoware.auto package.

• autoware_auto_cmake
• autoware_auto_common
• autoware_auto_geometry
• autoware_auto_tf2
• autoware_testing
• fake_test_node
• had_map_utils
• motion_common
• motion_testing
• time_utils
• vehicle_constants_manager

Separate callback group to execute callbackInitialPose in parallel

https://github.com/tier4/autoware.iv/pull/2372

Rename existing packages named `autoware_*` to different names

To avoid confusion between Core/Common's prefix.
autowarefoundation/autoware_common#3 (comment)

missing updateQ function in osqp interface

updateQ function was removed by mistake that is necessary to use warm start of osqp.

Some of the reference articles are written in Japanese

Some packages of readme or comment has reference which is written by Japanese.

If it's easily replace by English article then replace it, otherwise leave it alone.

When the processing load of the main callback function is high, other callback functions starve.

When the processing load of the main callback function is high, the other callback functions starve.
In particular, some of the planning processes are so heavy that they cannot receive velocity, object and pointcloud.

The same problem occurred in localization, and it was solved by using multi-threading.
0ec1440#diff-636e0f59d675b65f5e7fc80e805b839474f437d7c89a46b4af048f455ee46e26

some of calcSignedArcLength function need to consider path index or pose

occlusion spot: remaining TODOs

below is remaing TODOs

1. better interpolation using original path behind ego #290
2. consider using lanelet info to filter unnecessary possible collision.
3. fix velocity of spline interpolation #290
4. consider safe margin before collision point #344
5. consider detection area of passable/impassable collisiopn. #354

below is bug fix
#351

Add package dependency

Check the dependency and add necessary dependency that are used by autoware pakcages

Change the reference of autoware_auto_msgs

autowarefoundation/autoware_common#4 (comment)

• Move Tier IV's fork to AWF org?
• Consider renaming repository name as autoware_msgs
  • Because the package names might change in the future.

Diagnostics with no corresponding node

There are no nodes that output these diagnostics in this repository or in any other public repository.
Don't these need to be removed or commented out?

https://github.com/autowarefoundation/autoware.universe/blob/tier4/proposal/system/system_error_monitor/config/diagnostic_aggregator/control.param.yaml#L69-L81

https://github.com/autowarefoundation/autoware.universe/blob/tier4/proposal/system/system_error_monitor/config/diagnostic_aggregator/map.param.yaml#L17-L25

How much should we adjust "Autoware.auto packages" to the "Tier4" acceptance criteria?

So far some packages area back porting from autoware.auto so we should change as minimal as possible, so we don't apply these changes.

• pre-commit (ignore for temporary)
• add sample launch file (each packages should have sample launch file)
• pass Gtest
• readme.md

below should be added?

• add sample launch file (each packages should have sample launch file)

Merge packages in Tier IV's AutowareArchitectureProposal repository

Merge packages in https://github.com/tier4/AutowareArchitectureProposal.iv

VehicleStateCommand is still used in simple_planning_simulator, which is a deprecated message

We have to replace VehicleStateCommand with GearCommand.

Support Docker development environment

To provide an easy-to-develop environment, we should support Docker.

The base of Dockerfile is introduced here.
https://github.com/tier4/AutowareArchitectureProposal.proj/tree/main/docker

Also, Autoware.Auto has Dockerfile for ade.
https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/blob/master/tools/ade_image/Dockerfile

Display labeled code coverage in pull requests

Related to autowarefoundation/autoware-documentation#2, I would like to add the feature to measure and display code coverage for pull requests to improve review process.

Considerations

• About the reporter, whether to use CodeCov or to create a function to measure and report in GitHub Actions.
• How to specify labels for coverage by label, whether to automatically collect all labels or to specify the labels we want to set.

consider case when autoware overshoot internally or externally

There are some modules which doesn't define case for overshooting stop line without fulfilling stop condition by internal control error or external manual input that causes "Stop forever until manual override is applied". For example stop line defines stop state as 2 [sec] velocity below of 0.1[m/s] at 2[m] around stop line however if there is manual override or control error occur and over stop line stop line without notice then it will never meet stop line condition and stop velocity insert forever. So we should clear dead line margin (margin after stop line) which "we don't consider distance to stop line as a stop condition". So my suggestion is if overshoot happens "stop anyway for 2 sec at any place, then GO".

overshoot: mostly caused by manual override by human who thinks already stopped and stop condition was met in autoware but actually not.

Add missing current pose topic for simple planning simulator

This line is unsed so far so it would be better to remove this line and assume pose from simulator is coming from odometry message.

autoware.universe/simulator/simple_planning_simulator/src/simple_planning_simulator/simple_planning_simulator_core.cpp

Line 112 in 2726453

pub_current_pose_ = create_publisher<PoseStamped>("/current_pose", QoS{1});

or
add /current_pose topic like autoware.iv
The same information is in odometry message but ,It seem no package refer to pose from odometry message

i think it's better to publish PoseStamped message from simulator for better compatibility.

cc : @isamu-takagi

Galactic ARM version of pacmod3_msgs isn't released

rosdep install in ARM CI failed.
https://github.com/autowarefoundation/autoware.universe/runs/4749500723?check_suite_focus=true#step:7:6268

https://s3.amazonaws.com/autonomoustuff-repo

behavior avoidance need to consider area to be able to drive

Fix typos

I think procs can be added to the dictionary or be replaced by processes (or processors?).

Add delay model of velocity and steering

Adding delay model of velocity and steering which reads velocity command as DELAY_STEER_VEL.
This model was used in autoware.iv as DELAY_STEER. And this model was not ported from autoware.iv.

autoware.universe/simulator/simple_planning_simulator/include/simple_planning_simulator/simple_planning_simulator_core.hpp

Lines 188 to 197 in 4dc308f

	/* vehicle model */
	enum class VehicleModelType
	{
	IDEAL_STEER_ACC = 0,
	IDEAL_STEER_ACC_GEARED = 1,
	DELAY_STEER_ACC = 2,
	DELAY_STEER_ACC_GEARED = 3,
	IDEAL_STEER_VEL = 4,
	DELAY_STEER_VEL = 5
	} vehicle_model_type_; //!< @brief vehicle model type to decide the model dynamics