autowarefoundation / autoware_common

autoware_common

Commonly referenced ROS library packages for Autoware.

Note that the packages under tmp/ may introduce breaking changes and is planned to be replaced by re-designed packages in the future.

autoware_common's Issues

The file "lanelet2_python/internal/converter.h" was not found.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

--- stderr: lanelet2_extension_python
/home/pixbus/HMI/remoteware-robobus/src/autoware/autoware_common/tmp/lanelet2_extension_python/src/utility.cpp:29:10: fatal error: lanelet2_python/internal/converter.h: No such file or directory
29 | #include <lanelet2_python/internal/converter.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake[2]: *** [CMakeFiles/_lanelet2_extension_python_boost_python_utility.dir/build.make:76: CMakeFiles/_lanelet2_extension_python_boost_python_utility.dir/src/utility.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:196: CMakeFiles/_lanelet2_extension_python_boost_python_utility.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

Failed <<< lanelet2_extension_python [4.07s, exited with code 2]

Expected behavior

Error message as above

Actual behavior

Error message as above

Steps to reproduce

colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release

Versions

No response

Possible causes

No response

Additional context

No response

Discuss how to create packages from templates

Currently, Autoware.Auto uses autoware_auto_create_pkg for this.
https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/blob/1111bb025ced60a5399719f079e81933690a7183/src/tools/autoware_auto_create_pkg/package.xml

However, I think it can be replaced by other ways like this because:

• Few people use ros2 run autoware_auto_create_pkg command.
• It can easily check the build warnings/errors of template files.
• It can be used for not only template packages but also template repositories including CI workflows.

`build-and-test.yaml` don't work when pushing to other than `main` or `tier4/proposal`

According to https://github.com/autowarefoundation/autoware_common/blob/tier4/proposal/.github/workflows/build-and-test.yaml#L5-L7`, build-and-test.yamlonly work when pushingmainandtier4/proposal`.

Why don't you add tier4/universe?
Because some of repositories which import it with sync-files workflow has tier4/universe repository as a main branch.

Thank you.

Start using git tags

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Hi,
Since many other projects depend on it, it might be a good idea to start using tags.

Purpose

No build error in related projects

Possible approaches

:D

Definition of done

tagging

Add autoware_lint_common for each package's dependencies

Use autoware_lint_common instead of amant_lint_common to format in clang-format/Black.

Clean folder path `autoware_common/tmp /lanelet2_extension` to `autoware_common/lanelet2_extension`

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I don't know why there is a tmp folder for autoware_common/tmp /lanelet2_extension

Purpose

clean (remove) the tmp folder so that it looks more clean for folder structure

Possible approaches

remove the tmp folder, move lanelet2_extension to its upper path

Definition of done

tmp folder is removed

Job names of build-and-test.yaml and build-and-test-pr.yaml conflict

After #24 is merged, the job names conflict and the Required condition doesn't work correctly.
#21 (comment)

Copy and modify necessary packages from Autoware.Auto

https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/tree/master/src/tools

• autoware_auto_cmake
• autoware_testing
• etc.

Consider the package naming rule for autoware.core and autoware_common

As previously discussed in https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/108, the packages that might be released should have a prefix to be named globally unique.

Since the packages that will be put in this repository might be released, we should decide how to name them.
Also considering the Core/Universe architecture, there would be for example trajectory_follower of Universe and trajectory_follower of Core, therefore it's reasonable to add a prefix to Core packages.

IMO. the candidates of the prefix are autoware_ or aw_.
For the following reasons, I would prefer aw_.

• To keep the package names short.
  • autoware_auto_ is too long.
• To avoid conflicts between the existing packages.
  • Some packages are already named autoware_.
• AW is a well-known abbreviation of Autoware.
  • The Autoware Foundation is called AWF.

FYI, I think what packages are included in autoware_common would be like the following:

• autoware_lint_common (a common lint settings)
• autoware_utils (like https://github.com/ros2/rcutils)
• lanelet2_extension
• autoware_auto_cmake
• autoware_auto_testing
• etc.

Move lanelet2_extension from autowarefoundation/autoware.universe

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Currently, we place lanelet2_extension at autowarefoundation/autoware.universe/map/lanelet2_extension

This cause a problem, for example, scenario_simulator_v2 forked this package to avoid complex CI workflows by referencing autoware.universe repository.
It it not the best approach.

Therefore, it is desired to move widely referenced packages to autoware_common.

Purpose

To remove unnecessary duplicates.

Possible approaches

Move lanelet2_extension from autowarefoundation/autoware.universe to autowarefoundation/autoware_core.

Definition of done

• The package is added to autoware_core.
• The package is removed from autoware.universe.

Consider where to put autoware_auto_msgs

Currently, the original package is here and forked by Tier IV here.

The proposed modifications by Tier IV are sent as MRs, but not fully merged yet.
https://gitlab.com/autowarefoundation/autoware.auto/autoware_auto_msgs/-/merge_requests

We should decide:

• Where to put the packages.
  • If we move to GitHub and only the message is in GitLab, it's confusing.
• Whether to keep using a common autoware_auto_msgs with Autoware.Auto.
  • Keeping the consistency between Autoware.Auto is difficult and it slows down the development speed.
  • The naming of autoware_auto_ is a bit misleading because we adopt Core/Universe architecture.
    • https://discourse.ros.org/t/technical-steering-committee-tsc-meeting-36-2021-11-17-minutes/23168

So I propose creating a new msg repository in GitHub (or putting it into autoware_common) and naming it as autoware_msgs (or aw_msgs as being discussed in #3).