The CARLA team is thrilled to release CARLA 0.9.9! Buckle up, because it comes ready to drift!
The development has been brief but intense. There are plenty of announces to make, some of great importance. Especially remarkable is the new map ingestion proccess. This has been simplified for users to use their maps in CARLA out-of-the-box. Traffic lights and traffic signs will nevermore require users’ manual intervention. Instead, CARLA can now automatically ingest these traffic landmarks directly from OpenDRIVE.
Moreover, previous features and modules are growing strong. The RSS sensor, SUMO co-simulation, OpenDRIVE standalone mode, and Traffic Manager all have new features, and improved performance. There is even a new integration with PTV-Vissim. The documentation keeps up to date with all of these improvements, and features new tutorials. Last but not least, there is a new map in CARLA. It is opening day in Town10HD!
Here is a summary of every feature included in CARLA 0.9.9!
.xodrwill be accessible from the API. Additionally, the simulator will generate stop, yield, and traffic light objects automatically when running.
Let’s take a look!
The CARLA team has decided to upgrade to the latest version of Unreal Engine, UE4.24. Until now, some crashes were happening when spawning a lot of vehicles while using Vulkan. These crashes do not occur anymore after the upgrade. Furthermore, users should also expect a little increase in the FPS, which never comes amiss.
In order to update the CARLA build, there are some steps to be made.
Delete the UE4.22 version of the system and download a UE4.24.x.
Upgrade to clang-8 with the following commands.
sudo apt install clang-8 lld-8 sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/lib/llvm-8/bin/clang++ 180 sudo update-alternatives --install /usr/bin/clang clang /usr/lib/llvm-8/bin/clang 180 rm -fr Build make clean make launch
Previously in CARLA, traffic lights, and traffic signs had to be created manually by the user after the map was imported. The user had to place them in the scene, add the bounding boxes that determine their influence, and set everything ready. This process is now automatic. When the simulator starts running, it generates traffic lights, stops, and yields using the information provided by the OpenDRIVE file.
The rest of settings that users had to do manually, are also managed during the process.
.jsonfile describing the package.
Create your map, and make the ingestion. Read the documentation to learn more.
From now on, CARLA can read OpenDRIVE signals as described in the road map. All of them will be described in CARLA as landmark objects that can be queried from the API. In order to facilitate their manipulation, there have been several additions to it.
Even if the the simulator generates stop, yields and traffic lights in the simulation, the way these objects are managed has not changed for the user. For instance, it is still possible to customize the traffic lights timing directly from the API.
The implementation of the RSS sensor has been extended. Now, the ability to consume the OpenDRIVE map information enables all the RSS features in CARLA, and full support of RSS anywhere in the map. This upgrade makes for two remarkable features.
RSS checks priority and safety at junctions. Previously, the RSS worked based on road segments, and was limited to these. Now, the RSS sensor can take different road segments into consideration to make the calculations. That makes it possible to integrate junctions, where different road segments meet. When at a junction, a RSS vehicle will check for priority. If necessary, it will brake when coming closer, or even stop to give right of way. More about how the RSS library manages this can be read in the official documentation under Handling of intersections.
Stay on road mode is available. This RSS feature uses the map data to get a description of the road boundaries. At those boundaries, the RSS will place virtual objects, walls, that will prevent the vehicle from driving off the road. The RSS formulas apply to these objects as any other. As a result, the vehicle will always maintain a minimum safe distance with them. By default, the feature is Off. It can be switched using RssSensor.road_boundaries_mode.
The Traffic Manager module now includes a new mode. In hybrid mode, either all vehicle physics can be disabled, or enabled only in a radius around an ego vehicle with the tag
hero. This feature removes the vehicle physics bottleneck from the simulator, especially for cars far away from the ego vehicle. Since vehicle physics are not active, all cars move by teleportation while following their path. This feature relies on the method Actor.set_simulate_physics(). However, not all the physics are disregarded. Basic calculations for a linear acceleration are maintained. By doing so, the position update, and vehicle speed still look realistic. That guarantees that when a vehicle enables or disables its physics, the transition is fluid.
The are two parameters ruling the hybrid mode. One is the radius that states the proximity area around any ego vehicle where physics are enabled. The other is the vehicle with
role_name='hero', that will act as center of this radius.
The hybrid mode is disabled by default. There are two ways to enable it.
spawn_npc.pywith the flag
--hybrid. The vehicles spawned will be registered to a Traffic Manager stated inside the script, and this will run with the hybrid physics on.
Here is an example of the hybrid mode running. The ego vehicle is tagged with a red square. Vehicles with physics disabled are tagged with a blue square. When inside the area of influence stated by the radius, physics are enabled and the tag becomes green.
Besides that, the module has been iterated to improve performance, and there is a minor modification in the Vehicle.set_autopilot() method. This now needs for an attribute stating which Traffic Manager is the vehicle subscribed to.
The mesh generation in the OpenDRIVE standalone mode has been greatly improved. Junctions have been polished to avoid inaccuracies, especially where uneven lanes joined. Instead of creating the whole map as a unique mesh, different fragments are created. Working smaller prevents unexpected issues. Also, by dividing the mesh, not all of it has to be rendered at a time. This is a step towards a larger goal, where the feature will be able to generate huge maps.
Here is an example showing some portions of TownBig. This map is now now available in CARLA, in
On top of that there are two new additions. Crosswalks have been implemented to the pedestrian navigation, and some safety measures have been created to prevent vehicles from falling. About those, the width of the lanes is incremented at junctions, and visible walls appear on the boundaries of the road.
Some settings of the mesh generation can be customized when the method
client.generate_opendrive_world(xodr_file,parameters) is called. Those settings are specified in
parameters, using a carla.OpendriveGenerationParameters.
vertex_distanceis the distance between the vertices of the mesh. The bigger the distance, the more inaccurate the mesh will be. However, if the distance is too small, the resulting mesh will be too heavy to work with.
max_road_lengthis the maximum length of a portion of the mesh. The mesh is divided in portions to reduce rendering overhead. If a portion is not visible, UE will not render it. The smaller the portions, the more probably they are discarded. However, if the portions are too small, UE will have too many objects to manage, and performance will be affected too.
wall_heightstates the height of the additional walls created on the boundaries of the road. These prevent vehicles from falling to the void.
additional_widthis a small width increment applied to the junction lanes. This is a safety measure to prevent vehicles from falling.
smooth_junctionsif True, some information of the OpenDRIVE will be reinterpreted to smooth the final mesh at junctions. This is done to prevent some inaccuracies that may occur when various lanes meet. If set to False, the mesh will be generated exactly as described in the OpenDRIVE.
enable_mesh_visibilityif False, the mesh will not be rendered. This could save a lot of work to the simulator.
This new mode allows CARLA and PTV-Vissim to run a synchronous simulation. Vehicles spawned in one simulator will do so in the other, and their positions will be updated in parallel. In order work, the system must count with PTV-Vissim, and the Driving simulator interface package.
So far, this feature is still experimental, and there are some aspects to take into account.
--simulator-vehicles <INT>. Default value is
Everything related with the PTV-Vissim integration can be found in
Co-Simulation/PTV-Vissim. There is a script in there to run the co-simulation, and examples for Town01 and Town03. Here is an example of how to run the co-simulation using the Town03 example.
python3 run_synchronization.py examples/Town03/Town03.inpx
Traffic lights are now integrated in the co-simulation! As long as they are defined in the OpenDRIVE road map, they will be generated in SUMO. Now the synchronization script has some additional arguments.
--tls-managerto choose which simulator will change the state of traffic lights. The other will update them accordingly. Supported values are
none. Using the later, the traffic lights will not be synchronized.
--sumo-guiwill open a window to visualize SUMO.
# Traffic lights controlled by CARLA python run_synchronization.py examples/TestTLS.sumocfg --tls-manager carla --sumo-gui
There is also a new script,
util/netconvert_carla.py, that generates a SUMO network from an OpenDRIVE file. This script runs the
netconvert tool to generate the main road network without traffic lights. These are then created one by one, using the OpenDRIVE definition. That way, inaccuracies are avoided.
The script will generate a net file that can be opened in SUMO. Use that to prepare the SUMO environment for the co-simulation.
python netconvert_carla.py <PATH_TO_XODR> --output Test.net.xml
Additionally, the script
spawn_npc_sumo.py is almost equivalent to the already-known
spawn_npc.py. The difference is that vehicles will be managed using SUMO instead of the Traffic Manager. This script automatically generates a SUMO network in a temporal folder, based on the active town in CARLA. The script will create random routes and let the vehicles roam around.
As the script runs a synchronous simulation, and spawns vehicles in it, the arguments are the same that appear in
# Spawn 10 vehicles, that will be managed by SUMO instead of Traffic Manager. # CARLA in charge of traffic lights. # Open a window for SUMO visualization. python spawn_sumo_npc.py -n 10 --tls-manager carla --sumo-gui
Lastly, there are two more examples for Town04 and Town05 available in CARLA. These will ease the usage of the feature, so the user does not have to set the SUMO environment previously. The examples can be found in
The documentation has been updated to reflect the upgrades mentioned in previous sections. Nonetheless, there are some remarkable new entries.
There is a new tutorial regarding how to properly retrieve data from the simulation. This is a holistic tutorial that comprises the whole process of retrieving data from start to finish. It starts with the simplest steps, such as customizing the simulation or spawning an ego vehicle. However, it also provides detailed descriptions for sensors, and explains how the recorder can be used to facilitate this process. The goal is to make sure that users can exploit CARLA, by retrieving as much data as desired in the simplest way.
The tutorials regarding assets have been revisited. This new iteration is focused on making simpler for users to add their own assets, being these props, maps, vehicles, and how to create standalone packages for them.
Town10HD is the new addition to CARLA. The whole mindset during its development was to push forward towards visual realism. In order to achieve that, meticulous care has been put into materials.
The environment is based on an American city, designed using real references. Different parts of the map show different settings, such as a skycraper district, a promenade, or a humble and populated neighbourhood. This town also counts with several new props carefully designed including vegetation, scultpures, a museum, and a metro entrance among many others.
Improvements are especially visible on buildings. The facades are now more detailed to be appealing. The streets are no longer plane series of buildings, but a vivid scene of elements coming in and out. This is noticeable from the very ground floors, all the way up. Cubemaps have been placed at windows so that they provide with diverse home pictures.
For the sake of creating these buildings, a new tool has been developed. BP_Procedural_Buildings is a blueprint that is at the same time compound from different blueprints. By using the tool, the dimensions of the building are stated, and then filled in at random. The blueprints are used as if they were pieces to fit the mold. All of the meshes are efficiently instantiated to avoid performance issues. The final result is a varied and realistic building.
Last but not least, the road has been also carefully crafted. Each segment has been treated as a white canvas. The road came to life by painting weathering, tire marks, and day-to-day traits that made it look realistic. After that, decal textures and meshes were added to provide even more detail, such as oil splashes or dirt scattered around.
netconvert_carla.pyto generate SUMO net files.
spawn_npc_sumo.pyto spawn vehicles managed by SUMO instead of Traffic Manager.
command.SetAutopilot()now has a
BP_Power_poles. A blueprint to spawn power poles.
BP_Lights. A blueprint for assets using lights that exposes these in the API.
BP_Procedural_Buildings. A tool to create procedural buildings.
manual_control.pyfor a more realistic throttle and brake.