Hi @evshary
I'm currently running Autoware with Carla following the documentation of this repository (branch: humble)
I set everything correctly following the instruction, but when I set the goal position on RVIZ, it seems Autoware and Carla are not communicating well..
Here is the link to the video to show the situation:
https://drive.google.com/file/d/1bO2ef6-LXW9Zwt4_nTf0vuX-jLRm2gCa/view?usp=sharing

I also observed that, even though the car made a bit sharper turn, it eventually collides with the bridge on the right side (which means the car does not steer to the left)

I do not know about how to make a log file regarding Autoware or bridge, but I'll do my best to make the situation crystal clear.
I just need your help. Thank you in advance!

Here is my environment and running command:

• OS: Ubuntu 20.04
• Carla Version: 0.9.13
• I slightly modified the bridge script (options like --sync, --autopilot, --pygame and --position) and other commands are the same with that of the documentation.

#!/bin/bash
PYTHON_AGENT_PATH=${AUTOWARE_CARLA_ROOT}/external/zenoh_carla_bridge/carla_agent
parallel --verbose ::: "RUST_LOG=z=info ${AUTOWARE_CARLA_ROOT}/external/zenoh_carla_bridge/target/release/zenoh_carla_bridge" \
                       "poetry -C ${PYTHON_AGENT_PATH} run python3 ${PYTHON_AGENT_PATH}/main.py \
                        --host ${CARLA_SIMULATOR_IP} --rolename ${VEHICLE_NAME} --autopilot --sync --pygame --position $1"

I also tried after removing option --sync, but the situation was the same.

Hello, I am currently working with Zatitech's Openplanner bridge (https://github.com/ZATiTech/open_planner). I've heard the Zenoh bridge is based on Zatitech's, and I was wondering if it has inherited the latter's limitations.

Currently, Openplanner bridge only supports one sensor each (one camera, one lidar, one GNSS and one IMU). Can you modify this sensor kit in Zenoh's bridge (for example, adding multiple cameras or lidars)?

Additionally, I've had problems when assigning each sensor a different sensor_tick parameter (in order to change the frequency of each sensor), so right now the system only works with all sensors working at the same frequency. Is it possible to assign different sensor frequencies on Zenoh's bridge?

Thank you for your answers.

if run this work on two machines. any configuration files should be modify?

Hi, Evshary. During the last couple of days we experienced a specific issue with the building of the zenoh_carla_bridge. Apparently, the carla-sys Rust crate cannot build. The process gets frozen and the memory usage increases until it overflows the available memory and Make shows a 137 error. This happens on two different computers with 2 different bridge installations.

We tested it on a third computer that had an older version of the bridge and this time it worked fine. We discovered that the Rust crate cxx is most likely the cause. The computers that don't work both have version 1.0.115 of cxx, while the one that does work has version 1.0.104. The thing is we don't know how to change that crate's version. It doesn't appear as a dependency on the cargo.toml files and the only way to see it is by running cargo tree on the zenoh_carla_bridge folder. We think the cxx crate is installed along with the first installation of Rust, when make prepare_bridge is run in the container for the first time. As we cannot directly change the version, re-running the command does not fix the issue.

Do you know how we can revert the cxx crate's version back to 1.0.104?

Thank you for your time.
Best regards,
Mario

I am new to zenoh dds bridge. When my autoware is running, I couldn't see topics or nodes using ros2 cli. I get empty output when I run ros2 node list or ros2 topic list.
I did exec into the humble docker container and ran ros2 topic list while the autoware is running in another terminal(same container),

What am I missing? How to use all the ros2 dev tools(cli, rqt, rosbag, etc) using the zenoh bridge(for carla data)?

Hello, I was trying to monitor different Autoware topics, belonging to different modules:

/sensing/camera/traffic_light/image_raw, /sensing/imu/tamagawa/imu_raw, /sensing/lidar/concatenated/pointcloud, /sensing/gnss/pose_with_covariance, /perception/object_recognition/detection/clustering/clusters, /perception/object_recognition/detection/clustering/objects, /perception/object_recognition/detection/objects, /perception/object_recognition/objects, /system/component_state_monitor/component/autonomous/perception, /control/command/control_cmd, /perception/object_recognition/detection/rois0, perception/object_recognition/detection/camera_lidar_fusion/objects

I was recording them in a ros2bag and then checking both the timestamp of the messages' header as well as the ros2bag recording timestamp, as well as the order in which these messages are being recorded. I've noticed some strange behavior, however. As I see in these links: https://github.com/autowarefoundation/autoware.universe/blob/main/control/trajectory_follower_node/src/simple_trajectory_follower.cpp, https://github.com/autowarefoundation/autoware.universe/blob/main/control/shift_decider/src/shift_decider.cpp, Autoware's control modules are set on a timer, in some cases with frequencies around 30 ms. However Carla's default settings set the delta_seconds to 50 ms (delta_time=0.05).

