autowarefoundation / autoware Goto Github PK

I'll change the name and year from https://github.com/autowarefoundation/autoware/blob/main/NOTICE depending on the repository's files.

• autoware_common
• autoware.core
• autoware.universe
• autoware_launch
• sample_sensor_kit_launch
• sample_vehicle_launch
• autoware_individual_params
• autoware-github-actions
• autoware-documentation

FYI, to clone these repositories:

repositories:
  autoware:
    type: git
    url: https://github.com/autowarefoundation/autoware.git
    version: main
  autoware_common:
    type: git
    url: https://github.com/autowarefoundation/autoware_common.git
    version: main
  autoware.core:
    type: git
    url: https://github.com/autowarefoundation/autoware.core.git
    version: main
  autoware.universe:
    type: git
    url: https://github.com/autowarefoundation/autoware.universe.git
    version: main
  autoware_launch:
    type: git
    url: https://github.com/autowarefoundation/autoware_launch.git
    version: main
  sample_sensor_kit_launch:
    type: git
    url: https://github.com/autowarefoundation/sample_sensor_kit_launch.git
    version: main
  sample_vehicle_launch:
    type: git
    url: https://github.com/autowarefoundation/sample_vehicle_launch.git
    version: main
  autoware_individual_params:
    type: git
    url: https://github.com/autowarefoundation/autoware_individual_params.git
    version: main
  autoware-github-actions:
    type: git
    url: https://github.com/autowarefoundation/autoware-github-actions.git
    version: main
  autoware-documentation:
    type: git
    url: https://github.com/autowarefoundation/autoware-documentation.git
    version: main

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

2022-01-08T18:56:43.4386749Z TASK [autoware.dev_env.ros2 : Install ros-galactic-desktop] ********************
2022-01-08T18:59:11.7105352Z ##[warning]You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 15 MB

Or, the capacity allocated for Docker images is too small.

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

As described in #370 (comment) it makes sense to move external repositories to src/external for easier maintenance

Purpose

Move repositories to src/external

Possible approaches

Update .repos file so that external repositories are cloned to src/external

Definition of done

All external repositories are cloned to src/external

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

https://github.com/autowarefoundation/autoware/runs/6212294556?check_suite_focus=true#step:6:4715

Expected behavior

No failure.

Actual behavior

It failed.

Steps to reproduce

Run the workflow.

Versions

No response

Possible causes

No response

Additional context

I'll re-run the CI after a while.

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 have managed to run autoware in jetson AGX and everything seems to work well!
the only thing I am looking for is that how to send the output of the lidar via UDP!
what I mean is that I used autoware to detect and track objects using lidar only
is there any way to make the output send thro udp
like xyz

Purpose

to run with a new contral unit

Possible approaches

using autoware with different robot not only a car

Definition of done

autwoare is installed

Is there any sample bag file to try autoware software-suites?

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: traffic_light_classifier
CMake Error at ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:100 (message):
ament_cmake_symlink_install_directory() can't find
'/home/autoware/src/universe/autoware.universe/perception/traffic_light_classifier/data'
Call Stack (most recent call first):
ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:332 (ament_cmake_symlink_install_directory)
cmake_install.cmake:41 (include)

Expected behavior

--- stderr: traffic_light_classifier
CMake Error at ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:100 (message):
ament_cmake_symlink_install_directory() can't find
'/home/autoware/src/universe/autoware.universe/perception/traffic_light_classifier/data'
Call Stack (most recent call first):
ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:332 (ament_cmake_symlink_install_directory)
cmake_install.cmake:41 (include)

Actual behavior

--- stderr: traffic_light_classifier
CMake Error at ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:100 (message):
ament_cmake_symlink_install_directory() can't find
'/home/autoware/src/universe/autoware.universe/perception/traffic_light_classifier/data'
Call Stack (most recent call first):
ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:332 (ament_cmake_symlink_install_directory)
cmake_install.cmake:41 (include)

Steps to reproduce

--- stderr: traffic_light_classifier
CMake Error at ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:100 (message):
ament_cmake_symlink_install_directory() can't find
'/home/autoware/src/universe/autoware.universe/perception/traffic_light_classifier/data'
Call Stack (most recent call first):
ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:332 (ament_cmake_symlink_install_directory)
cmake_install.cmake:41 (include)

Versions

No response

Possible causes

No response

Additional context

No response

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

When doing a clean build of any perception packages that require trained model ONNX files (eg: lidar_apollo_instance_segmentation), a permission denied error occurs when gdown tries to download the files from Google Drive.

Expected behavior

ONNX files should be downloaded as expected and the perception packages should build without error

Actual behavior

gdown reports a permission denied error

Steps to reproduce

I am not sure how to reproduce the issue short of doing a complete clean build of Autoware

Versions

• OS: Ubuntu 20.04
• ROS 2: Galactic
• Autoware: Universe
• gdown: 4.4.0

Possible causes

The theory is that there is a limit to the number of requests that can be made via Google Drive API, and downloads via gdown will fail when the limit is hit.

