The CARLA ROS bridge turns a driving simulator into a ROS stack

Two-way translation, and that is the whole design

This ROS package is a bridge that enables two-way communication between ROS and CARLA, and the description of how it works is precise enough to be the mental model for everything else.

The information from the CARLA server is translated to ROS topics. In the same way, the messages sent between nodes in ROS get translated to commands to be applied in CARLA.

So it is a translator in both directions, and the asymmetry of the two directions matters. Data flows one way, from the simulator's world into the ROS graph as topics. Commands flow the other way, from ROS messages published by your nodes into simulator actions on vehicles and on the simulation itself.

That design is what makes the bridge useful for autonomous driving work. A controller node in ROS does not need to know anything about CARLA's Python API, it publishes a steering and throttle command, and the bridge turns that into a control action on the vehicle. And a perception node does not need to know anything about the simulator, it subscribes to sensor topics and gets camera images, lidar and the rest.

The image at the top of the README shows an rviz setup with an autonomous driving demo, which is the intended usage in one picture: rviz on one side for visualisation, a ROS stack in the middle, and CARLA providing the world.

The project is Python as its primary language, MIT licensed, with the last push on 2026-08-16. The release history is old, with 0.9.12 from 2022-07-22, 0.9.11 from 2021 and 0.9.10.1 from 2020, so the packages track the CARLA releases rather than shipping on their own schedule.

Four feature groups, and they map to what a driving stack needs

The feature list is four groups, and it reads like a checklist for an autonomous driving stack.

Providing sensor data covers lidar, semantic lidar, cameras for depth, segmentation, rgb and dvs, plus GNSS, radar and IMU. That is the full sensor suite a vehicle would carry, and the two camera variants beyond plain rgb are what make it usable for perception work, since a segmentation camera gives you ground truth masks.

Providing object data covers transforms, which go through tf, traffic light status, visualization markers, collision events and lane invasion. The tf integration is the detail worth noting, because it means the simulator's coordinate frames are published into the standard ROS transform tree, so a node can ask where anything is relative to anything else without knowing about CARLA at all.

Controlling AD agents means steer, throttle and brake. That is a deliberately small set, and it is the standard drive-by-wire interface, which means a controller written against it does not have to change if you move to a real vehicle.

Controlling CARLA covers play and pause of the simulation and setting simulation parameters. That last one matters more than it looks. A simulator that runs in real time is awkward to test against, because your node has to keep up with the wall clock. Being able to pause the world and step it means a test can drive the simulation deterministically, and the traffic light status and collision topics are what let you assert on what happened.

So the feature set is grouped by direction and by role, and the bridge covers both the sensing side and the actuation side of the loop.

It is a family of ROS packages, not one

The top-level entries show that this is a metapackage of related ROS packages, and the naming makes the roles obvious.

There is `carla_ros_bridge/`, which is the bridge itself. There is `carla_msgs/`, the message definitions, and it is not just a directory but a git submodule, which means the message definitions are shared with the CARLA repository rather than duplicated in a copy that can drift.

Then the control packages. `carla_ackermann_control/` implements vehicle control following the Ackermann steering model, which is the correct kinematic model for a car, and `carla_ackermann_msgs/` holds the messages for it. `carla_manual_control/` is a manual control alternative, `carla_twist_to_control/` converts a twist command into a control command, and `carla_ad_agent/` is the autonomous driving agent that ties control together.

The simulation-side packages are `carla_spawn_objects/`, for placing objects in the world, and `carla_ros_scenario_runner/` with its `carla_ros_scenario_runner_types/`, which is the scenario execution framework, meaning you can script a driving scenario rather than driving by hand.

The data-side packages include `carla_common/` for shared code, `carla_waypoint_publisher/` with `carla_waypoint_types/`, which publishes the road network as waypoints for planners to follow, and `pcl_recorder/`, which records point cloud data, useful for building datasets.

The tooling packages are `rqt_carla_control/` for controlling from the ROS Qt interface, `rviz_carla_plugin/` for visualising in rviz, and `carla_ad_demo/` which is the demo shown in the README image.

Two infrastructure entries complete the picture. `ros_compatibility/` is the layer that lets the same packages work across ROS versions, and `docker/` and `packaging/` handle containerised and packaged builds. There is also `install_dependencies.sh`, a `Makefile`, a `mkdocs.yml` for the documentation and a `.pylintrc`.

The build is a small Makefile with a strict format check

The Makefile is short and it tells you the project's working habits.

The file finder is defined once and reused, and it excludes the virtualenv, the carla_msgs submodule, the packaging build directory, the build directory, the log directory and the install directory. The exclusions are the ones you would expect from a repository that builds Python packages, CMake packages and documentation in the same tree.