Additionally, it is difficult for the whole platform of Carla, Zenoh bridge and Autoware to work at perfect real time, so the Carla ticks not always tick with a true 50 ms frequency (a tick can sometimes last for a real time second, or half a second, for example). That being said, when monitoring the control topics working on a 30 ms timer, I'd expect to see a bunch of control messages being recorded within each Carla tick, but that doesn't happen. Only one control message appears within each Carla tick.

I've added a CSV screenshot containing the messages of a ros2bag I recorded while using Zenoh bridge. Not all the topics I've listed above were recorded properly, but I hope it serves to illustrate some of the behavior I'm talking about. This was recorded when the ego vehicle was moving normally on the road. It's not edited in any way. I've used this: https://ternaris.gitlab.io/rosbags/index.html to convert the ros2bag to CSV. The E column called timestamp refers to the timestamp stored in each message's header, while the G column called bag_timestamp refers to the timestamp when each message was recorded into the ros2bag.

Given all this:

• How do Autoware timers work in relation to Carla?
• Do they monitor Wall Time, or Ros Time?
• How does Carla's discrete management of time and its non real-time nature affect Autoware's timed nodes?
• Autoware's control commands are sent back to Carla through the bridge. Are they also responsible of ticking Carla when they are received?
• Do you know if ros2bag's recording order is to be trusted as the true order in which the messages were generated?

Sorry for the avalanche of questions, but understanding how Carla's time management and Autoware's relate to each other is critical for the project I'm working on.

Thank you so much for your answers.

hello， @evshary ，I have successfully replicated multiple vehicles in parallel according to Readme. I would like to ask if this architecture supports interaction between multiple vehicles, such as perceiving other vehicles and avoiding them, identifying and following traffic signals?
Will future versions integrate these features? If it's not supported, how can I expand it？

I met some issues "GILBC not found" when run Python Agent (In Carla bridge container).
./script/run-bridge.sh

/home/dell/autoware_carla_launch/poetry/venv/bin/python: /usr/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /home/dell/autoware_carla_launch/poetry/venv/bin/python)
/home/dell/autoware_carla_launch/poetry/venv/bin/python: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/dell/autoware_carla_launch/poetry/venv/bin/python)
/home/dell/autoware_carla_launch/poetry/venv/bin/python: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/dell/autoware_carla_launch/poetry/venv/bin/python)
/home/dell/autoware_carla_launch/poetry/venv/bin/python: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/dell/autoware_carla_launch/poetry/venv/bin/python)

I am using the main branch. Ubuntu 22.04 Carla 0.9.14. This docker image was created all at once, how should I go about fixing this? Should I Change to the humble branch and retry?

Hi @evshary!
I'm currently using your nice bridge software to run Autoware.
However, I faced another issue that I cannot set destination that requires lane change.
Here is a video for better understanding of the situation.
The map used in the video is Town05.
When I set the destination near to the start point, which requires a lane change once, but it seems like the car does not make a correct path.
I thought that this is because there's not enough distance to change lane, so I set the destination a bit far from the starting point, but the situation was the same.
When I make the car drive(click AUTO of OperationMode on RViz), it drives but stucks to the same lane and cannot reach the goal.
I also suffered this situation on Town04 too, and I could not even set the destination(On Town05, '2D Goal Pose' call worked anyway, but on town04, even '2d Goal Pose' does not work for 'lane-changing destination').

Have you ever suffered this issue?
I cannot sure whether this is the problem from Autoware or from bridge, but I write this issue to you because I expect Autoware to be able to handle this kind of somewhat basic case.. so I just want to hear your opinion.

I could reproduce the issue at any point of the map with multi-lane(Town04, Town05), so I expect that you can reproduce it with random spawning point(default option of the bridge)

Thank you for reading!

Hi @evshary,

I am following this tutorial: https://tier4.github.io/AWSIM/GettingStarted/QuickStartDemo/ to debug my autoware carla bridge code. This below command run very well in AWSim Map. However, when I replace AWSim Map to Carla Map Town 01, my rviz seems to be mismatched between lanelet2 map and point cloud map. Do you check it?

ros2 launch autoware_launch e2e_simulator.launch.xml vehicle_model:=sample_vehicle sensor_model:=awsim_sensor_kit map_path:=<your mapfile location>

Thank you.

Hello,
I followed the instructions to start 2 vehicles in 2 different rviz windows. This part is working.

When I do ros2 topic list, I only get: /parameter_events and /rosout. Is this expected?
Moreover, in RViz, when I set a 2D pose goal, the path is computed but engage does not move the vehicle, it is still in the INITIALIZING state.

Any help will be useful.

Thank you!

Note: I am not using docker and I am using the galactic branch.

When I set a 2D Goal Pose on Rviz, I hope to see publishes to Autoware topics.
I am following the Carla-Autoware Demo but cannot find any Autoware topics (i.e. /control/command/control_cmd) from ros2 topic list. I am using a single host for both the bridge and Autoware dockers.

