Merge branch 'dev'

CHANGELOG.md

@@ -1,3 +1,59 @@
+## CARLA 0.9.14
+
+  * Fixed bug in FrictionTrigger causing sometimes server segfault
+  * Added attachment type "SpringArmGhost" for cinematic cameras but without doing the collision test.
+  * Improved algorithm to move signals out of the road by computing the desired displacement direction.
+  * Added `TrafficManager.vehicle_lane_offset(actor, offset)` and `TrafficManager.global_lane_offset(offset)` methods.
+  * Some of the warnings shown when building a map will now only be showing when debugging.
+  * The ids for semantic segmentation has been modified to be the same as cityscapes (labels, ids and colors)
+  * Fixed bug causing traffic signals at the end points of a road to sometimes create malformed waypoints.
+  * Fixed pedestrian skeleton frame, where sometimes it was draw displaced from the body
+  * Fixed decals when importing maps. It was using other .json files found in other packages.
+  * In multi-GPU mode some sensors now are forced to be created on the primary server always (ex. collision sensor)
+  * Added the speed limits for 100, 110 and 120 Km/h.
+  * Fixing sensor destruction, now the stream and socket is succesfully destroyed.
+  * Fixed bug at `Vehicle.get_traffic_light_state()` and `Vehicle.is_at_traffic_light()` causing vehicles to temporarily not lose the information of a traffic light if they moved away from it before it turned green.
+  * Changed the height of the automatic spawn points, from 3m to only 0.5m
+  * Added pedestrian skeleton to the recorder, as additional data. They will replay with the exact pose.
+  * Added multi-GPU feature. Now several servers (with dedicated GPU) can render sensors for the same simulation.
+  * Fixed bug causing the `Vehicle.get_traffic_light_state()` function not notify about the green to yellow and yellow to red light state changes.
+  * Fixed bug causing the `Vehicle.is_at_traffic_light()` function to return *false* if the traffic light was green.
+  * Fixed bug causing the scene lights to return an incorrect location at large maps.
+  * Fixed bug causing the `world.ground_projection()` function to return an incorrect location at large maps.
+  * Added failure state to vehicles, which can be retrieved by using `Vehicle.get_failure_state()`. Only Rollover failure state is currently supported.
+  * Fixed bug causing the TM to block the simulation when a vehicle with no physics was teleported.
+  * Fixed bug causing the TM to block the simulation when travelling through a short roads that looped on themselves.
+  * Improved the TM's handling of non signalized junctions, resulting in a more fluid overall behavior.
+  * Added check to avoid adding procedural trigger boxes inside intersections.
+  * Python agents now accept a carla.Map and GlobalRoutePlanner instances as inputs, avoiding the need to recompute them.
+  * Python agents now have a function to lane change.
+  * Python agents now detect vehicle in adjacent lanes if invaded due to the offset.
+  * Fixed bug causing the python agents to sometimes not detect a blocking actor if there were severral actors around it.
+  * Improved Python agents performance for large maps.
+  * Fix a bug at `Map.get_topology()`, causing lanes with no successors to not be part of it.
+  * Added new ConstantVelocityAgent
+  * Added new parameter to the TrafficManager, `set_desired_speed`, to set a vehicle's speed.
+  * Added 4 new attributes to all vehicles:
+    - `base_type` can be use as a vehicle classification. The possible values are  *car*, *truck*, *van*, *motorcycle* and *bycicle*.
+    - `special_type` provides more information about the vehicle. It is currently restricted to *electric*, *emergency* and *taxi*, and not all vehicles have this attribute filled.
+    - `has_dynamics_doors` can either be *true* or *false* depending on whether or not the vehicle has doors that can be opened using the API.
+    - `has_lights` works in the same way as *has_dynamic_doors*, but differentiates between vehicles with lights, and those that don't.
+  * Added native ackermann controller:
+    - `apply_ackermann_control`:  to apply an ackermann control command to a vehicle
+    - `get_ackermann_controller_settings`: to get the last ackermann controller settings applied
+    - `apply_ackermann_controller_settings`: to apply new ackermann controller settings
+  * Fixed bug causing the Traffic Manager to not be deterministic when using hybrid mode
+  * Added `NormalsSensor`, a new sensor with normals information
+  * Added support for N wheeled vehicles
+  * Added support for new batch commands ConsoleCommand, ApplyLocation (to actor), SetTrafficLightState
+  * Added new API function: `set_day_night_cycle` at the LightManager, to (de)activate the automatic switch of the lights when the simulation changes from day to night mode, and viceversa.
+  * Switch to boost::variant2 for rpc::Command as that allows more than 20 RPC commands
+  * Added post process effects for rainy and dusty weathers.
+  * Switched data type of the dust storm weather parameter from bool to float.
+  * Check for the version of the installed Clang compiler during build.
+  * Added API function to get direct access to the GBuffer textures of a sensor:
+    - `listen_to_gbuffer`: to set a callback for a specific GBuffer texture
+
 ## CARLA 0.9.13
 
   * Added new **instance aware semantic segmentation** sensor `sensor.camera.instance_segmentation`