Two variables are derived from it. `CMAKE_FILES` collects the cmake files and CMakeLists.txt files, and `PY_FILES` collects the Python files. Both then feed the targets.

The `check` target depends on `check_format` and `pylint`, so a format failure and a lint failure are both gates rather than a suggestion.

check: check_format pylint

format:
	$(PY_FILES) | xargs autopep8 --in-place --max-line-length=100

The format target runs autopep8 in place over the Python files with a maximum line length of 100, and cmake-format over the CMake files. The check variant runs the same tools in diff and check mode rather than writing, which is the form used in continuous integration.

There is a `deb` target that calls the packaging script, so a Debian package can be built from the repository.

The Python requirements are short and they say what the packages actually use. The formatting and linting tools are pep8, autopep8, cmake_format at 0.6.11 and pylint. The functional ones are transforms3d for the coordinate conversions between the simulator frame and the ROS frame, pygame, pexpect for driving the simulator process, simple-pid for the control loops and networkx.

transforms3d and networkx together with the tf publishing in the feature list is the shape of the problem: the bridge's job is moving data between two coordinate conventions and two process boundaries, and those two libraries do most of the arithmetic.

The version pin and the documentation arrangement

Two practical points sit near the top of the README and both will save you time.

The first is a bold line stating that this version requires CARLA 0.9.13. That is a hard constraint rather than a recommendation, and it matters more than it appears because the release history shows the bridge packages are versioned alongside CARLA releases rather than independently. The package version 0.9.12 and the required CARLA version 0.9.13 sit right next to each other, so the numbering convention is legible if you know to look.

The second is where the documentation lives. The README says that installation instructions and further documentation of the ROS bridge and additional packages are found in the carla.readthedocs.io documentation, and the badge at the top links to the CARLA docs with the latest version. The repository's own docs/ directory and mkdocs.yml are the source for that site, with a .readthedocs.yml configuring the build.

That is a reasonable arrangement for a package that has to match a simulator's release cycle, because the simulator's own documentation site is where a user already goes to learn the API the bridge talks to.

The project also carries a CHANGELOG.md, so the changes across CARLA releases are recorded, and the CI badge points at a GitHub Actions workflow.

For anyone evaluating it, the practical checklist is short. Match the CARLA version, decide whether you need ROS 1 or ROS 2, and work out which of the packages you actually need, because a minimal setup is the bridge plus the messages plus one control package, and the full set brings in the scenario runner, the point cloud recorder and the rviz plugin.

Where this sits against talking to CARLA directly

The realistic comparison is with using CARLA's own Python API from a script, and with a general simulator integration framework.

Writing directly against CARLA's Python API gives you the full simulator with nothing in between, and for a single scripted scenario it is less to install and less to debug. The cost is that your code is tied to the simulator's data model and its Python API, and the moment you want a perception node, a planner node and a controller node that run separately, or you want the data in a format other tools can subscribe to, you are writing the plumbing yourself.

The bridge is that plumbing. The topic-based translation means standard ROS tooling applies: rviz for visualisation, rosbag for recording, rqt for introspection, and tf for spatial reasoning. Those are the parts of the ROS ecosystem you would otherwise have to reimplement against a simulator-specific API.

The other comparison is with other simulator bridges. The specificity is both the strength and the weakness here. Because the bridge is written for CARLA, it covers the things CARLA exposes, and the feature list reads like a complete inventory of what a simulator can tell you: every sensor type, every object event, and the vehicle controls. A more general framework would cover more simulators and less of each.

And there is a hybrid worth considering, which is what the package set suggests. Use the bridge for the parts of your stack that benefit from being in ROS, for instance a perception pipeline you want to train and a controller you want to unit test, and use the CARLA API directly for a quick scripted experiment where the ROS plumbing would be overhead.

The scenario runner package tips the balance for anyone doing systematic evaluation, because scripted scenarios plus a point cloud recorder plus the ROS data stream is what you need to generate a dataset and run an evaluation loop over it.

Editorial conclusion

Adopt the CARLA ROS bridge if you are already running ROS and want to put a full driving simulator behind it, because the bridge handles the translation in both directions and the package set covers control, spawning and visualisation as well as the data stream. Skip it if you are on a newer CARLA than 0.9.13 without accepting that this version pins its requirement, or if you want a single package rather than a set of ROS packages to keep in step. Verify first that your CARLA version matches, that you are on ROS 2 rather than ROS 1 since the title covers both, and how the compatibility layer behaves, because the repository carries a ros_compatibility directory and a git submodule for carla_msgs.

Frequently asked questions

Official sources

1. carla-simulator/ros-bridge on GitHub
2. Issues
3. License: MIT
4. README
5. Releases