I've tried running ros2 topic list in the "run-autoware-docker" container but could only find /rosout and /parameter_events

Am I missing something?

./container/run-bridge-docker.sh

zenoh-carla-bridge does not exist. Creating...
[+] Building 3.1s (6/11)                                                        docker:default
 => [internal] load build definition from Dockerfile_carla_bridge                         0.0s
 => => transferring dockerfile: 927B                                                      0.0s
 => [internal] load metadata for ghcr.io/autowarefoundation/autoware-universe:galactic-2  2.8s
 => [internal] load .dockerignore                                                         0.0s
 => => transferring context: 2B                                                           0.0s
 => [1/8] FROM ghcr.io/autowarefoundation/autoware-universe:galactic-20221201-prebuilt-c  0.0s
 => CACHED [2/8] RUN apt-get update                                                       0.0s
 => ERROR [3/8] RUN apt-get install -y wget unzip tmux inetutils-ping curl vim            0.2s
------                                                                                         
 > [3/8] RUN apt-get install -y wget unzip tmux inetutils-ping curl vim:
0.205 Reading package lists...
0.218 Building dependency tree...
0.220 Reading state information...
0.222 E: Unable to locate package tmux
0.222 E: Unable to locate package inetutils-ping
0.222 E: Unable to locate package vim
------
Dockerfile_carla_bridge:7
--------------------
   5 |     RUN apt-get update
   6 |     # Useful tools
   7 | >>> RUN apt-get install -y wget unzip tmux inetutils-ping curl vim
   8 |     RUN python3 -m pip install gdown
   9 |     RUN printf 'set-option -g default-shell /bin/bash\nset -g default-terminal "tmux-256color"' > /etc/tmux.conf
--------------------
ERROR: failed to solve: process "/bin/bash -o pipefail -c apt-get install -y wget unzip tmux inetutils-ping curl vim" did not complete successfully: exit code: 100
Extension volume doesn't support default arguments. Please extend it.
Active extensions ['network', 'nvidia', 'privileged', 'user', 'volume', 'x11']
Step 1/6 : FROM golang:1.19 as detector
 ---> 80b76a6c918c
Step 2/6 : RUN git clone -q https://github.com/dekobon/distro-detect.git &&     cd distro-detect &&     git checkout -q 5f5b9c724b9d9a117732d2a4292e6288905734e1 &&     CGO_ENABLED=0 go build .
 ---> Using cache
 ---> 3451c367aa35
Step 3/6 : FROM zenoh-carla-bridge
no more output and success not detected
Failed to build detector image
WARNING unable to detect os for base image 'zenoh-carla-bridge', maybe the base image does not exist

Does anyone have any experience with this bug? I have tried the solution in the issue related to rocker.

Hi @evshary
I have one more question about running Autoware on Carla with autopilot NPC Vehicle.
I'm currently running bridge and autoware on docker container (one container for each), and I'm working on host PC to spawn NPC vehicle.
However, when I spawn NPC vehicles, they do not move(actually moving with the speed about 0.1km/h) but Autoware works well.
And after about 150 seconds(2:30 minutes, on pygame UI), I could see the vehicles start to move, but Autoware and RViz stop(literally they do not make any response.. no updates are made).

It can be the issue from me because I create another carla client on host PC, but I cannot know..
Could you please tell me the way to generate NPC vehicle properly?

Sorry to bother you @evshary , i want to know whether in this bridge, Autoware can recognize the traffic light in Carla and follow the traffic rules.

Hello,
this is not an issue and the question has nothing to do with your project. I couldn't find any answer so I wanted to check if someone knowledgeable may know the answer. When there is an obstacle in the same lane as the ego vehicle, the ego vehicle stops behind the obstacle. Do I have to do something specific for the ego vehicle to change lane instead of stopping?

Thank you

Hi author,
Can i use python API read data from carla and rospy for pub and sub to autoware without zenod ?
Rust and zenod is big challenge with me ? Have any problem if using only python for connect carla with autoware ?
Thank you.

Hello, I've followed the tutorial shown in: https://autoware.org/running-multiple-autoware-powered-vehicles-in-carla-using-zenoh/. I have successfully installed the system and both Rviz visualizers opened up. However, when I set the Goal Pose, the vehicles couldn't move. Is there any configuration steps I missed? Is it possible for the problem to be related to internet connection? I appreciate any insight you may have.

Thank you so much for your answers.

Hi @evshary,

I modified the "script/run-bridge.sh" to add the "--pygame" and"--position" to the poetry command. The "--pygame" works fine. But when I use "--position", the script will get stuck, "main.py" will not respond and crash.

