) | RSS world model at the current point in time. This is the input data for the RSS calculations. |
| `ego_dynamics_on_route` | [carla.RssEgoDynamicsOnRoute](<../python_api#carlarssegodynamicsonroute>) | Current ego vehicle dynamics regarding the route. |
In case a actor_constellation_callback is registered, a call is triggered for:
1. default calculation (`actor_constellation_data.other_actor=None`)
2. per-actor calculation
```py
# Fragment of rss_sensor.py
# The function is registered as actor_constellation_callback
def _on_actor_constellation_request(self, actor_constellation_data):
actor_constellation_result = carla.RssActorConstellationResult()
actor_constellation_result.rss_calculation_mode = ad.rss.map.RssMode.NotRelevant
actor_constellation_result.restrict_speed_limit_mode = ad.rss.map.RssSceneCreation.RestrictSpeedLimitMode.IncreasedSpeedLimit10
actor_constellation_result.ego_vehicle_dynamics = self.current_vehicle_parameters
actor_constellation_result.actor_object_type = ad.rss.world.ObjectType.Invalid
actor_constellation_result.actor_dynamics = self.current_vehicle_parameters
actor_id = -1
actor_type_id = "none"
if actor_constellation_data.other_actor != None:
# customize actor_constellation_result for specific actor
...
else:
# default
...
return actor_constellation_result
```
---
## Semantic LIDAR sensor
* __Blueprint:__ sensor.lidar.ray_cast_semantic
* __Output:__ [carla.SemanticLidarMeasurement](python_api.md#carla.SemanticLidarMeasurement) per step (unless `sensor_tick` says otherwise).
This sensor simulates a rotating LIDAR implemented using ray-casting that exposes all the information about the raycast hit. Its behaviour is quite similar to the [LIDAR sensor](#lidar-sensor), but there are two main differences between them.
* The raw data retrieved by the semantic LIDAR includes more data per point.
* Coordinates of the point (as the normal LIDAR does).
* The cosine between the angle of incidence and the normal of the surface hit.
* Instance and semantic ground-truth. Basically the index of the CARLA object hit, and its semantic tag.
* The semantic LIDAR does not include neither intensity, drop-off nor noise model attributes.
The points are computed by adding a laser for each channel distributed in the vertical FOV. The rotation is simulated computing the horizontal angle that the LIDAR rotated in a frame. The point cloud is calculated by doing a ray-cast for each laser in every step.
```sh
points_per_channel_each_step = points_per_second / (FPS * channels)
```
A LIDAR measurement contains a package with all the points generated during a `1/FPS` interval. During this interval the physics are not updated so all the points in a measurement reflect the same "static picture" of the scene.
This output contains a cloud of lidar semantic detections and therefore, it can be iterated to retrieve a list of their [`carla.SemanticLidarDetection`](python_api.md#carla.SemanticLidarDetection):
```py
for detection in semantic_lidar_measurement:
print(detection)
```
The rotation of the LIDAR can be tuned to cover a specific angle on every simulation step (using a [fixed time-step](adv_synchrony_timestep.md)). For example, to rotate once per step (full circle output, as in the picture below), the rotation frequency and the simulated FPS should be equal.
__1.__ Set the sensor's frequency `sensors_bp['lidar'][0].set_attribute('rotation_frequency','10')`.
__2.__ Run the simulation using `python3 config.py --fps=10`.
#### SemanticLidar attributes
| Blueprint attribute | Type | Default | Description |
| ------------------------------------- | ------------------ | ------------------- | ------------------------------------- |
| `channels` | int | 32 | Number of lasers. |
| `range` | float | 10.0 | Maximum distance to measure/raycast in meters (centimeters for CARLA 0.9.6 or previous). |
| `points_per_second` | int | 56000 | Points generated by all lasers per second. |
| `rotation_frequency` | float | 10.0 | LIDAR rotation frequency. |
| `upper_fov` | float | 10.0 | Angle in degrees of the highest laser. |
| `lower_fov` | float | -30.0 | Angle in degrees of the lowest laser. |
| `horizontal_fov` | float | 360.0 | Horizontal field of view in degrees, 0 - 360. |
| `sensor_tick` | float | 0.0 | Simulation seconds between sensor captures (ticks). |
#### Output attributes
| Sensor data attribute | Type | Description |
| ------------------------------------- | ------------------------------------- | ------------------------------------- |
| `frame` | int | Frame number when the measurement took place. |
| `timestamp` | double | Simulation time of the measurement in seconds since the beginning of the episode. |
| `transform` | [carla.Transform](<../python_api#carlatransform>) | Location and rotation in world coordinates of the sensor at the time of the measurement. |
| `horizontal_angle` | float | Angle (radians) in the XY plane of the LIDAR in the current frame. |
| `channels` | int | Number of channels (lasers) of the LIDAR. |
| `get_point_count(channel)` | int | Number of points per channel captured in the current frame. |
| `raw_data` | bytes | Array containing the point cloud with instance and semantic information. For each point, four 32-bits floats are stored.
XYZ coordinates.
cosine of the incident angle.
Unsigned int containing the index of the object hit.
Unsigned int containing the semantic tag of the object it. |
## Semantic segmentation camera
* __Blueprint:__ sensor.camera.semantic_segmentation
* __Output:__ [carla.Image](python_api.md#carla.Image) per step (unless `sensor_tick` says otherwise).
This camera classifies every object in sight by displaying it in a different color according to its tags (e.g., pedestrians in a different color than vehicles).
When the simulation starts, every element in scene is created with a tag. So it happens when an actor is spawned. The objects are classified by their relative file path in the project. For example, meshes stored in `Unreal/CarlaUE4/Content/Static/Pedestrians` are tagged as `Pedestrian`.
The server provides an image with the tag information __encoded in the red channel__: A pixel with a red value of `x` belongs to an object with tag `x`.
This raw [carla.Image](python_api.md#carla.Image) can be stored and converted it with the help of __CityScapesPalette__ in [carla.ColorConverter](python_api.md#carla.ColorConverter) to apply the tags information and show picture with the semantic segmentation.
```py
...
raw_image.save_to_disk("path/to/save/converted/image",carla.ColorConverter.cityScapesPalette)
```
The following tags are currently available (Note, tags changed from version 0.9.13 to 0.9.14):
| Value | Tag | Converted color | Description |
| ----------------------------------- | ----------------------------------- | ----------------------------------- | ----------------------------------- |
| `0` | Unlabeled | `(0, 0, 0)` | Elements that have not been categorized are considered `Unlabeled`. This category is meant to be empty or at least contain elements with no collisions. |
| `1` | Roads | `(128, 64, 128)` | Part of ground on which cars usually drive.
E.g. lanes in any directions, and streets. |
| `2` | SideWalks | `(244, 35, 232)` | Part of ground designated for pedestrians or cyclists. Delimited from the road by some obstacle (such as curbs or poles), not only by markings. This label includes a possibly delimiting curb, traffic islands (the walkable part), and pedestrian zones. |
| `3` | Building | `(70, 70, 70)` | Buildings like houses, skyscrapers,... and the elements attached to them.
E.g. air conditioners, scaffolding, awning or ladders and much more. |
| `4` | Wall | `(102, 102, 156)` | Individual standing walls. Not part of a building. |
| `5` | Fence | `(190, 153, 153)` | Barriers, railing, or other upright structures. Basically wood or wire assemblies that enclose an area of ground. |
| `6` | Pole | `(153, 153, 153)` | Small mainly vertically oriented pole. If the pole has a horizontal part (often for traffic light poles) this is also considered pole.
E.g. sign pole, traffic light poles. |
| `7` | TrafficLight | `(250, 170, 30)` | Traffic light boxes without their poles. |
| `8` | TrafficSign | `(220, 220, 0)` | Signs installed by the state/city authority, usually for traffic regulation. This category does not include the poles where signs are attached to.
E.g. traffic- signs, parking signs, direction signs... |
| `9` | Vegetation | `(107, 142, 35)` | Trees, hedges, all kinds of vertical vegetation. Ground-level vegetation is considered `Terrain`. |
| `10` | Terrain | `(152, 251, 152)` | Grass, ground-level vegetation, soil or sand. These areas are not meant to be driven on. This label includes a possibly delimiting curb. |
| `11` | Sky | `(70, 130, 180)` | Open sky. Includes clouds and the sun. |
| `12` | Pedestrian | `(220, 20, 60)` | Humans that walk |
| `13` | Rider | `(255, 0, 0)` | Humans that ride/drive any kind of vehicle or mobility system
E.g. bicycles or scooters, skateboards, horses, roller-blades, wheel-chairs, etc. . |
| `14` | Car | `(0, 0, 142)` | Cars, vans |
| `15` | Truck | `(0, 0, 70)` | Trucks |
| `16` | Bus | `(0, 60, 100)` | Busses |
| `17` | Train | `(0, 60, 100)` | Trains |
| `18` | Motorcycle | `(0, 0, 230)` | Motorcycle, Motorbike |
| `19` | Bicycle | `(119, 11, 32)` | Bicylces |
| `20` | Static | `(110, 190, 160)` | Elements in the scene and props that are immovable.
E.g. fire hydrants, fixed benches, fountains, bus stops, etc. |
| `21` | Dynamic | `(170, 120, 50)` | Elements whose position is susceptible to change over time.
E.g. Movable trash bins, buggies, bags, wheelchairs, animals, etc. |
| `22` | Other | `(55, 90, 80)` | Everything that does not belong to any other category. |
| `23` | Water | `(45, 60, 150)` | Horizontal water surfaces.
E.g. Lakes, sea, rivers. |
| `24` | RoadLine | `(157, 234, 50)` | The markings on the road. |
| `25` | Ground | `(81, 0, 81)` | Any horizontal ground-level structures that does not match any other category. For example areas shared by vehicles and pedestrians, or flat roundabouts delimited from the road by a curb. |
| `26` | Bridge | `(150, 100, 100)` | Only the structure of the bridge. Fences, people, vehicles, an other elements on top of it are labeled separately. |
| `27` | RailTrack | `(230, 150, 140)` | All kind of rail tracks that are non-drivable by cars.
E.g. subway and train rail tracks. |
| `28` | GuardRail | `(180, 165, 180)` | All types of guard rails/crash barriers. |
!!! Note
Read [this](tuto_D_create_semantic_tags.md) tutorial to create new semantic tags.
## Instance segmentation camera
* __Blueprint:__ sensor.camera.instance_segmentation
* __Output:__ [carla.Image](python_api.md#carla.Image) per step (unless `sensor_tick` says otherwise).
This camera classifies every object in the field of view both by class and also by instance ID.
When the simulation starts, every element in scene is created with a tag. So it happens when an actor is spawned. The objects are classified by their relative file path in the project. For example, meshes stored in `Unreal/CarlaUE4/Content/Static/Pedestrians` are tagged as `Pedestrian`.
The server provides an image with the tag information __encoded in the red channel__: A pixel with a red value of `x` belongs to an object with tag `x`. The green and blue values of the pixel define the object's unique ID. For example a pixel with an 8 bit RGB value of [10, 20, 55] is a vehicle (Semantic tag 10) with a unique instance ID `20-55`.
#### Basic camera attributes
| Blueprint attribute | Type | Default | Description |
| ----------------------------- | ----------------------------- | ----------------------------- | ----------------------------- |
| `fov` | float | 90\.0 | Horizontal field of view in degrees. |
| `image_size_x` | int | 800 | Image width in pixels. |
| `image_size_y` | int | 600 | Image height in pixels. |
| `sensor_tick` | float | 0\.0 | Simulation seconds between sensor captures (ticks). |
---
#### Camera lens distortion attributes
| Blueprint attribute | Type | Default | Description |
| ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------- |
| `lens_circle_falloff` | float | 5\.0 | Range: [0.0, 10.0] |
| `lens_circle_multiplier` | float | 0\.0 | Range: [0.0, 10.0] |
| `lens_k` | float | \-1.0 | Range: [-inf, inf] |
| `lens_kcube` | float | 0\.0 | Range: [-inf, inf] |
| `lens_x_size` | float | 0\.08 | Range: [0.0, 1.0] |
| `lens_y_size` | float | 0\.08 | Range: [0.0, 1.0] |
---
#### Output attributes
| Sensor data attribute | Type | Description |
| ----------------------- | ----------------------- | ----------------------- |
| `fov` | float | Horizontal field of view in degrees. |
| `frame` | int | Frame number when the measurement took place. |
| `height` | int | Image height in pixels. |
| `raw_data` | bytes | Array of BGRA 32-bit pixels. |
| `timestamp` | double | Simulation time of the measurement in seconds since the beginning of the episode. |
| `transform` | [carla.Transform](<../python_api#carlatransform>) | Location and rotation in world coordinates of the sensor at the time of the measurement. |
| `width` | int | Image width in pixels. |
---
## DVS camera
* __Blueprint:__ sensor.camera.dvs
* __Output:__ [carla.DVSEventArray](python_api.md#carla.DVSEventArray) per step (unless `sensor_tick` says otherwise).
A Dynamic Vision Sensor (DVS) or Event camera is a sensor that works radically differently from a conventional camera. Instead of capturing
intensity images at a fixed rate, event cameras measure changes of intensity asynchronously, in the form of a stream of events, which encode per-pixel
brightness changes. Event cameras possess distinct properties when compared to standard cameras. They have a very high dynamic range (140 dB
versus 60 dB), no motion blur, and high temporal resolution (in the order of microseconds). Event cameras are thus sensors that can provide high-quality
visual information even in challenging high-speed scenarios and high dynamic range environments, enabling new application domains for vision-based
algorithms.
The DVS camera outputs a stream of events. An event `e=(x,y,t,pol)` is triggered at a pixel `x`, `y` at a timestamp `t` when the change in
logarithmic intensity `L` reaches a predefined constant threshold `C` (typically between 15% and 30%).
``
L(x,y,t) - L(x,y,t-\delta t) = pol C
``
`t-\delta t` is the time when the last event at that pixel was triggered and `pol` is the polarity of the event according to the sign of the
brightness change. The polarity is positive `+1` when there is increment in brightness and negative `-1` when a decrement in brightness occurs. The
working principles depicted in the following figure. The standard camera outputs frames at a fixed rate, thus sending redundant information
when no motion is present in the scene. In contrast, event cameras are data-driven sensors that respond to brightness changes with microsecond
latency. At the plot, a positive (resp. negative) event (blue dot, resp. red dot) is generated whenever the (signed) brightness change exceeds the
contrast threshold `C` for one dimension `x` over time `t`. Observe how the event rate grows when the signal changes rapidly.
The current implementation of the DVS camera works in a uniform sampling manner between two consecutive synchronous frames. Therefore, in order to
emulate the high temporal resolution (order of microseconds) of a real event camera, the sensor requires to execute at a high frequency (much higher
frequency than a conventional camera). Effectively, the number of events increases the faster a CARLA car drives. Therefore, the sensor frequency
should increase accordingly with the dynamics of the scene. The user should find a balance between time accuracy and computational cost.
The provided script [`manual_control.py`][manual_control] uses the DVS camera in order to show how to configure the sensor, how to get the stream of events and how to depict such events in an image format, usually called event frame.
[manual_control]: https://github.com/carla-simulator/carla/blob/master/PythonAPI/examples/manual_control.py
Note that due to the sampling method of the DVS camera, if there is no pixel difference between two consecutive synchronous frames the camera will not return an image. This will always occur in the first frame, as there is no previous frame to compare to and also in the event that there has been no movement between frames.
DVS is a camera and therefore has all the attributes available in the RGB camera. Nevertheless, there are few attributes exclusive to the working principle of an Event camera.
#### DVS camera attributes
| Blueprint attribute | Type | Default | Description |
| ---------------------- | ---------------------- | ---------------------- | ---------------------- |
| `positive_threshold` | float | 0\.3 | Positive threshold C associated to a increment in brightness change (0-1). |
| `negative_threshold` | float | 0\.3 | Negative threshold C associated to a decrement in brightness change (0-1). |
| `sigma_positive_threshold` | float | 0 | White noise standard deviation for positive events (0-1). |
| `sigma_negative_threshold` | float | 0 | White noise standard deviation for negative events (0-1). |
| `refractory_period_ns` | int | 0\.0 | Refractory period (time during which a pixel cannot fire events just after it fired one), in nanoseconds. It limits the highest frequency of triggering events. |
| `use_log` | bool | true | Whether to work in the logarithmic intensity scale. |
| `log_eps` | float | 0\.001 | Epsilon value used to convert images to log: `L = log(eps + I / 255.0)`.
Where `I` is the grayscale value of the RGB image:
`I = 0.2989*R + 0.5870*G + 0.1140*B`. |
---
## Optical Flow Camera
The Optical Flow camera captures the motion perceived from the point of view of the camera. Every pixel recorded by this sensor encodes the velocity of that point projected to the image plane. The velocity of a pixel is encoded in the range [-2,2]. To obtain the motion in pixel units, this information can be scaled with the image size to [-2 * image_size, 2 * image_size].
#### Optical Flow camera attributes
| Blueprint attribute | Type | Default | Description |
| ------------------- | ---- | ------- | ----------- |
| `image_size_x` | int | 800 | Image width in pixels. |
| `image_size_y` | int | 600 | Image height in pixels. |
| `fov` | float | 90.0 | Horizontal field of view in degrees. |
| `sensor_tick` | float | 0.0 | Simulation seconds between sensor captures (ticks). |
#### Optical Flow camera lens distortion attributes
| Blueprint attribute | Type | Default | Description |
| ------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------- |
| `lens_circle_falloff` | float | 5\.0 | Range: [0.0, 10.0] |
| `lens_circle_multiplier` | float | 0\.0 | Range: [0.0, 10.0] |
| `lens_k` | float | \-1.0 | Range: [-inf, inf] |
| `lens_kcube` | float | 0\.0 | Range: [-inf, inf] |
| `lens_x_size` | float | 0\.08 | Range: [0.0, 1.0] |
| `lens_y_size` | float | 0\.08 | Range: [0.0, 1.0] |
#### Output attributes
| Sensor data attribute | Type | Description |
| --------------------- | ---- | ----------- |
| `frame` | int | Frame number when the measurement took place. |
| `timestamp` | double | Simulation time of the measurement in seconds since the beginning of the episode. |
| `transform` | [carla.Transform](<../python_api#carlatransform>) | Location and rotation in world coordinates of the sensor at the time of the measurement. |
| `width` | int | Image width in pixels. |
| `height` | int | Image height in pixels. |
| `fov` | float | Horizontal field of view in degrees. |
| `raw_data` | bytes | Array of BGRA 64-bit pixels containing two float values. |
---
## V2X sensor
Vehicle-to-everything (V2X) communication is an important aspect for future applications of cooperative intelligent transportation systems. In real vehicles, this requires a dedicated onboard unit (OBU) in each vehicle, that is able to send and receive information over wireless channels. Depending on the region (Europe, China, USA), different physical technologies, protocols and application messaging formats are used.
CARLA currently supports simulation of a simple broadcast wireless channel and two application messages. Protocols for network access and forwarding are not supported yet. The two implemented messages are the [*Cooperative Awarness Message*](#cooperative-awareness-message) according to the European standard ETSI, and a [*custom message*](#custom-v2x-message) type, that can be used to transmit arbitrary string data (e.g. JSON). There are two distinct sensors for V2X communication, that can be used separately, one for each application message type.
Basically, the wireless channel incorporates the following calculation for both sensors:
ReceivedPower = OtherTransmitPower + combined_antenna_gain - loss
IF (ReceivedPower >= receiver_sensitivity)
THEN message is received
To simulate V2X communication, at least two V2X sensors of the same type need to be spawned (at least one sender-receiver pair). Because the received power is calculated on the receiver-side V2X sensor, only the antenna gain that is specified on the receiver-side sensor is incorporated in this calculation. Transmission power and receiver sensitivity can be configured (see [Blueprint attributes](#v2x-sensors-blueprint-attributes)).
The *loss* calculation depends on
- the visbility condition between sender and receiver: line of sight (no obstacles), non-line of sight obstructed by buildings, or non-line of sight obstructed by vehicles, and
- the scenario: highway, rural, or urban environment
While the visibility is simulated within CARLA, the scenario can be configured by the user (see [Blueprint attributes](#v2x-sensors-blueprint-attributes)), as well as several other attributes of the wireless channel.
### Sensor (sub)types
#### Cooperative Awareness Message
* __Blueprint:__ sensor.other.v2x
* __Output:__ [carla.CAMData](python_api.md#carla.CAMData), triggered according to the ETSI CAM standard, unless configured otherwise
Triggering conditions according to ETSI standard:
- Heading angle change > $4$°
- Position difference > $4$ m
- Speed change > $5$ m/s
- Time elapsed > CAM Generation time (configurable)
- Low Frequency Container Time Elapsed $> 500$ ms
For the CAM V2X sensor, additional blueprint attributes apply:
| Blueprint attribute | Type | Default | Description |
|-------------------------|--------|-------------------------|------------------------------------|
| Message generation |
| gen\_cam\_min | float | $0.1$ | Minimum elapsed time between two successive CAMs in seconds (s) |
| gen\_cam\_max | float | $1.0$ | Maximum elapsed time between two successive CAMs in seconds (s) |
| fixed\_rate | bool | false [true] | Generate a CAM in every CARLA tick (only for debug purposes, will result in slowdown) |
| | Data generation |
| `noise_vel_stddev_x` | float | 0\.0 | Standard deviation parameter in the noise model for velocity (X axis). |
| `noise_accel_stddev_x` | float | 0\.0 | Standard deviation parameter in the noise model for acceleration (X axis). |
| `noise_accel_stddev_y` | float | 0\.0 | Standard deviation parameter in the noise model for acceleration (Y axis). |
| `noise_accel_stddev_z` | float | 0\.0 | Standard deviation parameter in the noise model for acceleration (Z axis). |
| `noise_yawrate_bias` | float | 0\.0 | Mean parameter in the noise model for yaw rate. |
| `noise_yawrate_stddev` | float | 0\.0 | Standard deviation parameter in the noise model for yaw rate. |
| `noise_alt_bias` | float | 0\.0 | Mean parameter in the noise model for altitude. |
| `noise_alt_stddev` | float | 0\.0 | Standard deviation parameter in the noise model for altitude. |
| `noise_lat_bias` | float | 0\.0 | Mean parameter in the noise model for latitude. |
| `noise_lat_stddev` | float | 0\.0 | Standard deviation parameter in the noise model for latitude. |
| `noise_lon_bias` | float | 0\.0 | Mean parameter in the noise model for longitude. |
| `noise_lon_stddev` | float | 0\.0 | Standard deviation parameter in the noise model for longitude. |
| `noise_head_bias` | float | 0\.0 | Mean parameter in the noise model for heading. |
| `noise_head_stddev` | float | 0\.0 | Standard deviation parameter in the noise model for heading. |
#### Custom V2X Message
* __Blueprint:__ sensor.other.v2x_custom
* __Output:__ [carla.CustomV2XData](python_api.md#carla.CustomV2XData), triggered with next tick after a *send()* was called
##### Methods
- **send**(**self**, **callback**)
The function the user has to call every time to send a message. This function needs for an argument containing an object type [carla.SensorData](#carla.SensorData) to work with.
- **Parameters:**
- `data` (_function_) - The called function with one argument containing the sensor data.
The custom V2X message sensor works a little bit different than other sensors, because it has the *send* function in addition to the *listen* function, that needs to be called, before another sensor of this type will receive anything. The transmission of a custom message is only triggered, when *send* is called. Each message given to the *send* function is only transmitted once to all Custom V2X Message sensors currently spawned.
Example:
bp = world.get_blueprint_library().find('sensor.other.v2x_custom')
sensor = world.spawn_actor(bp, carla.Transform(), attach_to=parent)
sensor.send("Hello CARLA")
### V2X sensors blueprint attributes
| Blueprint attribute | Type | Default | Description |
|-------------------------|--------|-------------------------|------------------------------------|
| transmit\_power | float | $21.5$ | Sender transmission power in dBm |
| receiver\_sensitivity | float | $-99$ | Receiver sensitivity in dBm |
| frequency\_ghz | float | $5.9$ | Transmission frequency in GHz. 5.9 GHz is standard for several physical channels. |
| noise\_seed | int | $0$ | Random parameter for initialization of noise |
| filter\_distance | float | $500$ | Maximum transmission distance in meter, path loss calculations above are skipped for simulation speed |
| | __Path loss model parameters__ |
| combined\_antenna\_gain | float | $10.0$ | Combined gain of sender and receiver antennas in dBi, parameter for radiation efficiency and directivity |
| d\_ref | float | $ 1.0 $ | reference distance for Log-distance path loss model in meter |
| path\_loss\_exponent | float | 2.7 | Loss parameter for non-line of sight due to building obstruction |
| scenario | string | urban | Options: [urban, rural, highway], defines the fading noise parameters |
| path\_loss\_model | string | geometric | general path loss model to be used. Options: [geometric, winner] |
| use\_etsi\_fading | bool | true | Use the fading params as mentioned in the ETSI publication (true), or use the custom fading standard deviation |
| custom\_fading\_stddev | float | 0.0 | Custom value for fading standard deviation, only used if `use_etsi_fading` is set to `false` |
|