Docs/3rd_party_integrations.md

@@ -0,0 +1,78 @@
+
+# 3rd Party Integrations
+
+CARLA has been developed to integrate with several 3rd party applications in order to maximise its utility and extensability. The following  
+
+-   [__ROS bridge__](https://carla.readthedocs.io/projects/ros-bridge/en/latest/)
+-   [__SUMO__](adv_sumo.md)  
+-   [__Scenic__](tuto_G_scenic.md)
+-   [__CarSIM__](tuto_G_carsim_integration.md)
+-   [__Chrono__](tuto_G_chrono.md)
+-   [__OpenDRIVE__](adv_opendrive.md) 
+-   [__PTV Vissim__](adv_ptv.md)
+-   [__RSS__](adv_rss.md) 
+-   [__AWS and RLlib__](tuto_G_rllib_integration.md)
+
+---
+## ROS bridge
+
+__Full documentation of the ROS bridge is found [__here__](https://carla.readthedocs.io/projects/ros-bridge/en/latest/).__
+
+The ROS bridge enables two-way communication between ROS and CARLA. 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.
+
+The ROS bridge is compatible with both ROS 1 and ROS 2.
+
+The ROS bridge boasts the following features:
+
+- Provides sensor data for LIDAR, Semantic LIDAR, Cameras (depth, segmentation, rgb, dvs), GNSS, Radar and IMU.
+- Provides object data such as transforms, traffic light status, visualisation markers, collision and lane invasion.
+- Control of AD agents through steering, throttle and brake.
+- Control of aspects of the CARLA simulation like synchronous mode, playing and pausing the simulation and setting simulation parameters.
+
+---
+
+## SUMO
+
+CARLA has developed a co-simulation feature with [__SUMO__](https://www.eclipse.org/sumo/). This allows to distribute the tasks at will, and exploit the capabilities of each simulation in favour of the user.
+
+Please refer to the full documentation [__here__](adv_sumo.md).
+
+---
+
+## PTV Vissim
+
+[__PTV Vissim__](https://www.ptvgroup.com/en/solutions/products/ptv-vissim/) is a proprietary software package providing a comprehensive traffic simulation solution with a powerful GUI. To use PTV-Vissim with CARLA refer to [__this guide__](adv_ptv.md)
+
+---
+
+## Scenic 
+
+Scenic is a set of libraries and a language for scenario specification and scene generation. CARLA and scenic can work seemlessly together, read [__this guid__](tuto_G_scenic.md) to understand how to use scenic with CARLA. 
+
+If you need to learn more about Scenic, then read their ["Getting Started with Scenic"](https://scenic-lang.readthedocs.io/en/latest/quickstart.html) guide and have a look at their tutorials for creating [static](https://scenic-lang.readthedocs.io/en/latest/tutorials/tutorial.html) and [dynamic](https://scenic-lang.readthedocs.io/en/latest/tutorials/dynamics.html) scenarios.
+
+---
+
+## CarSIM
+
+CARLA's integration with CarSim allows vehicle controls in CARLA to be forwarded to CarSim. CarSim will do all required physics calculations of the vehicle and return the new state to CARLA. 
+
+Learn how to use CARLA alongside CarSIM [here](tuto_G_carsim_integration.md).
+
+## OpenDRIVE
+
+[__OpenDRIVE__](https://www.asam.net/standards/detail/opendrive/) is an open format specification used to describe the logic of a road network intended to standardise the discription of road networks in digital format and allow different applications to exchange data on road networks. Please refer to the full documentation [__here__](adv_opendrive.md)
+
+## RSS - Responsibility Sensitive Safety
+
+CARLA integrates the [C++ Library for Responsibility Sensitive Safety](https://github.com/intel/ad-rss-lib) in the client library. This feature allows users to investigate behaviours of RSS without having to implement anything. CARLA will take care of providing the input, and applying the output to the AD systems on the fly. Refer to the full documentation [__here__](adv_rss.md)
+
+## AWS and RLlib integration
+
+The RLlib integration brings support between the Ray/RLlib library and CARLA, allowing the easy use of the CARLA environment for training and inference purposes. Ray is an open source framework that provides a simple, universal API for building distributed applications. Ray is packaged with RLlib, a scalable reinforcement learning library, and Tune, a scalable hyperparameter tuning library. Read more about operating CARLA on AWS and RLlib [__here__](tuto_G_rllib_integration.md).
+
+## Chrono physics
+
+[__Chrono__](https://projectchrono.org/) is a multi-physics simulation engine providing high realism vehicle dynamics using templates. CARLA's Chrono integraion allows CARLA users to add Chrono templates to simulate vehicle dynamics. Please refer to the full documentation [__here__](tuto_G_chrono.md).
+
+---

Docs/adv_agents.md

@@ -63,14 +63,14 @@ destination = random.choice(spawn_points).location
 agent.set_destination(destination)
 ```
 
-__5.__ Vehicle controls and behaviors are applied during a navigation step. During each step, the __Basic Agent__ will apply a vehicle control and react to any vehicles or traffic lights by performing an emergency stop. The __Behavior Agent__ will react to traffic lights, avoid pedestrians, follow cars and navigate intersections according to the behavior type you applied:
+__4.__ Vehicle controls and behaviors are applied during a navigation step. During each step, the __Basic Agent__ will apply a vehicle control and react to any vehicles or traffic lights by performing an emergency stop. The __Behavior Agent__ will react to traffic lights, avoid pedestrians, follow cars and navigate intersections according to the behavior type you applied:
 
 ```py
 while True:
     vehicle.apply_control(agent.run_step())
 ```
 
-__6.__ You can check if the agent has finished its trajectory and perform an action when that happens. The following snippet will end the simulation once your vehicle has reached its destination:
+__5.__ You can check if the agent has finished its trajectory and perform an action when that happens. The following snippet will end the simulation once your vehicle has reached its destination:
 
 ```py
 while True:
@@ -81,7 +81,7 @@ while True:
     vehicle.apply_control(agent.run_step())
 ```
 
-__7.__ Instead of finishing the simulation when an agent has reached its target destination, a new, random route can be generated for the agent to follow:
+__6.__ Instead of finishing the simulation when an agent has reached its target destination, a new, random route can be generated for the agent to follow:
 
 ```py
 while True:

Docs/adv_multigpu.md

@@ -0,0 +1,52 @@
+# Carla Multi-GPU feature
+
+Multi-GPU in carla means that the user can  start several servers (called secondary servers) that will do render work for the main server (called primary server) for different sensors.
+
+## Primary server
+
+The steps are: first, start the primary server without any render capability. The parameters we can use are:
+
+* `-nullrhi`
+* `-carla-primary-port`
+
+Run the following from the command line:
+
+```sh
+./CarlaUE4.sh --nullrhi
+```
+
+The primary server will use, by default, the port 2002 to listen for secondary servers. If you need to listen on another port, then you can change it with the port flag:
+
+```sh
+./CarlaUE4.sh --nullrhi -carla-primary-port=3002
+```
+
+## Secondary servers
+
+We may then start as many servers as we need, but the ideal is to have as many secondary servers as the number of GPUs installed in the computer. Through parameters we need to specify the GPU we want the server use and also the host/port where the primary server is listening, with the flags:
+
+  * `-carla-rpc-port`
+  * `-carla-primary-host`
+  * `-carla-primary-port`
+  * `-ini:[/Script/Engine.RendererSettings]:r.GraphicsAdapter`
+
+For example, if the primary server is executing in the same computer than the secondary servers and with the default port, we can use this command:
+
+```sh
+./CarlaUE4.sh -carla-rpc-port=3000 -carla-primary-host=127.0.0.1 -ini:[/Script/Engine.RendererSettings]:r.GraphicsAdapter=0
+```
+
+Here, the secondary server will use port 3000 as the RPC server to avoid conflicts with other ports (but it will never be used), and will connect to the primary server located at IP 127.0.0.1 (localhost) in the default port (2002), and also this server will use the GPU device 0.
+
+If we want to start another secondary server using another GPU, we could use the following command:
+
+```sh
+./CarlaUE4.sh -carla-rpc-port=4000 -carla-primary-host=127.0.0.1 -carla-primary-port=2002 -ini:[/Script/Engine.RendererSettings]:r.GraphicsAdapter=1
+```
+
+This secondary server will use port 4000 as the RPC server to avoid conflicts with other ports and will connect to the primary server located at IP 127.0.0.1 in port 2002, and also this server will use the GPU device 1.
+
+## Pipeline
+
+After the first secondary server connects to the primary server, it will set up the synchronous mode automatically, with the default values of 1/20 delta seconds.
+