Here is the poetry command:
"poetry -C ${PYTHON_AGENT_PATH} run python3 ${PYTHON_AGENT_PATH}/main.py \ --host ${CARLA_SIMULATOR_IP} --pygame --rolename ${VEHICLE_NAME} --position 396,105.4,0,0,0,0 \ 2>&1 | tee ${LOG_PATH}/vehicle.log"

Information from running the bash script:

sleep 5 && RUST_LOG=z=info /home/weidonghu/autoware_carla_launch/external/zenoh_carla_bridge/target/release/zenoh_carla_bridge --zenoh-listen tcp/0.0.0.0:7447 2>&1 | tee bridge_log/2024-01-10_12:25:32//bridge.log
poetry -C /home/weidonghu/autoware_carla_launch/external/zenoh_carla_bridge/carla_agent run python3 /home/weidonghu/autoware_carla_launch/external/zenoh_carla_bridge/carla_agent/main.py --host 127.0.0.1 --pygame --rolename v1 --position 396,105.4,0,0,0,0 2>&1 | tee bridge_log/2024-01-10_12:25:32//vehicle.log
INFO: listening to server 127.0.0.1:2000
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5220:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Value in failed request: 0x500
Serial number of failed request: 238
Current serial number in output stream: 239
INFO zenoh_carla_bridge > Running Carla Autoware Zenoh bridge...
INFO zenoh::net::runtime > Using PID: 5fd6e2fa69c8e32a8dcdc836ccea73ac
INFO zenoh::net::runtime::orchestrator > Zenoh can be reached at: tcp/192.168.188.83:7447
INFO zenoh::net::runtime::orchestrator > Zenoh can be reached at: tcp/172.17.0.1:7447
INFO zenoh::net::runtime::orchestrator > zenohd listening scout messages on 224.0.0.224:7446
WARNING: Version mismatch detected: You are trying to connect to a simulator that might be incompatible with this API
WARNING: Client API version = 0.4.0-1-gb3fbf09-dirty
WARNING: Simulator API version = 0.9.13
WARNING: Version mismatch detected: You are trying to connect to a simulator that might be incompatible with this API
WARNING: Client API version = 0.4.0-1-gb3fbf09-dirty
WARNING: Simulator API version = 0.9.13

From this information, I noticed that the sensors here are not created?

Similar thing happens when I use client.get_world() instead of client.load_world() in external/zenoh_carla_bridge/carla_agent/simulation/loop.py, and designate a vehicle I spawned in carla as the player. Although in this case, the pygame window works fine, the sensors doesn't work, causing the localization and carmera image in autoware RVIZ window not working.

The commit I use is up to b598fe0043821e096a8b8788eb3cb4e377914bb3. Can you help me with this? Thank you!

this is latest bridge i have seen, can I use ubuntu 22.04 to do all these works

I got this error when running make prepare_bridge

Get code

git submodule update --init --recursive
fatal: detected dubious ownership in repository at '/root/autoware_carla_launch'
To add an exception for this directory, call:

git config --global --add safe.directory /root/autoware_carla_launch

make: *** [Makefile:16: prepare_bridge] Error 128

if im using git config --global --add safe.directory, i will have the same error with issue 3

Hi @evshary!

I'm currently trying to use the most recent version of Autoware, but I encountered the following error while running ./script/run-autoware.sh.