Additional context

No response

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

I'm following How to update a workspace.
In order to update repos, it says we command

vcs import src < autoware.repos
vcs pull

However, it seems it ignores under src directory because of .gitignore.
Thus we should command as follows?

vcs import src < autoware.repos
vcs pull src

Expected behavior

Updating repos by vcs pull

Actual behavior

No repos updated by vcs pull

Steps to reproduce

Follow How to update a workspace

Versions

No response

Possible causes

No response

Additional context

No response

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

After #340, the image size is too large because unnecessary packages are installed.

https://github.com/autowarefoundation/autoware/pkgs/container/autoware-universe/22935531?tag=humble-latest-arm64

Purpose

To reduce the size.

Possible approaches

Select which packages to install.

Definition of done

The image size is compressed.

Opened by this comment: #29 (comment)

Reference links:

• https://opensource.google/docs/copyright/#the-year
• https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/
• https://www.apache.org/legal/src-headers.html
• https://www.apache.org/foundation/license-faq.html
• https://infra.apache.org/licensing-howto.html
• https://www.apache.org/licenses/LICENSE-2.0

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

Installation of ros-humble-desktop fails.
https://github.com/autowarefoundation/autoware/runs/7851163697?check_suite_focus=true#step:5:1924

#18 155.6 TASK [autoware.dev_env.ros2 : Install ros-humble-desktop] **********************
#18 161.1 fatal: [localhost]: FAILED! => {"cache_update_time": 1660626759, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"       install 'ros-humble-desktop'' failed: E: Unable to correct problems, you have held broken packages.\n", "rc": 100, "stderr": "E: Unable to correct problems, you have held broken packages.\n", "stderr_lines": ["E: Unable to correct problems, you have held broken packages."], "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSome packages could not be installed. This may mean that you have\nrequested an impossible situation or if you are using the unstable\ndistribution that some required packages have not yet been created\nor been moved out of Incoming.\nThe following information may help to resolve the situation:\n\nThe following packages have unmet dependencies:\n libignition-math6-dev : Depends: libignition-cmake2-dev (>= 2.13.0) but 2.12.1-2~jammy is to be installed\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information...", "Some packages could not be installed. This may mean that you have", "requested an impossible situation or if you are using the unstable", "distribution that some required packages have not yet been created", "or been moved out of Incoming.", "The following information may help to resolve the situation:", "", "The following packages have unmet dependencies:", " libignition-math6-dev : Depends: libignition-cmake2-dev (>= 2.13.0) but 2.12.1-2~jammy is to be installed"]}

Expected behavior

Installation succeeds.

Actual behavior

Installation fails.

Steps to reproduce

git clone [email protected]:autowarefoundation/autoware.git -b humble
cd autoware
./docker/build.sh

The error log is as follows:

#17 119.1 TASK [autoware.dev_env.ros2 : Install ros-humble-desktop] **********************
#17 122.7 fatal: [localhost]: FAILED! => {"cache_update_time": 1660627442, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"       install 'ros-humble-desktop'' failed: E: Unable to correct problems, you have held broken packages.\n", "rc": 100, "stderr": "E: Unable to correct problems, you have held broken packages.\n", "stderr_lines": ["E: Unable to correct problems, you have held broken packages."], "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSome packages could not be installed. This may mean that you have\nrequested an impossible situation or if you are using the unstable\ndistribution that some required packages have not yet been created\nor been moved out of Incoming.\nThe following information may help to resolve the situation:\n\nThe following packages have unmet dependencies:\n libignition-math6-dev : Depends: libignition-cmake2-dev (>= 2.13.0) but 2.12.1-2~jammy is to be installed\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information...", "Some packages could not be installed. This may mean that you have", "requested an impossible situation or if you are using the unstable", "distribution that some required packages have not yet been created", "or been moved out of Incoming.", "The following information may help to resolve the situation:", "", "The following packages have unmet dependencies:", " libignition-math6-dev : Depends: libignition-cmake2-dev (>= 2.13.0) but 2.12.1-2~jammy is to be installed"]}
#17 122.7
#17 122.7 PLAY RECAP *********************************************************************
#17 122.7 localhost                  : ok=9    changed=5    unreachable=0    failed=1    skipped=1    rescued=0    ignored=0
#17 122.7
#17 122.7 Failed.
#17 ERROR: executor failed running [/bin/bash -o pipefail -c ./setup-dev-env.sh -y $SETUP_ARGS universe   && pip uninstall -y ansible ansible-core   && mkdir src   && vcs import src < autoware.repos   && rosdep update   && DEBIAN_FRONTEND=noninteractive rosdep install -y --ignore-src --from-paths src --rosdistro "$ROS_DISTRO"   && apt-get clean   && rm -rf /var/lib/apt/lists/*]: exit code: 1
------
 > [devel devel  8/14] RUN --mount=type=ssh   ./setup-dev-env.sh -y --no-cuda-drivers universe   && pip uninstall -y ansible ansible-core   && mkdir src   && vcs import src < autoware.repos   && rosdep update   && DEBIAN_FRONTEND=noninteractive rosdep install -y --ignore-src --from-paths src --rosdistro "humble"   && apt-get clean   && rm -rf /var/lib/apt/lists/*:
#17 115.8 TASK [autoware.dev_env.ros2 : Add ROS 2 apt repository to source list] *********
#17 119.1 changed: [localhost]
#17 119.1
#17 119.1 TASK [autoware.dev_env.ros2 : Install ros-humble-desktop] **********************
#17 122.7 fatal: [localhost]: FAILED! => {"cache_update_time": 1660627442, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"       install 'ros-humble-desktop'' failed: E: Unable to correct problems, you have held broken packages.\n", "rc": 100, "stderr": "E: Unable to correct problems, you have held broken packages.\n", "stderr_lines": ["E: Unable to correct problems, you have held broken packages."], "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSome packages could not be installed. This may mean that you have\nrequested an impossible situation or if you are using the unstable\ndistribution that some required packages have not yet been created\nor been moved out of Incoming.\nThe following information may help to resolve the situation:\n\nThe following packages have unmet dependencies:\n libignition-math6-dev : Depends: libignition-cmake2-dev (>= 2.13.0) but 2.12.1-2~jammy is to be installed\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information...", "Some packages could not be installed. This may mean that you have", "requested an impossible situation or if you are using the unstable", "distribution that some required packages have not yet been created", "or been moved out of Incoming.", "The following information may help to resolve the situation:", "", "The following packages have unmet dependencies:", " libignition-math6-dev : Depends: libignition-cmake2-dev (>= 2.13.0) but 2.12.1-2~jammy is to be installed"]}
#17 122.7
#17 122.7 PLAY RECAP *********************************************************************
#17 122.7 localhost                  : ok=9    changed=5    unreachable=0    failed=1    skipped=1    rescued=0    ignored=0
#17 122.7
#17 122.7 Failed.
------
error: failed to solve: executor failed running [/bin/bash -o pipefail -c ./setup-dev-env.sh -y $SETUP_ARGS universe   && pip uninstall -y ansible ansible-core   && mkdir src   && vcs import src < autoware.repos   && rosdep update   && DEBIAN_FRONTEND=noninteractive rosdep install -y --ignore-src --from-paths src --rosdistro "$ROS_DISTRO"   && apt-get clean   && rm -rf /var/lib/apt/lists/*]: exit code: 1

Versions

• ROS 2: Humble

Possible causes

Some released packages might be broken.

Additional context

A similar issue that happened recently.
https://answers.ros.org/question/402781/ros-humble-ubuntu-2204-apt-install-issue/

The CI succeeded yesterday and failed today.
https://github.com/autowarefoundation/autoware/actions/runs/2857649523
https://github.com/autowarefoundation/autoware/actions/runs/2865405553

As pointed out here, it's useful if we can run scenario testing on CI.

We can use TIER IV's Autoware Evaluator for this use case.
In that case, we need to add .webauto-ci.yml to this repository.
https://github.com/tier4/AutowareArchitectureProposal.proj/blob/474da436880f93bd59d87107bd9d83254b0cd9b3/.webauto-ci.yml
https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/blob/635b36e0b461f66f25fd4a9c30231ca5f129e5db/.webauto-ci.yml

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

Enable multi-stage builds for Autoware (eg: using Docker Compose or another similar tool).

Purpose

Lay the ground work, with the right tool, to enable building Autoware.Universe as a microservices architecture.

Possible approaches

• Use Docker Compose (this is the tool assumed in the definition of done steps below)

From https://docs.docker.com/compose/:
Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

Definition of done

• Create a new script build-compose.sh that uses Docker Compose to build an Autoware container as a multi-stage build (the current local build script is /autowarefoundation/autoware/docker/build.sh)
• Submit a PR to the Autoware repository with the new build-compose.sh file and request a review from @kenji-miyake
• Replace the existing build.sh script for local builds
• Update the existing workflows/actions to use Docker Compose for Docker images built with GitHub Actions
  • https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/build.yaml
  • https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/build-self-hosted.yaml
  • https://github.com/autowarefoundation/autoware/blob/main/.github/actions/docker-build-and-push/action.yaml

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

The obstacle avoidance marker is busy by default.

In TIER IV, The fix for the obstacle avoidance marker has been incorporated but not in the awf repository.

Purpose

The debug visualization is turned off by default, for easier to see.

Possible approaches

modify rviz config

Definition of done

The debugging visualization in avoidance is turned off.

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

add allow-change-held-packages option here .
Unfortunately ansible 2.13 has not been released yet, where allow-change-held-packages option is implemented, so I will this option after ansible 2.13 is released.

Purpose

To prevent the problem described in #154 (comment).

Possible approaches

add allow-change-held-packages option here .

Definition of done

• add allow-change-held-packages option here .

I'd like to propose the improvement on Dockerfile to modify the code on the host environment rather than on a container.

Current Dockerfile on the add-docker branch expects to modify the code on a container rather than the host. But it is inefficient to set up the development environment and change the code on a container.
So I propose modifying the files on the host, mounting src on a container, and running autoware on the container.

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

With this branches/tags,

It will create multiple releases.

Expected behavior

The second trial should update the existing release that has the same name.

Actual behavior

Another release is created.

Steps to reproduce

1. Create a tag.
2. Create and push a beta branch.
3. Add a commit to the branch and push again.

Versions

No response

Possible causes

I should have used gh release edit for the second trial.
https://cli.github.com/manual/gh_release_edit

Additional context

No response

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

The pull request (PR link) has been approved but it fails to proceed due to the dependency of the package, morai_msgs.
At first, the morai_msgs package was in [autoware.universe/tools/simulator_test/]. but in the simulation working group, it was decided to remove it and then, append it to autoware.repos to maintain consistency with other packages.

Purpose

Since the pull request (PR link) has been approved but failed to be built, the morai_msgs package would be added to autoware.repos for further steps.

Possible approaches

None.

Definition of done

the morai_msgs package is listed on the autoware.repos.

Currently autoware_auto_msgs repository for universe and core is located in tier4 group.
I think the repository should be in autowarefoundation group.

Discussed in #120

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

Originated from discussion posted by @kasperornmeck in #2780_

Purpose

Reduce docker images size for runtime environment where unnecessary software could be removed from development environment and reduce the disk space used.

Current status

Details of the container used in the analysis:

REPOSITORY: ghcr.io/autowarefoundation/autoware-universe
TAG: galactic-20220728-prebuilt-cuda-arm64
IMAGE ID: 8b7fbc56f6bf
CREATED: 8 days ago
SIZE: 19.3GB

Definition of done

• runtime dependencies analysis
• reduce sized docker image for runtime

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

In autoware documentation page, Ccache is recommended to speed up recompilation. See here.

Purpose

• Add Ccache into docker image to speed up recompilation.

Possible approaches

• Adding Ccache in Ansible.

Definition of done

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 add configuration file for TIER IV's CI/CD Pipeline.
The configuration file can contain the following

• Build type, which determines what type of build will be performed.
• The type of simulation to run and its runtime arguments.

Purpose

Additional settings for testing Simulation in the CI/CD pipeline of TIER IV.

Possible approaches

add configuration.

Definition of done

Confiugration file is added.

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

ROS 2 Humble will be released this May.
https://docs.ros.org/en/rolling/Releases/Release-Humble-Hawksbill.html

To smoothly transit to Humble, it's good to support Rolling before that.

Related: autowarefoundation/autoware.universe#268

Purpose

To smoothly transit to Humble.

Possible approaches

Replace all Galactic-dependent parts with the new styles.

Definition of done

Autoware's tutorials work with ROS 2 Rolling on Ubuntu 22.04.

If I run ./setup-dev-env.sh docker multiple times, duplicated entries are written.

$ cat /etc/apt/sources.list.d/nvidia-docker.list
deb https://nvidia.github.io/libnvidia-container/stable/ubuntu18.04/$(ARCH) /
# deb https://nvidia.github.io/libnvidia-container/experimental/ubuntu18.04/$(ARCH) /
deb https://nvidia.github.io/nvidia-container-runtime/stable/ubuntu18.04/$(ARCH) /
# deb https://nvidia.github.io/nvidia-container-runtime/experimental/ubuntu18.04/$(ARCH) /
deb https://nvidia.github.io/nvidia-docker/ubuntu18.04/$(ARCH) /

deb https://nvidia.github.io/libnvidia-container/stable/ubuntu18.04/$(ARCH) /
#deb https://nvidia.github.io/libnvidia-container/experimental/ubuntu18.04/$(ARCH) /
deb https://nvidia.github.io/nvidia-container-runtime/stable/ubuntu18.04/$(ARCH) /
#deb https://nvidia.github.io/nvidia-container-runtime/experimental/ubuntu18.04/$(ARCH) /
deb https://nvidia.github.io/nvidia-docker/ubuntu18.04/$(ARCH) /

deb https://nvidia.github.io/libnvidia-container/stable/ubuntu18.04/$(ARCH) /
#deb https://nvidia.github.io/libnvidia-container/experimental/ubuntu18.04/$(ARCH) /
deb https://nvidia.github.io/nvidia-container-runtime/stable/ubuntu18.04/$(ARCH) /
#deb https://nvidia.github.io/nvidia-container-runtime/experimental/ubuntu18.04/$(ARCH) /
deb https://nvidia.github.io/nvidia-docker/ubuntu18.04/$(ARCH) /

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

The push condition is false in scheduled jobs.
https://github.com/autowarefoundation/autoware/runs/7830173853?check_suite_focus=true#step:5:491

Therefore, even though the workflow has passed, the new images aren't pushed.

Expected behavior

The push condition should be true.

Actual behavior

The push condition is false.

Steps to reproduce

Trigger Docker CI workflows with the schedule event.

Versions

No response

Possible causes

This condition is wrong.

Additional context

No response

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

See https://github.com/autowarefoundation/autoware_common/runs/6220775368?check_suite_focus=true#step:6:16

Expected behavior

No error.

Actual behavior

Run sudo apt-get -yqq update
W: GPG error: https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A4B469963BF863CC
E: The repository 'https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  InRelease' is not signed.
Error: Process completed with exit code 100.

Steps to reproduce

Run the workflow.

Versions

No response

Possible causes

• Update the key.
• Remove CUDA from the source list after installation.

Additional context

• https://forums.developer.nvidia.com/t/notice-cuda-linux-repository-key-rotation/212772/1
• https://forums.developer.nvidia.com/t/updating-the-cuda-linux-gpg-repository-key/212897
• https://forums.developer.nvidia.com/t/invalid-public-key-for-cuda-apt-repository/212901
• NVIDIA/nvidia-container-toolkit#258

Currently, sensor_kit description/launch are separated, but vehicle description/launch are combined, which is not consistent.

sensor_kit

• https://github.com/tier4/aip_description.iv
• https://github.com/tier4/AutowareArchitectureProposal_aip_launcher

vehicle

• https://github.com/tier4/lexus_description.iv

We can reconsider the structure and naming.

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 will create 2 docker containers that will pull the universe and build selected packages separated by their basic functionality.

Container contents:

• Container 1:
  • drivers, sensing, perception, localization
• Container 2:
  • planning, control

The reason we split them this way is to ensure we minimize the data transfer overhead between containers.

Purpose

To prototype the first multi-container version of the Autoware Universe for Open AD Kit.

Possible approaches

I will first test them out on my local machine. Then maybe we can set-up the CI but I am not sure yet.

Definition of done

• Decide what packages are required for the container

• First container:

  • Create the dockerfile like in here: https://github.com/autowarefoundation/autoware/blob/main/docker/autoware-universe/Dockerfile
  • Make sure the respective tutorials run with the autoware builds:
    • https://autowarefoundation.github.io/autoware-documentation/main/tutorials/ad-hoc-simulation/rosbag-replay-simulation/

• Second container:

  • Create the dockerfile like in here: https://github.com/autowarefoundation/autoware/blob/main/docker/autoware-universe/Dockerfile
  • Make sure the respective tutorials run with the autoware builds:
    • https://autowarefoundation.github.io/autoware-documentation/main/tutorials/ad-hoc-simulation/planning-simulation/

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

In the current universe image, vulkaninfo cannot detect host GPU. This might cause simulator to crash in the future. This happens as I was trying to run svl using the universe docker image. I understand svl is going down very soon. But this error would possibly affect future development with simulator which might require vulkan driver. I have not figured out a fix. Please feel free to make comments if you have any idea.
By comparing the vulkaninfo output, you can see that problematic output, which is the output of universe image, does not detect GPU correctly.

Expected behavior

Being able to start simulator.
Below is the correct output.

==========
VULKANINFO
==========

Vulkan Instance Version: 1.2.131


Instance Extensions: count = 18
====================
	VK_EXT_acquire_xlib_display            : extension revision 1
	VK_EXT_debug_report                    : extension revision 10
	VK_EXT_debug_utils                     : extension revision 2
	VK_EXT_direct_mode_display             : extension revision 1
	VK_EXT_display_surface_counter         : extension revision 1
	VK_KHR_device_group_creation           : extension revision 1
	VK_KHR_display                         : extension revision 23
	VK_KHR_external_fence_capabilities     : extension revision 1
	VK_KHR_external_memory_capabilities    : extension revision 1
	VK_KHR_external_semaphore_capabilities : extension revision 1
	VK_KHR_get_display_properties2         : extension revision 1
	VK_KHR_get_physical_device_properties2 : extension revision 2
	VK_KHR_get_surface_capabilities2       : extension revision 1
	VK_KHR_surface                         : extension revision 25
	VK_KHR_surface_protected_capabilities  : extension revision 1
	VK_KHR_wayland_surface                 : extension revision 6
	VK_KHR_xcb_surface                     : extension revision 6
	VK_KHR_xlib_surface                    : extension revision 6

Layers: count = 4
=======
VK_LAYER_LUNARG_standard_validation (LunarG Standard Validation Layer) Vulkan version 1.0.131, layer version 1:
	Layer Extensions: count = 0
	Devices: count = 2
		GPU id 	: 0 (NVIDIA GeForce RTX 3070 Ti)
		Layer-Device Extensions: count = 0

		GPU id 	: 1 (llvmpipe (LLVM 12.0.0, 256 bits))
		Layer-Device Extensions: count = 0

VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan version 1.2.73, layer version 1:
	Layer Extensions: count = 0
	Devices: count = 2
		GPU id 	: 0 (NVIDIA GeForce RTX 3070 Ti)
		Layer-Device Extensions: count = 0

		GPU id 	: 1 (llvmpipe (LLVM 12.0.0, 256 bits))
		Layer-Device Extensions: count = 0

Actual behavior

Problematic output.

==========
VULKANINFO
==========

Vulkan Instance Version: 1.2.131


Instance Extensions: count = 18
====================
	VK_EXT_acquire_xlib_display            : extension revision 1
	VK_EXT_debug_report                    : extension revision 10
	VK_EXT_debug_utils                     : extension revision 1
	VK_EXT_direct_mode_display             : extension revision 1
	VK_EXT_display_surface_counter         : extension revision 1
	VK_KHR_device_group_creation           : extension revision 1
	VK_KHR_display                         : extension revision 23
	VK_KHR_external_fence_capabilities     : extension revision 1
	VK_KHR_external_memory_capabilities    : extension revision 1
	VK_KHR_external_semaphore_capabilities : extension revision 1
	VK_KHR_get_display_properties2         : extension revision 1
	VK_KHR_get_physical_device_properties2 : extension revision 2
	VK_KHR_get_surface_capabilities2       : extension revision 1
	VK_KHR_surface                         : extension revision 25
	VK_KHR_surface_protected_capabilities  : extension revision 1
	VK_KHR_wayland_surface                 : extension revision 6
	VK_KHR_xcb_surface                     : extension revision 6
	VK_KHR_xlib_surface                    : extension revision 6

Layers: count = 3
=======
VK_LAYER_LUNARG_standard_validation (LunarG Standard Validation Layer) Vulkan version 1.0.131, layer version 1:
	Layer Extensions: count = 0
	Devices: count = 1
		GPU id 	: 0 (llvmpipe (LLVM 12.0.0, 256 bits))
		Layer-Device Extensions: count = 0

VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan version 1.2.73, layer version 1:
	Layer Extensions: count = 0
	Devices: count = 1
		GPU id 	: 0 (llvmpipe (LLVM 12.0.0, 256 bits))
		Layer-Device Extensions: count = 0

VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.1.73, layer version 1:
	Layer Extensions: count = 0
	Devices: count = 1
		GPU id 	: 0 (llvmpipe (LLVM 12.0.0, 256 bits))
		Layer-Device Extensions: count = 0

Steps to reproduce

sudo apt update
sudo apt install vulkan-tools -y
vulkaninfo 2>&1 | a.txt
vi a.txt

Versions

Docker images

Possible causes

No response

Additional context

No response

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

When I run setup-dev-env.sh docker for the first time, the following error occurs:

nv@xavier-5:~/ws/autoware$ ./setup-dev-env.sh docker
Setting up the build environment take up to 1 hour.
>  Are you sure to run the setup? [y/N] y
./setup-dev-env.sh: line 105: ansible-galaxy: command not found

Expected behavior

The script should run without error

Actual behavior

Error occured and stopped.

Steps to reproduce

1. CLone project
2. Run ./setup-dev-env.sh docker

Versions

• OS: Ubuntu 20.04
• ROS2: Galactic
• Autoware: main

Possible causes

ansible was previously installed under user account, but not under root account. This may cause the version check to pass, but ansible-galaxy not found by root account.

Additional context

No response

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

https://github.com/autowarefoundation/autoware/runs/6556147878?check_suite_focus=true#step:7:5706

--- stderr: grid_map_core
In file included from /usr/include/eigen3/Eigen/Core:214,
                 from /autoware/src/universe/vendor/grid_map/grid_map_core/include/grid_map_core/GridMap.hpp:13,
                 from /autoware/src/universe/vendor/grid_map/grid_map_core/include/grid_map_core/iterators/PolygonIterator.hpp:14,
                 from /autoware/src/universe/vendor/grid_map/grid_map_core/src/iterators/PolygonIterator.cpp:11:
/usr/include/eigen3/Eigen/src/Core/arch/NEON/PacketMath.h: In function ‘Packet Eigen::internal::pload(const typename Eigen::internal::unpacket_traits<T>::type*) [with Packet = Eigen::internal::eigen_packet_wrapper<int, 2>; typename Eigen::internal::unpacket_traits<T>::type = signed char]’:
/usr/include/eigen3/Eigen/src/Core/arch/NEON/PacketMath.h:1671:9: error: ‘void* memcpy(void*, const void*, size_t)’ copying an object of non-trivial type ‘Eigen::internal::Packet4c’ {aka ‘struct Eigen::internal::eigen_packet_wrapper<int, 2>’} from an array of ‘const int8_t’ {aka ‘const signed char’} [-Werror=class-memaccess]
 1671 |   memcpy(&res, from, sizeof(Packet4c));
      |   ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/eigen3/Eigen/Core:172,
                 from /autoware/src/universe/vendor/grid_map/grid_map_core/include/grid_map_core/GridMap.hpp:13,
                 from /autoware/src/universe/vendor/grid_map/grid_map_core/include/grid_map_core/iterators/PolygonIterator.hpp:14,
                 from /autoware/src/universe/vendor/grid_map/grid_map_core/src/iterators/PolygonIterator.cpp:11:
/usr/include/eigen3/Eigen/src/Core/GenericPacketMath.h:159:8: note: ‘Eigen::internal::Packet4c’ {aka ‘struct Eigen::internal::eigen_packet_wrapper<int, 2>’} declared here
  159 | struct eigen_packet_wrapper
      |        ^~~~~~~~~~~~~~~~~~~~

Expected behavior

No error.

Actual behavior

There are errors when building grid_map_core.

Steps to reproduce

docker run --rm -it ghcr.io/autowarefoundation/autoware-universe:humble-latest-arm64
colcon build --symlink-install --cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release --packages-up-to grid_map_core

Versions

• ROS 2 Humble
• arm64

Possible causes

No response

Additional context

No response

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

When I run a docker container built on this repository with rocker, nvidia-smi and CUDA packages of autoware.universe didn't work.

Expected behavior

$ rocker --nvidia --x11 --user ghcr.io/autowarefoundation/autoware-universe:humble-latest nvidia-smi

returns the same result as

docker run --rm -it --gpus all -e DISPLAY -e TERM -e QT_X11_NO_MITSHM=1 -v /tmp/.X11-unix:/tmp/.X11-unix -v /etc/localtime:/etc/localtime:ro ghcr.io/autowarefoundation/autoware-universe:humble-latest

Actual behavior

$ rocker --nvidia --x11 --user --volume $PWD:$HOME/autoware -- ghcr.io/autowarefoundation/autoware-universe:humble-latest nvidia-smi
...
bash: nvidia-smi: command not found

or

# in the docker container
$ ros2 launch lidar_centerpoint lidar_centerpoint.launch.xml
[INFO] [launch]: All log files can be found below /home/yusuke/.ros/log/2022-05-27-18-24-13-889706-yusuke-desktop-14888
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [lidar_centerpoint_node-1]: process started with pid [14889]
[lidar_centerpoint_node-1] terminate called after throwing an instance of 'thrust::system::detail::bad_alloc'
[lidar_centerpoint_node-1]   what():  std::bad_alloc: cudaErrorInsufficientDriver: CUDA driver version is insufficient for CUDA runtime version
[ERROR] [lidar_centerpoint_node-1]: process has died [pid 14889, exit code -6, cmd '/home/yusuke/autoware/install/lidar_centerpoint/lib/lidar_centerpoint/lidar_centerpoint_node --ros-args -r __node:=lidar_centerpoint --params-file /tmp/launch_params__7bviznb --params-file /tmp/launch_params_xhbpo0pj --params-file /tmp/launch_params_3cva1bu7 --params-file /tmp/launch_params_591wukuf --params-file /tmp/launch_params_binyjp_2 --params-file /tmp/launch_params_d_ubfmz8 --params-file /tmp/launch_params_3ciwtkcg --params-file /tmp/launch_params_cy1qmkld --params-file /home/yusuke/autoware/install/lidar_centerpoint/share/lidar_centerpoint/config/default.param.yaml -r ~/input/pointcloud:=/sensing/lidar/pointcloud -r ~/output/objects:=objects'].

Steps to reproduce

1. build a docker image in docker directory
2. run a docker container with rocker
3. nvidia-smi

Versions

No response

Possible causes

No response

Additional context

No response

The current commit history is automatically generated when merging, but it creates many lines and makes it harder to catch up on what is going on. So I'd like to propose formulating a commit message guideline for better commit history.

I think we should explicitly define what we should include in the commit history and what we don't include. We can refer to other OSS contribution guidelines.

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

We have done some work to analyze and calculate the execution time of the function nodes using the ros2_tracing and tracecompass.

At present,we have analyzed the planning module across planning_simulator on adlink.

The statistical results of some nodes

node: time

mission_planner: 1s(loading the vector map and mission_planning)
behavoir_path: 7ms;
behavior_velocity: 2ms
obstacle_avoidance: (normal:1ms ,replan:18ms)
obstacle_stop: 1.5ms
motion_velocity: 16ms
surround_obstacle: 900μs
scenario_select: 300μs

Purpose

1.When the self-driving vehicle is abnormal, the suspicious node can be found according it.
2.Find out the nodes with long execution time in modules and optimize the algorithm if it affects the system
3.Offer some suggestion about the design and deployment for bus odd

Possible approaches

tools:
https://gitlab.com/ros-tracing/ros2_tracing
https://www.eclipse.org/tracecompass/

Definition of done

execution time of the function nodes

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

We are going to integrate Autoware into the diff-drive robot.

Prerequirements:

We have diff-drive robot with sensor attached.
We have motor drive interface.

Purpose

The diff-drive robot will be implemented with automatic driving functions.

Possible approaches

With simulation

• spawn the urdf on the Rviz
• change the controller to diff-drive type
• planning simulation using the urdf

With robot

• command the diff-drive robot with Autoware
• control the diff-drive robot with Autoware
• sensing with Autoware
• localization with Autoware
• apply plannning simulation to real robot

Definition of done

We don't know what we can do with Autoware right now, so we're integrating Autoware with diff-drive robots to investigate what it can do. For example,

• The diff-drive robot drives autonomously in a room.
  • reach goal
  • avoid obstacle
  • change lane (option)　
  • parking

Related discussion

#170
https://github.com/autowarefoundation/autoware/discussions/173
#183,
#186,
#189,
#174,
#188,
#194,
#196,
#197,
#198,
#199

enable open cda workflow

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

PlotJugger installation was added in #243.

But it has a problem, it can't be used if it's not released.
So if we add the source in autoware.repos, it will still cause an error.

Since it's low-priority for Galactic, it's okay if we work on it after we move to Humble.

Purpose

To prevent an error when it's not released.

Possible approaches

It can be resolved by adding exec_depend to some packages as explained in https://github.com/orgs/autowarefoundation/discussions/235#discussioncomment-2638505.

There are some choices for where to place the depends.

• autoware_launch
• autoware_common/dev_tools (A new package)
• etc.

Considering many packages depend on autoware_common, is autoware_launch better?

Definition of done

• Where to place the depends is agreed.
• The depends are added.
• The behavior is confirmed.

libembree-dev can't be installed on ARM.
#8 (comment)

• Build embree manually
• Run rosdep install with --skip-keys=embree

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

lidar_centerpoint model can not download model automatically due to LIB_TORCH NOT FOUND

Expected behavior

lidar_centerpoint model can download model automatically

Actual behavior

lidar_centerpoint model can not download model automatically due to LIB_TORCH NOT FOUND

Steps to reproduce

ros2 launch tier4_perception_launch perception.launch.xml mode:=lidar

output is :
[WARNING] [launch_ros.actions.node]: Parameter file path is not a file: /autoware/install/lidar_centerpoint/share/lidar_centerpoint/config/default.param.yaml

Versions

ROS2

Possible causes

No response

Additional context

No response

The current Dockerfile doesn't install kvaser-interface even autoware.universe requires it

To install kvaser-interface we need to explicitly add the repository as in the installation procedure so we need to update the ansible playbook

lidar_centerpoint cannot be built on Docker since the current Dockerfile doesn't install libtorch.

lidar_centerpoint explicitly requires libtorch installation to build the executable so we need to add the lines to download and install libtorch on the Dockerfile or ansible.

I'm wondering if there is any cmd existing in universe such that we could enter a specific docker container from another terminal. For example, when we were using ade in Auto, if an environment has been created, we can simply type ade enter from another terminal. I understand that we could use docker exec --it container id to enter the same image from another terminal. It seems that when I was using rocker, the container was created on the fly without a tag. I think it would be good to have some other simple cmd as ade does to enter the created container rather than copy and paste an temporary id.

• Set up https://github.com/autowarefoundation/autoware
• Set up https://github.com/autowarefoundation/autoware_launch if necessary -> It was not mandatory.
• autowarefoundation/autoware.universe#204

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

A follow-up for #2435.

Purpose

To support ROS 2 Humble.

Possible approaches

Improve autowarefoundation/autoware_core_universe_prototype#248.

Definition of done

Autoware's Humble Docker image is published.

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

Hi,

The current steps for install Autoware.Universe via docker is wrong. The manual is hosted on Autoware's website and not here.
Can I post the correct steps here and someone can update the documentation over on Autoware?

Expected behavior

Installing with the current documentation will result in the following error:

• CUDA not found
• CUDNN not found
• TensorRT not found
• nvdia-smi and cuda version missmatch
• unable to upgrade cuda tools due to invalid cross link device
• rocker no longer has the cuda commands.
• colcon build fails on cpluplus due to memory contraints.

Actual behavior

Should have installed correctly and built correctly.

Steps to reproduce

Follow documentation

Versions

OS: Ubuntu 20.04
CUDA: 11.6
Rocker: 2.10

Possible causes

Stated Above.

Additional context

Stated Above.

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

scenario_simulator_v2 depends on libzmqpp-dev package in ubuntu, this package supports in focal but not supported in jammy.
In order to support humble and ubuntu jammy (22.04), we have to resolve this dependency.

Purpose

Support humble and ubuntu jammy.

Possible approaches

adding zmqpp_vendor package in simulator.repos file.
I already made a draft pull-request for this approach. #350

Definition of done

Resolve zmqpp dependency in ROS2 humble and Ubuntu Jammy(22.04).

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

"All versions prior to CUDA Toolkit 11.6 Update 2" have a security risk.

https://nvidia.custhelp.com/app/answers/detail/a_id/5334

Purpose

To resolve the risk.

Possible approaches

Update the versions in ansible/playbooks/universe.yaml.

Definition of done

The versions are updated and the build CI passes.

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 install CUDA using setup-dev-env.sh, but it creates different layers and enforces people to pull a large part of the image every time.

To avoid that, it's better to have a common base image.

Purpose

To minimize the differences between Autoware's Docker Images.

Possible approaches

• Wait for NVIDIA to release a new image and deb packages, and use them. (Recommended)
  • We might have to add the --no-cuda option to setup-dev-env.sh.
• Create a common Autoware base image.

Definition of done

Autoware's Docker Images are based on a common base image.