1702373501.2179277 [INFO] [launch]: Default logging verbosity is set to INFO
1702373508.5440278 [ERROR] [launch]: Caught exception in launch (see debug for traceback): Included launch description missing required argument 'duplicated_node_checker_param_path' (description: 'no description given'), given: [map_path, ...

It seems the new feature duplicated_node_checker is added to the Autoware, but the path duplicated_node_checker_param_path is not set. Could you please tell me where to modify to handle this issue?

Thank you. Please answer me when you are available.

Integrate V2X, and update the documentation.

Just my one cent.
It helps visitors to understand the purpose of the repository and distinguish it from other bridge code and subprojects.

./run-docker.sh

Extension volume doesn't support default arguments. Please extend it.
Active extensions ['network', 'nvidia', 'privileged', 'volume', 'x11', 'user']
Step 1/12 : FROM python:3-slim-stretch as detector
 ---> 7691d3cb6cbc
Step 2/12 : RUN mkdir -p /tmp/distrovenv
 ---> Using cache
 ---> 9d7a12f57f51
Step 3/12 : RUN python3 -m venv /tmp/distrovenv
 ---> Using cache
 ---> 533adc7ef328
Step 4/12 : RUN apt-get update && apt-get install -qy patchelf binutils
 ---> Running in 062552a9721d
Ign:1 http://security.debian.org/debian-security stretch/updates InRelease
Ign:2 http://deb.debian.org/debian stretch InRelease
Ign:3 http://security.debian.org/debian-security stretch/updates Release
Ign:4 http://deb.debian.org/debian stretch-updates InRelease
Ign:5 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
Ign:6 http://deb.debian.org/debian stretch Release
Ign:7 http://security.debian.org/debian-security stretch/updates/main all Packages
Ign:8 http://deb.debian.org/debian stretch-updates Release
Ign:5 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
Ign:9 http://deb.debian.org/debian stretch/main all Packages
Ign:7 http://security.debian.org/debian-security stretch/updates/main all Packages
Ign:10 http://deb.debian.org/debian stretch/main amd64 Packages
Ign:5 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
Ign:11 http://deb.debian.org/debian stretch-updates/main all Packages
Ign:7 http://security.debian.org/debian-security stretch/updates/main all Packages
Ign:12 http://deb.debian.org/debian stretch-updates/main amd64 Packages
Ign:5 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
Ign:9 http://deb.debian.org/debian stretch/main all Packages
Ign:7 http://security.debian.org/debian-security stretch/updates/main all Packages
Ign:10 http://deb.debian.org/debian stretch/main amd64 Packages
Ign:5 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
Ign:11 http://deb.debian.org/debian stretch-updates/main all Packages
Ign:7 http://security.debian.org/debian-security stretch/updates/main all Packages
Ign:12 http://deb.debian.org/debian stretch-updates/main amd64 Packages
Err:5 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
  404  Not Found
Ign:9 http://deb.debian.org/debian stretch/main all Packages
Ign:7 http://security.debian.org/debian-security stretch/updates/main all Packages
Ign:10 http://deb.debian.org/debian stretch/main amd64 Packages
Ign:11 http://deb.debian.org/debian stretch-updates/main all Packages
Ign:12 http://deb.debian.org/debian stretch-updates/main amd64 Packages
Ign:9 http://deb.debian.org/debian stretch/main all Packages
Ign:10 http://deb.debian.org/debian stretch/main amd64 Packages
Ign:11 http://deb.debian.org/debian stretch-updates/main all Packages
Ign:12 http://deb.debian.org/debian stretch-updates/main amd64 Packages
Ign:9 http://deb.debian.org/debian stretch/main all Packages
Ign:10 http://deb.debian.org/debian stretch/main amd64 Packages
Ign:11 http://deb.debian.org/debian stretch-updates/main all Packages
Ign:12 http://deb.debian.org/debian stretch-updates/main amd64 Packages
Ign:9 http://deb.debian.org/debian stretch/main all Packages
Err:10 http://deb.debian.org/debian stretch/main amd64 Packages
  404  Not Found
Ign:11 http://deb.debian.org/debian stretch-updates/main all Packages
Err:12 http://deb.debian.org/debian stretch-updates/main amd64 Packages
  404  Not Found
Reading package lists...
�[91mW: The repository 'http://security.debian.org/debian-security stretch/updates Release' does not have a Release file.
W: The repository 'http://deb.debian.org/debian stretch Release' does not have a Release file.
W: The repository 'http://deb.debian.org/debian stretch-updates Release' does not have a Release file.
E: Failed to fetch http://security.debian.org/debian-security/dists/stretch/updates/main/binary-amd64/Packages  404  Not Found
E: Failed to fetch http://deb.debian.org/debian/dists/stretch/main/binary-amd64/Packages  404  Not Found
E: Failed to fetch http://deb.debian.org/debian/dists/stretch-updates/main/binary-amd64/Packages  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.
�[0m
Removing intermediate container 062552a9721d
no more output and success not detected
Failed to build detector image
WARNING unable to detect os for base image 'autoware-carla-bridge', maybe the base image does not exist

@evshary , do you have any experience with this bug? Maybe we need to consider serving a custom autoware docker (of course fixed in Galactic version)?

Hi evshary!
I'm currently running the Autoware universe on Carla with your bridge, but I got a question regarding the perception module of Autoware.

To my knowledge, Autoware is capable of predicting the trajectory of objects(like NPC Vehicle, ...) moving around, and I remember that I saw the expected trajectory drawn with dotted line on RViz when I run the Autoware on AWSIM.
However, when I run Autoware on Carla with the bridge, I cannot see any of the dotted lines in RViz as below:

I saw that the ego vehicle stops when the NPC Vehicle or other obstacles are in front of him, but in the case of the video below, the ego vehicle does not stop and eventually collide to the tail of the NPC Vehicle.

Could you please check whether the expected trajectory shows well on your screen?
Thanks in advance! I always appreciate to your hard work!

How to reproduce?

sudo ./container/run-bridge-docker.sh

Error:

zenoh-carla-bridge does not exist. Creating...
[+] Building 0.9s (4/4) FINISHED                                                                                                                                        docker:default
 => [internal] load .dockerignore                                                                                                                                                 0.0s
 => => transferring context: 2B                                                                                                                                                   0.0s
 => [internal] load build definition from Dockerfile_carla_bridge                                                                                                                 0.0s
 => => transferring dockerfile: 927B                                                                                                                                              0.0s
 => ERROR [internal] load metadata for ghcr.io/autowarefoundation/autoware-universe:galactic-20221201-prebuilt-cuda-amd64                                                         0.9s
 => [auth] autowarefoundation/autoware-universe:pull token for ghcr.io                                                                                                            0.0s
------
 > [internal] load metadata for ghcr.io/autowarefoundation/autoware-universe:galactic-20221201-prebuilt-cuda-amd64:
------
Dockerfile_carla_bridge:1
--------------------
   1 | >>> FROM ghcr.io/autowarefoundation/autoware-universe:galactic-20221201-prebuilt-cuda-amd64
   2 |     # TODO: Don't upgrade it until we bump the carla-sys version.
   3 |     
--------------------
ERROR: failed to solve: ghcr.io/autowarefoundation/autoware-universe:galactic-20221201-prebuilt-cuda-amd64: pulling from host ghcr.io failed with status code [manifests galactic-20221201-prebuilt-cuda-amd64]: 403 Forbidden
/usr/lib/python3/dist-packages/paramiko/transport.py:237: CryptographyDeprecationWarning: Blowfish has been deprecated and will be removed in a future release
  "class": algorithms.Blowfish,
Extension volume doesn't support default arguments. Please extend it.
Active extensions ['network', 'nvidia', 'privileged', 'user', 'volume', 'x11']
Step 1/6 : FROM golang:1.19 as detector
 ---> 80b76a6c918c
Step 2/6 : RUN git clone -q https://github.com/dekobon/distro-detect.git &&     cd distro-detect &&     git checkout -q 5f5b9c724b9d9a117732d2a4292e6288905734e1 &&     CGO_ENABLED=0 go build .
 ---> Using cache
 ---> 7dbb148a439f
Step 3/6 : FROM zenoh-carla-bridge
no more output and success not detected
Failed to build detector image
WARNING unable to detect os for base image 'zenoh-carla-bridge', maybe the base image does not exist

May I know to how fix it or I am missing something? Thank you.

Hello,
I am using zenoh with two vehicles (galactic).
It seems that mission planner only works for the first vehicle spawned in autoware.
Steps to reproduce:

• 1:

<?xml version="1.0" encoding="UTF-8"?>
<launch>
  <group>
    <executable cmd="$(env AUTOWARE_CARLA_ROOT)/run_carla_bridge.sh" output="screen">
      <env name="RUST_LOG" value="z=info"/>
    </executable>
    <executable cmd="poetry run python3 main.py --host $(env CARLA_SIMULATOR_IP) --rolename 'rv1' --position 396.0,250.0,0.300000,0.000000,-90.000053,0.000000" cwd="$(env AUTOWARE_CARLA_ROOT)/external/zenoh_carla_bridge/carla_agent" output="screen" />
    <executable cmd="poetry run python3 main.py --host $(env CARLA_SIMULATOR_IP) --pygame --rolename 'rv2' --position 396.0,316.0,0.300000,0.000000,-90.000053,0.000000" cwd="$(env AUTOWARE_CARLA_ROOT)/external/zenoh_carla_bridge/carla_agent" output="screen" />
  </group>
</launch>

• 2:

ROS_DOMAIN_ID=1 VEHICLE_NAME="rv1" ros2 launch autoware_carla_launch autoware_zenoh.launch.xml

• 3 :

ROS_DOMAIN_ID=2 VEHICLE_NAME="rv2" ros2 launch autoware_carla_launch autoware_zenoh.launch.xml

• 4: In RViz, when I set the goal for rv1 then a path is computed. When I set a goal for rv2 then a plan is not computed. If I start step 3 before step 2 then I can only set the goal for rv2 and not rv1.

Any idea what is happening?

Thank you

I follow the README.md. and I have already apt install tmux inetutils-ping vim.

Hi evshary!

I got a question regarding the behavior of NPC Vehicles.
When I run the simulation with autopilot NPC vehicles, the vehicles often slide through the road randomly.

In video1, when the ego vehicle turns to the right, the NPC vehicle is already slided too much, and seems like he invaded the lane while cornering.
Also, you can see that another NPC vehicle invades the lane where the ego vehicle is, and eventually makes a collision with the ego vehicle.

In video2, the NPC vehicle on the opposite lane stops on the red light sign, but slides through when he starts to move, and eventually collides with the ego vehicle.

Maybe these slidings could be from the weather I configured(especially puddle, rain or wetness), but I don't know why NPC vehicles drive well and abruptly lose control.
Also I remember that I didn't experience this issue while running a traffic simulation with autopilot NPC vehicle on Carla independently(which means w/o bridge and Autoware).

Have you ever experienced the situation like this? or do you know any possible solution on this issue?

Hi evshary!

I've got so many help from you, but I just got stuck while using the latest version of Autoware.
I pull the latest docker image here because the image contains the recent version of Autoware (committed on June 30), and slightly modified your image build script for zenoh-autoware referring here.
Building Autoware was successfuly, but I encountered an error while running the command make build_autoware

Here's the error I met:

mins@4b4493b67b85:~/autoware_carla_launch$ make build_autoware
colcon build --symlink-install --cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
Starting >>> autoware_carla_launch
Starting >>> autoware_manual_control
Starting >>> carla_pointcloud
Starting >>> carla_sensor_kit_description
Starting >>> carla_sensor_kit_launch
Finished <<< autoware_carla_launch [0.13s]
Finished <<< carla_sensor_kit_launch [0.12s]
Finished <<< carla_sensor_kit_description [0.13s]
--- stderr: carla_pointcloud
In file included from /home/mins/autoware_carla_launch/src/carla_pointcloud/src/carla_pointcloud/carla_pointcloud_interface_node.cpp:2:
/home/mins/autoware_carla_launch/src/carla_pointcloud/include/carla_pointcloud/carla_pointcloud_interface_node.hpp:9:10: fatal error: autoware_auto_control_msgs/msg/ackermann_control_command.hpp: No such file or directory
    9 | #include <autoware_auto_control_msgs/msg/ackermann_control_command.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake[3]: *** [CMakeFiles/carla_pointcloud_interface.dir/build.make:76: CMakeFiles/carla_pointcloud_interface.dir/src/carla_pointcloud/carla_pointcloud_interface_node.cpp.o] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:139: CMakeFiles/carla_pointcloud_interface.dir/all] Error 2
gmake[1]: *** [Makefile:146: all] Error 2
---
Failed   <<< carla_pointcloud [0.32s, exited with code 2]
Aborted  <<< autoware_manual_control [0.45s]

Summary: 3 packages finished [0.64s]
  1 package failed: carla_pointcloud
  1 package aborted: autoware_manual_control
  2 packages had stderr output: autoware_manual_control carla_pointcloud
make: *** [Makefile:11: build_autoware] Error 2

I do not have that much knowledge on the bridge code, but I remember that the package autoware_manual_control is from your repository.
I want to ask if you have any idea on this issue.

Thank you in advance!

hello. I would like to ask if I changed the Carla port (I don't use the default 2000) when I run the Carla server how do I change it also when I run the file in the Carla bridge container?

Hello, I already mentioned this issue in #32, but I think it will be more clear if I open a thread specifically for it.

I'm trying to modify the default sensor kit included with the bridge. Apparently, Autoware should support up to 8 cameras and 8 lidars. I have modified the file world.py and added more cameras and lidars. These extra sensors are then detected by run-bridge.sh. However, when I run run-autoware.shI can't see the new topics corresponding to those extra sensors.

I have checked sensor_kit_calibration.yamland sensor_kit.xacro to include them with the same names as world.py, but still can't see the topics when I run ros2 topic echo. Everything looks as default.

I think I'm missing a step here. Should I modify other files? Am I missing something?

Thank you for your answers.

Move the document to the websites
https://autoware-carla-launch.readthedocs.io/en/latest/
Reorganize it to be clearer to users

Hello,
just wanted to point out that I had to install cargo to be able to follow the build steps from the documentation.

sudo apt install cargo

Able to run FMS in humble_0.9.14
Also, we need to update the documentation.

Hello, I have a modified version of Zenoh bridge, where I'm trying to embed source Autoware into the container. However, I need to run some tests with vanilla bridge and I installed a fresh version on my computer alongside the modified one.

After building the bridge, I've noticed that the carla half of it (run-bridge.sh) and the autoware half (run-autoware.sh) have problems communicating. The ROS Time isn't moving at all and the simulation is frozen:

I've tried checking the IP of the computers I'm using, delete and re-download the images, and clearing docker's cache with docker builder prune. However, nothing's changed. Has anyone have any insight as to why this is happening? I've noticed some environment variables can affect other installations of the bridge, can this be related?

I am honestly shocked before the bridge had never failed in its vanilla state. Are there problems with multiple installations of the bridge on the same computer?

Thank you so much for your answers.

Hi, Do you have any timeline of when this repo would be upgraded to Carla 0.9.15?

• From what I tried the dependency of 'carla-ackermann 0.1.0' is on 'carla-sys 0.6.0' in Rust
• Also to Ubuntu 22.04

Hi @evshary

I'm keep using your bridge implementation for Autoware and Carla, and I have one question today.
I wonder how the message from /control/command/control_cmd to be converted to the control values(throttle, brake, ...) for Carla.

I think the most relevant function is the code below, but I cannot know how the values from the message(acceleration, speed...) to be convereted to the carla's control values.
https://github.com/evshary/zenoh_carla_bridge/blob/36ff278dc508697a5ef9800b5d32ee5f308e33c9/src/bridge/vehicle_bridge.rs#L310

I don't know about rust well, but I guess the step function calculates the values for carla's control values. Could you please tell me how it works?
https://github.com/evshary/zenoh_carla_bridge/blob/36ff278dc508697a5ef9800b5d32ee5f308e33c9/src/bridge/vehicle_bridge.rs#L367

I always appreciate to your help. Thank you!

Hi @evshary! Thank you for the nice work!
I saw your comment here and I'm currently following the instruction for humble branch of this repository.
However, while building the container for carla bridge (by typing make prepare_bridge), I faced an error below:

...
lactic/lib/x86_64-linux-gnu:/opt/ros/galactic/lib:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 ./python -E -m ensurepip \
                $ensurepip --root=/ ; \
fi
Looking in links: /tmp/tmpx4c31f6u
Requirement already satisfied: setuptools in /home/mins/autoware_carla_launch/pyenv/versions/3.8.10/lib/python3.8/site-packages (56.0.0)
Requirement already satisfied: pip in /home/mins/autoware_carla_launch/pyenv/versions/3.8.10/lib/python3.8/site-packages (21.1.1)
make[1]: Leaving directory '/tmp/python-build.20230611162332.223/Python-3.8.10'
Installed Python-3.8.10 to /home/mins/autoware_carla_launch/pyenv/versions/3.8.10
./script/dependency_install.sh: line 19: cd: external/zenoh_carla_bridge/carla_agent: No such file or directory
make: *** [Makefile:16: prepare_bridge] Error 1

I want to ask you some help to solve this error..
My OS is ubuntu 20.04, and I'm planning to use carla 0.9.13, so it seems there's no violation to the prerequisite..

Thank you in advance! I'm really appreciate to your work, since I could not have any expectation to run autoware universe humble with carla.. thank you so much.

Hi @evshary.

I am contacting you because we have recently realized that some messages generated by Carla cannot reach Autoware. We believe that these messages are lost (probably discarded) when passing through the Zenoh-based bridge.
For example, we compared the clock messages retrieved from Carla in the "publish_clock" function of the bridge (inside the zenoh_carla_bridge/src/clock.rs file) with Autoware's /clock topic messages recorded using the ros2 bag command.
During a 20 seconds simulation, the 16% of clock messages generated by Carla could not reach Autoware. In other words, the time interval between messages on Autoware's /clock topic is not always 20 ms (our Carla tick interval setting). Every 5 messages, the time interval is 40 ms (one missing message). Sometimes the time interval is also larger than 40 ms, as more clock messages in a row cannot reach Autoware.

Currently, Carla simulations include 12 vehicles (11 plus the ego-vehicle) and the ego-vehicle is equipped with the following suite of sensors:

• 1 lidar (sensor_tick = 100 ms)
• 5 radars (sensor_tick = 50 ms)
• 5 cameras (resolution = 2560 x 1440, sensor_tick =33 ms)
• 1 GNSS (sensor_tick = 50 ms)
• 1 IMU (sensor_tick = 50 ms)

Does the bridge have any limitations in terms of max data rate or bandwidth?

We know that the same problem applies also to other types of messages (e.g., lidar pointclouds) and also for other tick interval configurations (e.g., 50 ms). Please find attached the log files of the clock and lidar pointclouds messages in both the 20 ms and 50 ms tick interval configurations.

We are running both Carla and Autoware on the same computer, a desktop pc with Intel(R) Core(TM) i9-9980XE CPU, 66GBs RAM memory, and two NVIDIA Quadro P4000 GPUs.

We would really appreciate any feedback and support from your side. Thank you for your time.

Best Regards,
Mario.

PD: The next files contain the data measurements of the /clock and /carla_pointcloud topics, as well as the timestamp measurements extracted directly from the bridge's rust files.

20 ms Test:

• Carla timestamps extracted from the lidar_callback function inside the sensor_bridge.rs file, as well as in the clock.rs file. Each row represents a timestamp generated by Carla before passing through Zenoh, associated either with a /clock measurement or with a pointcloud. The structure of these files is:

• • sec
• • nanosec
• • timestamp expressed in seconds
• • difference between a timestamp and the previous one
• • whether this difference is greater that the expected sensor_tick or not (if True, it means that a message was missing)
• • number of missing messages
    Carla_Pointcloud_Stamp_20ms.csv
    Carla_Clock_20ms.csv

• /carla_pointcloud and /clock topics recorded using ros2bag:

• • topic name
• • message ID as recorded by ros2bag
• • timestamp in seconds
• • difference between a timestamp and the previous one
• • whether this difference is greater that the expected sensor_tick or not (if True, it means that a message was missing)
• • number of missing messages
• • Percentage of missing message with respect to the total amount of messages received
    TEST20ms_Town02_07022024_CarlaPointcloud.csv
    TEST20ms_Town02_07022024_Clock.csv

50 ms Test:
Identical files as before, but tested on a 50 ms tick.
Carla_Pointcloud_Stamp_50ms.csv
Carla_Clock_50ms.csv
TEST50ms_Town02_07022024_CarlaPointcloud.csv
TEST50ms_Town02_07022024_Clock.csv