p71924506
/
carla
mirror of https://github.com/carla-simulator/carla.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Sergi e/p098 core (#2583) 

* Style fixes and iteration

* Mid iteration for rebase

* Finished core + town slider

* First fix waiting for Reviewable

* Iteration on G comments

* Added spectator example

* Fixed typo

* Added minor change to generate opendrive world
This commit is contained in:
sergi.e 2020-03-17 09:24:43 +01:00 committed by GitHub
parent 91f5d909b6
commit 80708b9daa
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
21 changed files with 621 additions and 301 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
Docs/build_linux.md
View File

@ -257,8 +257,7 @@ Now CARLA is ready to go. Here is a brief summary of the most useful `make` comm
<th>Description</th>
</thead>
<tbody>
<td>
<code>make help</code> </td>
<td><code>make help</code> </td>
<td>Prints all available commands.</td>
</tr>
<tr>

192
Docs/core_actors.md
View File

@ -1,15 +1,16 @@
# 2nd. Actors and blueprints
The actors in CARLA include almost everything playing a role the simulation. That includes not only vehicles and walkers but also sensors, traffic signs, traffic lights and the spectator, the camera providing the simulation's point of view. They are crucial, and so it is to have fully understanding on how to operate on them.
This section will cover the basics: from spawning up to destruction and their different types. However, the possibilities they present are almost endless. This is the first step to then experiment, take a look at the __How to's__ in this documentation and share doubts and ideas in the [CARLA forum](https://forum.carla.org/).
Actors not only include vehicles and walkers, but also sensors, traffic signs, traffic lights, and the spectator. It is crucial to have fully understanding on how to operate on them.
* [__Blueprints__](#blueprints)
This section will cover spawning, destruction, types, and how to manage them. However, the possibilities are almost endless. Experiment, take a look at the __tutorials__ in this documentation and share doubts and ideas in the [CARLA forum](https://forum.carla.org/).
* [__Blueprints__](#blueprints)
* Managing the blueprint library
* [__Actor life cycle__](#actor-life-cycle):
* [__Actor life cycle__](#actor-life-cycle)
* Spawning
* Handling
* Destruction
* [__Types of actors__](#types-of-actors):
* [__Types of actors__](#types-of-actors)
* Sensors
* Spectator
* Traffic signs and traffic lights
@ -19,15 +20,17 @@ This section will cover the basics: from spawning up to destruction and their di
---
## Blueprints
This layouts allow the user to smoothly add new actors into the simulation. They basically are already-made models with a series of attributes listed, some of which are modifiable and others are not: vehicle color, amount of channels in a lidar sensor, _fov_ in a camera, a walker's speed. All of these can be changed at will. All the available blueprints are listed in the [blueprint library](bp_library.md) with their attributes and a tag to identify which can be set by the user.
These layouts allow the user to smoothly incorporate new actors into the simulation. They are already-made models with animations and a series of attributes. Some of these are modifiable and others are not. These attributes include, among others, vehicle color, amount of channels in a lidar sensor, a walker's speed, and much more.
#### Managing the blueprint library
Available blueprints are listed in the [blueprint library](bp_library.md), along with their attributes.
There is a [carla.BlueprintLibrary](python_api.md#carla.BlueprintLibrary) class containing a list of [carla.ActorBlueprint](python_api.md#carla.ActorBlueprint) elements. It is the world object who can provide access to an instance of it:
### Managing the blueprint library
The [carla.BlueprintLibrary](python_api.md#carla.BlueprintLibrary) class contains a list of [carla.ActorBlueprint](python_api.md#carla.ActorBlueprint) elements. It is the world object who can provide access to it.
```py
blueprint_library = world.get_blueprint_library()
```
Each blueprints has its own ID, useful to identify it and the actors spawned using it. The library can be read to find a certain ID, choose randomly or filter results using a [wildcard pattern](https://tldp.org/LDP/GNU-Linux-Tools-Summary/html/x11655.htm):
Blueprints have an ID to identify them and the actors spawned with it. The library can be read to find a certain ID, choose a blueprint at random, or filter results using a [wildcard pattern](https://tldp.org/LDP/GNU-Linux-Tools-Summary/html/x11655.htm).
```py
# Find a specific blueprint.
@ -36,7 +39,7 @@ collision_sensor_bp = blueprint_library.find('sensor.other.collision')
vehicle_bp = random.choice(blueprint_library.filter('vehicle.*.*'))
```
Besides that, each [carla.ActorBlueprint](python_api.md#carla.ActorBlueprint) has a series of [carla.ActorAttribute](python_api.md#carla.ActorAttribute) that can be _get_, _set_, and checked if existing:
Besides that, each [carla.ActorBlueprint](python_api.md#carla.ActorBlueprint) has a series of [carla.ActorAttribute](python_api.md#carla.ActorAttribute) that can be _get_ and _set_.
```py
is_bike = [vehicle.get_attribute('number_of_wheels') == 2]
if(is_bike)
@ -45,7 +48,7 @@ if(is_bike)
!!! Note
Some of the attributes cannot be modified. Check it out in the [blueprint library](bp_library.md).
Attributes have a helper class [carla.ActorAttributeType](python_api.md#carla.ActorAttributeType) which defines possible types as enums. Also, modifiable attributes come with a __list of recommended values__:
Attributes have an [carla.ActorAttributeType](python_api.md#carla.ActorAttributeType) variable. It states its type from a list of enums. Also, modifiable attributes come with a __list of recommended values__.
```py
for attr in blueprint:
@ -53,49 +56,54 @@ for attr in blueprint:
blueprint.set_attribute(attr.id, random.choice(attr.recommended_values))
```
!!! Note
Users can create their own vehicles, take a look at the tutorials in __How to... (content)__ to learn on that. Contributors can [add their new content to CARLA](tuto_D_contribute_assets.md).
Users can create their own vehicles. Check the __Tutorials (assets)__ to learn on that. Contributors can [add their new content to CARLA](tuto_D_contribute_assets.md).
---
## Actor life cycle
!!! Important
All along this section, many different functions and methods regarding actors will be covered. The Python API provides for __[commands](python_api.md#command.SpawnActor)__ to apply batches of this common functions (such as spawning or destroying actors) in just one frame.
This section mentions different methods regarding actors. The Python API provides for __[commands](python_api.md#command.SpawnActor)__ to apply batches of the most common ones, in just one frame.
#### Spawning
### Spawning
The world object is responsible of spawning actors and keeping track of those who are currently on scene. Besides a blueprint, only a [carla.Transform](python_api.md#carla.Transform), which basically defines a location and rotation for the actor.
__The world object is responsible of spawning actors and keeping track of these.__ Spawning only requires a blueprint, and a [carla.Transform](python_api.md#carla.Transform) stating a location and rotation for the actor.
The world has two different methods to spawn actors.
* [`spawn_actor()`](python_api.md#carla.World.spawn_actor) returns `None` if the spawning failed.
* [`try_spawn_actor()`](python_api.md#carla.World.try_spawn_actor) raises an exception if the spawning failed.
```py
transform = Transform(Location(x=230, y=195, z=40), Rotation(yaw=180))
actor = world.spawn_actor(blueprint, transform)
```
In case of collision at the specified location, the actor will not spawn. This may happen when trying to spawn inside a static object, but also if there is another actor currently at said point. The world has two different methods to spawn actors: [`spawn_actor()`](python_api.md#carla.World.spawn_actor) and [`try_spawn_actor()`](python_api.md#carla.World.try_spawn_actor).
The former will raise an exception if the actor could not be spawned, the later will return `None` instead.
The actor will not be spawned in case of collision at the specified location. No matter if this happens with a static object or another actor. It is possible to try avoiding these undesired spawning collisions.
To try to avoid this, the world can ask the map for a list of recommended transforms to act as spawning points __for vehicles__:
* `map.get_spawn_points()` __for vehicles__. Returns a list of recommended spawning points.
```py
spawn_points = world.get_map().get_spawn_points()
```
Quite the same works goes __for walkers__, but this time the world can get a random point on a sidewalk (this same method is used to set goal locations for walkers):
* `world.get_random_location()` __for walkers__. Returns a random point on a sidewalk. This same method is used to set a goal location for walkers.
```py
spawn_point = carla.Transform()
spawn_point.location = world.get_random_location_from_navigation()
```
Finally, an actor can be attached to another one when spawned, meaning it will follow the parent object around. This is specially useful for sensors. The attachment can be rigid or smooth, as defined by the helper class [carla.AttachmentType](python_api.md#carla.AttachmentType).
An actor can be attached to another one when spawned. Actors follow the parent they are attached to. This is specially useful for sensors. The attachment can be rigid or eased. It is defined by the helper class [carla.AttachmentType](python_api.md#carla.AttachmentType).
The next example attaches a camera rigidly to a vehicle, so their relative position remains fixed.
```py
camera = world.spawn_actor(camera_bp, relative_transform, attach_to=my_vehicle)
camera = world.spawn_actor(camera_bp, relative_transform, attach_to=my_vehicle, carla.AttachmentType.Rigid)
```
!!! Note
!!! Important
When spawning attached actors, the transform provided must be relative to the parent actor.
Once spawned, the world object adds the actors to a list, keeping track of the current state of the simulation. This list can be iterated on or searched easily:
Once spawned, the world object adds the actors to a list. This can be easily searched or iterated on.
```py
actor_list = world.get_actors()
# Find an actor by id.
@ -105,16 +113,17 @@ for speed_sign in actor_list.filter('traffic.speed_limit.*'):
print(speed_sign.get_location())
```
#### Handling
### Handling
Once an actor si spawned, handling is quite straightforward. The [carla.Actor](python_api.md#carla.Actor) class mostly consists of _get()_ and _set()_ methods to manage the actors around the map:
[carla.Actor](python_api.md#carla.Actor) mostly consists of _get()_ and _set()_ methods to manage the actors around the map.
```py
print(actor.get_acceleration())
print(actor.get_velocity())
location = actor.get_location()
location.z += 10.0
actor.set_location(location)
print(actor.get_acceleration())
print(actor.get_velocity())
```
The actor's physics can be disabled to freeze it in place.
@ -122,94 +131,92 @@ The actor's physics can be disabled to freeze it in place.
```py
actor.set_simulate_physics(False)
```
Besides that, actors also have tags provided by their blueprints that are mostly useful for semantic segmentation sensors, though this will be covered later on this documentation.
Besides that, actors also have tags provided by their blueprints. These are mostly useful for semantic segmentation sensors.
!!! Important
Most of the methods send requests to the simulator asynchronously. The simulator queues these, but has a limited amount of time each update to parse them. Flooding the simulator with lots of "set" methods will accumulate a significant lag.
!!! Warning
Most of the methods send requests to the simulator asynchronously. The simulator has a limited amount of time each update to parse them. Flooding the simulator with _set()_ methods will accumulate a significant lag.
#### Destruction
### Destruction
To remove an actor from the simulation, an actor can get rid of itself and notify if successful doing so:
Actors are not destroyed when a Python script finishes. They have to explicitly destroy themselves.
```py
destroyed_sucessfully = actor.destroy()
destroyed_sucessfully = actor.destroy() # Returns True if successful
```
Actors are not destroyed when the Python script finishes, they remain and the world keeps track of them until they are explicitly destroyed.
!!! Important
Destroying an actor blocks the simulator until the process finishes.
---
## Types of actors
#### Sensors
### Sensors
Sensors are actors that produce a stream of data. They are so important and vast that they will be properly written about on their own section: [4th. Sensors and data](core_sensors.md).
So far, let's just take a look at a common sensor spawning routine:
Sensors are actors that produce a stream of data. They have their own section, [4th. Sensors and data](core_sensors.md). For now, let's just take a look at a common sensor spawning cycle.
This example spawns a camera sensor, attaches it to a vehicle, and tells the camera to save the images generated to disk.
```py
camera_bp = blueprint_library.find('sensor.camera.rgb')
camera = world.spawn_actor(camera_bp, relative_transform, attach_to=my_vehicle)
camera.listen(lambda image: image.save_to_disk('output/%06d.png' % image.frame))
```
This example spawns a camera sensor, attaches it to a vehicle, and tellds the camera to save to disk each of the images that is going to generate. Three main highlights here:
* They have blueprints too. Each sensor works differently so setting attributes is especially important.
* Sensors have blueprints too. Setting attributes is crucial.
* Most of the sensors will be attached to a vehicle to gather information on its surroundings.
* Sensors __listen__ to data. When receiving it, they call a function described with __[Lambda expressions](https://docs.python.org/3/reference/expressions.html)__, so it is advisable to learn on that beforehand <small>(6.13 in the link provided)</small>.
* Sensors __listen__ to data. When data is received, they call a function described with a __[Lambda expression](https://docs.python.org/3/reference/expressions.html)__ <small>(6.13 in the link provided)</small>.
#### Spectator
### Spectator
This unique actor is the one element placed by Unreal Engine to provide an in-game point of view. It can be used to move the view of the simulator window.
Placed by Unreal Engine to provide an in-game point of view. It can be used to move the view of the simulator window. The following example would move the spectator actor, to point the view towards a desired vehicle.
#### Traffic signs and traffic lights
```py
spectator = world.get_spectator()
transform = vehicle.get_transform()
spectator.set_transform(carla.Transform(transform.location + carla.Location(z=50),
carla.Rotation(pitch=-90)))
So far, CARLA only is aware of some signs: stop, yield and speed limit, described with [carla.TrafficSign](python_api.md#carla.TrafficSign). Traffic lights, which are considered an inherited class named [carla.TrafficLight](python_api.md#carla.TrafficLight). __These cannot be found on the blueprint library__ and thus, cannot be spawned. They set traffic conditions and so, they are mindfully placed by developers.
```
Traffic signs are not defined in the road map itself (more on that in the following page). Instead, they have a [carla.BoundingBox](python_api.md#carla.BoundingBox) that triggers when a vehicle is inside of it and thus, affected by the traffic sign.
### Traffic signs and traffic lights
So far, CARLA only is aware of some signs: stop, yield and speed limit. Traffic lights are considered an inherited class from the more general traffic sign. __None of these can be found in the blueprint library__ and thus, cannot be spawned. They set traffic conditions, so they are mindfully placed by developers.
[__Traffic signs__](python_api.md#carla.TrafficSign) are not defined in the road map itself, as explained in the following page. Instead, they have a [carla.BoundingBox](python_api.md#carla.BoundingBox) to affect vehicles inside of it.
```py
#Get the traffic light affecting a vehicle
if vehicle_actor.is_at_traffic_light():
traffic_light = vehicle_actor.get_traffic_light()
```
!!! Note
Traffic lights will only affect a vehicle if the light is red.
Vehicles will only notice a traffic light if the light is red.
Regarding traffic lights, they are found in junctions so they belong to a `group` and identify with a `pole` number inside the group.
A group of traffic lights follows a cycle in which a pole is set to green, yellow and then red while the rest remain frozen in red. After spending a certain amount of seconds per state (including red, meaning there is a period of time in which all lights are red), the next pole starts its cycle and the previous one is frozen with the rest.
State and time per state can be easily accessed using _get()_ and _set()_ methods described in said class. Possible states are described with [carla.TrafficLightState](python_api.md#carla.TrafficLightState) as a series of enum values.
[__Traffic lights__](python_api.md#carla.TrafficLight) are found in junctions. They have their unique ID, as any actor, but also a `group` ID for the junction. To identify the traffic lights in the same group, a `pole` ID is used.
The traffic lights in the same group follow a cycle. The first one is set to green while the rest remain frozen in red. The active one spends a few seconds in green, yellow and red, so there is a period of time where all the lights are red. Then, the next traffic light starts its cycle, and the previous one is frozen with the rest.
The state of a traffic light can be set using the API. So does the seconds spent on each state. Possible states are described with [carla.TrafficLightState](python_api.md#carla.TrafficLightState) as a series of enum values.
```py
#Change a red traffic light to green
if traffic_light.get_state() == carla.TrafficLightState.Red:
traffic_light.set_state(carla.TrafficLightState.Green)
traffic_light.set_set_green_time(4.0)
```
* **Speed limit signs** with the speed codified in their type_id.
### Vehicles
#### Vehicles
[__carla.Vehicle__](python_api.md#carla.Vehicle) are a special type of actor. They are remarkable for having better physics. This is achieved applying four types of different controls.
[carla.Vehicle](python_api.md#carla.Vehicle) are a special type of actor that provide some better physics control. This is achieved applying four types of different controls:
* __[carla.VehicleControl](python_api.md#carla.VehiclePhysicsControl)__: provides input for driving commands such as throttle, steering, brake, etc.
* __[carla.VehicleControl](python_api.md#carla.VehiclePhysicsControl)__ provides input for driving commands such as throttle, steering, brake, etc.
```py
vehicle.apply_control(carla.VehicleControl(throttle=1.0, steer=-1.0))
```
* __[carla.VehiclePhysicsControl](python_api.md#carla.VehiclePhysicsControl)__: defines many physical attributes of the vehicle from mass and drag coefficient up to torque, maximum rpm, clutch strenght and many more. These controller contains within two more controllers. One is for the gears, [carla.GearPhysicsControl](python_api.md#carla.GearPhysicsControl), the other is a list of [carla.WheelPhysicsControl](python_api.md#carla.WheelPhysicsControl) that provide specific control over the different wheels of the vehicle for a realistic result.
* __[carla.VehiclePhysicsControl](python_api.md#carla.VehiclePhysicsControl)__ defines physical attributes of the vehicle. Besides many different attribute, this controller contains two more controllers. [carla.GearPhysicsControl](python_api.md#carla.GearPhysicsControl) for the gears. The other is a list of [carla.WheelPhysicsControl](python_api.md#carla.WheelPhysicsControl), that provide specific control over the different wheels.
```py
vehicle.apply_physics_control(carla.VehiclePhysicsControl(max_rpm = 5000.0, center_of_mass = carla.Vector3D(0.0, 0.0, 0.0), torque_curve=[[0,400],[5000,400]]))
```
Vehicles can be set to an __autopilot mode__ which will subscribe them to the Traffic manager, an advanced CARLA module that needs its own section to be fully comprehended. For now, it is enough to know that it conducts all the vehicles set to autopilot in order to simulate real urban conditions:
```py
vehicle.set_autopilot(True)
```
!!! Note
The traffic manager module is hard-coded, not based on machine learning.
Finally, vehicles also have a [carla.BoundingBox](python_api.md#carla.BoundingBox) that encapsulates them and is used for collision detection:
In order to apply physics and detect collisions, vehicles have a [carla.BoundingBox](python_api.md#carla.BoundingBox) encapsulating them.
```py
box = vehicle.bounding_box
@ -217,21 +224,43 @@ print(box.location) # Location relative to the vehicle.
print(box.extent) # XYZ half-box extents in meters.
```
#### Walkers
Vehicles include other functionalities unique to them.
[carla.Walker](python_api.md#carla.Walker) are moving actors and so, work in quite a similar way as vehicles do. Control over them is provided by controllers:
* The __autopilot mode__ will subscribe them to the [Traffic manager](adv_traffic_manager.md), and simulate real urban conditions. This module is hard-coded, not based on machine learning.
* __[carla.WalkerControl](python_api.md#carla.Walker)__: to move the pedestrian around with a certain direction and speed. It also allows them to jump.
* __[carla.WalkerBoneControl](python_api.md#carla.Walker)__: provides control over the specific bones of the 3D model. The skeleton structure and how to control it is summarized in this __[How to](tuto_G_control_walker_skeletons.md)__.
```py
vehicle.set_autopilot(True)
```
* __Vehicle lights__ created specifically for each vehicle model. They can be accessed from the API. In order to turn them on/off, the vehicle uses flag values. These are defined in [carla.VehicleLightState](python_api.md#carla.VehicleLightState) and binary operations are used to combine them.
Walkers can be AI controlled. They do not have an autopilot mode, but there is another actor, [carla.WalkerAIController](python_api.md#carla.WalkerAIController) that, when spawned attached to a walker, can move them around:
```py
# Turn on position lights
current_lights = carla.VehicleLightState.NONE
current_lights |= carla.VehicleLightState.Position
vehicle.set_light_state(current_lights)
```
!!! Note
So far, vehicle lights have been implemented only for a specific set of vehicles, listed in the [release post](http://carla.org/2020/03/09/release-0.9.8/#vehicle-lights).
### Walkers
[__carla.Walker__](python_api.md#carla.Walker) work in a similar way as vehicles do. Control over them is provided by controllers.
* [__carla.WalkerControl__](python_api.md#carla.Walker) moves the pedestrian around with a certain direction and speed. It also allows them to jump.
* [__carla.WalkerBoneControl__](python_api.md#carla.Walker) provides control over the 3D skeleton. [This tutorial](tuto_G_control_walker_skeletons.md) explains how to control it.
Walkers can be AI controlled. They do not have an autopilot mode. The [__carla.WalkerAIController__](python_api.md#carla.WalkerAIController) actor moves around the actor it is attached to.
```py
walker_controller_bp = world.get_blueprint_library().find('controller.ai.walker')
world.SpawnActor(walker_controller_bp, carla.Transform(), parent_walker)
```
The AI controller is bodiless, so it will not appear on scene. Passing location (0,0,0) relative to its parent will not cause a collision.
For the walkers to start wandering around, each AI controller has to be initialized, set a goal and optionally a speed. Stopping the controller works in the same manner:
!!! Note
The AI controller is bodiless and has no physics. It will not appear on scene. Also, location `(0,0,0)` relative to its parent will not cause a collision.
__Each AI controller needs initialization, a goal and, optionally, a speed__. Stopping the controller works in the same manner.
```py
ai_controller.start()
@ -240,26 +269,25 @@ ai_controller.set_max_speed(1 + random.random()) # Between 1 and 2 m/s (default
...
ai_controller.stop()
```
When a walker reaches the target location, they will automatically walk to another random point. If the target point is not reachable, then they reach the closest point from the are where they are.
When a walker reaches the target location, they will automatically walk to another random point. If the target point is not reachable, walkers will go to the closest point from their current location.
For a more advanced reference on how to use this, take a look at [this recipe](ref_code_recipes.md#walker-batch-recipe) where a lot of walkers is spawned and set to wander around using batches.
[This recipe](ref_code_recipes.md#walker-batch-recipe) uses batches to spawn a lot of walkers and make them wander around.
!!! Note
To **destroy the pedestrians**, the AI controller needs to be stopped first and then, both actor and controller should be destroyed.
!!! Important
__To destroy AI pedestrians__, stop the AI controller and destroy both, the actor, and the controller.
---
That is a wrap as regarding actors in CARLA.
The next step should be learning more about the map, roads and traffic in CARLA. Keep reading to learn more or visit the forum to post any doubts or suggestions that have come to mind during this reading:
That is a wrap as regarding actors in CARLA. The next step takes a closer look into the map, roads and traffic in CARLA.
Keep reading to learn more or visit the forum to post any doubts or suggestions that have come to mind during this reading.
<div text-align: center>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="forum.carla.org" target="_blank" class="btn btn-neutral" title="CARLA forum">
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="CARLA forum">
CARLA forum</a>
</p>
</div>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="../core_map" target="_blank" class="btn btn-neutral" title="3rd. Maps and navigation">
3rd. Maps and navigation</a>

55
Docs/core_concepts.md
View File

@ -1,7 +1,8 @@
# Core concepts
This section summarizes the main features and modules in CARLA. While this page is just an overview, the rest of the information can be found in their respective pages, including fragments of code and in-depth explanations.
In order to learn everything about the different classes and methods in the API, take a look at the [Python API reference](python_api.md). There is also another reference named [Code recipes](ref_code_recipes.md) containing some of the most common fragments of code regarding different functionalities that could be specially useful during these first steps.
This page introduces the main features and modules in CARLA. Detailed explanations of the different subjects can be found in their corresponding page.
In order to learn about the different classes and methods in the API, take a look at the [Python API reference](python_api.md). Besides, the [Code recipes](ref_code_recipes.md) reference contains some common code chunks, specially useful during these first steps.
* [__First steps__](#first-steps)
* 1st. World and client
@ -17,14 +18,14 @@ In order to learn everything about the different classes and methods in the API,
---
## First steps
#### 1st. World and client
### 1st. World and client
The client is the module the user runs to ask for information or changes in the simulation. It communicates with the server via terminal. A client runs with an IP and a specific port. There can be many clients running at the same time, although multiclient managing needs a full comprehension on CARLA in order to make things work properly.
__The client__ is the module the user runs to ask for information or changes in the simulation. A client runs with an IP and a specific port. It communicates with the server via terminal. There can be many clients running at the same time. Advanced multiclient managing requires thorough understanding of CARLA and [synchrony](adv_synchrony_timestep.md).
The world is an object representing the simulation, an abstract layer containing the main methods to manage it: spawn actors, change the weather, get the current state of the world, etc. There is only one world per simulation, but it will be destroyed and substituted for a new one when the map is changed.
__The world__ is an object representing the simulation. It acts as an abstract layer containing the main methods to spawn actors, change the weather, get the current state of the world, etc. There is only one world per simulation. It will be destroyed and substituted for a new one when the map is changed.
#### 2nd. Actors and blueprints
In CARLA, an actor is anything that plays a role in the simulation. That includes:
### 2nd. Actors and blueprints
An actor is anything that plays a role in the simulation.
* Vehicles.
* Walkers.
@ -32,17 +33,21 @@ In CARLA, an actor is anything that plays a role in the simulation. That include
* The spectator.
* Traffic signs and traffic lights.
A blueprint is needed in order to spawn an actor. __Blueprints__ are a set of already-made actor layouts: models with animations and different attributes. Some of these attributes can be set by the user, others don't. There is a library provided by CARLA containing all the available blueprints and the information regarding them. Visit the [Blueprint library](bp_library.md) to learn more about this.
__Blueprints__ are already-made actor layouts necessary to spawn an actor. Basically, models with animations and a set of attributes. Some of these attributes can be customized by the user, others don't. There is a [__Blueprint library__](bp_library.md) containing all the blueprints available as well as information on them.
#### 3rd. Maps and navigation
### 3rd. Maps and navigation
The map is the object representing the model of the world. There are many maps available, seven by the time this is written, and all of them use OpenDRIVE 1.4 standard to describe the roads.
Roads, lanes and junctions are managed by the API to be accessed using different classes and methods. These are later used along with the waypoint class to provide vehicles with a navigation path.
Traffic signs and traffic lights have bounding boxes placed on the road that make vehicles aware of them and their current state in order to set traffic conditions.
__The map__ is the object representing the simulated world, the town mostly. There are seven maps available. All of them use OpenDRIVE 1.4 standard to describe the roads.
#### 4th. Sensors and data
__Roads, lanes and junctions__ are managed by the [Python API](python_api.md) to be accessed from the client. These are used along with the __waypoint__ class to provide vehicles with a navigation path.
Sensors are one of the most important actors in CARLA and their use can be quite complex. A sensor is attached to a parent vehicle and follows it around, gathering information of the surroundings for the sake of learning. Sensors, as any other actor, have blueprints available in the [Blueprint library](bp_library.md) that correspond to the types available. Currently, these are:
__Traffic signs__ and __traffic lights__ have bounding boxes placed on the road. Vehicles become aware of them once inside their bounding box.
### 4th. Sensors and data
__Sensors__ wait for some event to happen, and then gather data from the simulation. They call for a function defining how to manage the data. Depending on which, sensors retrieve different types of __sensor data__.
A sensor is an actor attached to a parent vehicle. It follows the vehicle around, gathering information of the surroundings. The sensors available are defined by their blueprints in the [Blueprint library](bp_library.md).
* Cameras (RGB, depth and semantic segmentation).
* Collision detector.
@ -53,31 +58,29 @@ Sensors are one of the most important actors in CARLA and their use can be quite
* Obstacle detector.
* Radar.
Sensors wait for some event to happen to gather data and then call for a function defining what they should do. Depending on which, sensors retrieve different types of data in different ways and their usage varies substantially.
---
## Advanced steps
Some more complex elements and features in CARLA are listed here to make newcomers familiar with their existence. However it is highly encouraged to first take a closer look to the pages regarding the first steps in order to learn the basics.
Hereunder are listed some advanced CARLA features. However, it is highly encouraged to first take a closer look to the pages regarding the first steps in order to learn the basics.
- **Recorder:** CARLA feature that allows for reenacting previous simulations using snapshots of the world.
- **Rendering options:** Some advanced configuration options in CARLA that allow for different graphics quality, off-screen rendering and a no-rendering mode.
- **Simulation time and synchrony:** Everything regarding the simulation time and how does the server run the simulation depending on clients.
- **Traffic manager:** This module is in charge of every vehicle set to autopilot mode. It conducts the traffic in the city for the simulation to look like a real urban environment.
* __Recorder.__ Allows for reenacting previous simulations using snapshots of the world.
* __Rendering options.__ Graphics quality settings, off-screen rendering and a no-rendering mode.
* __Simulation time and synchrony.__ Everything regarding the simulation time and server-client communication.
* __Traffic manager.__ This module is in charge of every vehicle set to autopilot mode. It simulates traffic in the city for the simulation to look like a real urban environment.
---
That sums up the basics necessary to understand CARLA.
However, these broad strokes are just a big picture of the system.The next step should be learning more about the world of the simulation and the clients connecting to it. Keep reading to learn more or visit the forum to post any doubts or suggestions that have come to mind during this reading:
That is a wrap on the CARLA basics. The next step takes a closer look to the world and the clients connecting to it.
Keep reading to learn more. Visit the forum to post any doubts or suggestions that have come to mind during this reading.
<div text-align: center>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="forum.carla.org" target="_blank" class="btn btn-neutral" title="CARLA forum">
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="CARLA forum">
CARLA forum</a>
</p>
</div>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="../core_world" target="_blank" class="btn btn-neutral" title="1st. World and client">
1st. World and client</a>

243
Docs/core_map.md
View File

@ -2,92 +2,99 @@
After discussing about the world and its actors, it is time to put everything into place and understand the map and how do the actors navigate it.
* [__The map__](#the-map)
* [__The map__](#the-map)
* Map changing
* Lanes
* Junctions
* Waypoints
* [__Map navigation__](#map-navigation)
* [__Navigation in CARLA__](#navigation-in-carla)
* [__CARLA maps__](#carla-maps)
---
## The map
Understanding the map in CARLA is equivalent to understanding the road. All of the maps have an OpenDRIVE file defining the road layout fully annotated. The way the [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) defines roads, lanes, junctions, etc. is extremely important. It determines the possibilities of the API and the reasoning behind many decisions made.
The Python API provides a higher level querying system to navigate these roads. It is constantly evolving to provide a wider set of tools.
A map includes both the 3D model of a town and its road definition. Every map is based on an OpenDRIVE file describing the road layout fully annotated. The way the [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) defines roads, lanes, junctions, etc. is extremely important. It determines the possibilities of the API and the reasoning behind decisions made.
#### Changing the map
The Python API makes for a high level querying system to navigate these roads. It is constantly evolving to provide a wider set of tools.
This was briefly mentioned in [1st. World and client](core_world.md), so let's expand a bit on it: __To change the map, the world has to change too__. Everything will be rebooted and created from scratch, besides the Unreal Editor itself.
Using `reload_world()` creates a new instance of the world with the same map while `load_world()` is used to change the current one:
### Changing the map
__To change the map, the world has to change too__. Everything will be rebooted and created from scratch, besides the Unreal Editor itself. There are two ways to do so.
* `reload_world()` creates a new instance of the world with the same map.
* `load_world()` changes the current map and creates a new world.
```py
world = client.load_world('Town01')
```
The client can also get a list of available maps. Each map has a `name` attribute that matches the name of the currently loaded city, e.g. _Town01._:
The client can get a list of available maps. Each map has a `name` attribute that matches the name of the currently loaded city, e.g. _Town01_.
```py
print(client.get_available_maps())
```
So far there are seven different maps available. Each of these has a specific structure or unique features that are useful for different purposes, so a brief sum up on these:
|Town | Summary |
| -- | -- |
|__Town 01__ | As __Town 02__, a basic town layout with all "T junctions". These are the most stable.|
|__Town 02__ | As __Town 01__, a basic town layout with all "T junctions". These are the most stable.|
|__Town 03__ | The most complex town with a roundabout, unevenness, a tunnel. Essentially a medley.|
|__Town 04__ | An infinite loop in a highway.|
|__Town 05__ | Squared-grid town with cross junctions and a bridge.|
|__Town 06__ | Long highways with a lane exit and a [Michigan left](https://en.wikipedia.org/wiki/Michigan_left). |
|__Town 07__ | A rural environment with narrow roads, barely non traffic lights and barns.|
### Lanes
<br>
The lane types defined by [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) are translated to the API in [__carla.LaneType__](python_api.md#carla.LaneType) as a series of enum values.
Users can also [customize a map](tuto_A_map_customization.md) or even [create a new map](tuto_A_map_creation.md) to be used in CARLA. These are more advanced steps and have been developed in their own tutorials.
The lane markings surrounding a lane can be accessed through [__carla.LaneMarking__](python_api.md#carla.LaneMarkingType). These are defined with a series of variables.
* [__carla.LaneMarkingType__](python_api.md#carla.LaneMarkingType) are enum values according to OpenDRIVE standards.
* [__carla.LaneMarkingColor__](python_api.md#carla.LaneMarkingColor) are enum values to determine the color of the marking.
* __width__ to state thickness of the marking.
* [__carla.LaneChange__](python_api.md#carla.LaneChange) to state permissions to perform lane changes.
#### Lanes
The different types of lane as defined by [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) are translated to the API in [carla.LaneType](python_api.md#carla.LaneType). The surrounding lane markings for each lane can also be accessed using [carla.LaneMarking](python_api.md#carla.LaneMarkingType).
A lane marking is defined by: a [carla.LaneMarkingType](python_api.md#carla.LaneMarkingType) and a [carla.LaneMarkingColor](python_api.md#carla.LaneMarkingColor), a __width__ to state thickness and a variable stating lane changing permissions with [carla.LaneChange](python_api.md#carla.LaneChange).
Both lanes and lane markings are accessed by waypoints to locate a vehicle within the road and aknowledge traffic permissions.
Waypoints use these to aknowledge traffic permissions.
```py
# Get the lane type where the waypoint is.
lane_type = waypoint.lane_type
# Get the type of lane marking on the left.
left_lanemarking_type = waypoint.left_lane_marking.type()
# Get available lane changes for this waypoint.
lane_change = waypoint.lane_change
```
#### Junctions
### Junctions
A [carla.Junction](python_api.md#carla.Junction) represents an OpenDRIVE junction. This class provides for a bounding box to state whereas lanes or vehicles are inside of it.
The most remarkable method of this class returns a pair of waypoints per lane inside the junction. Each pair is located at the starting and ending point of the junction boundaries.
To ease managing junctions with OpenDRIVE, the [carla.Junction](python_api.md#carla.Junction) class provides for a bounding box to state whereas lanes or vehicles are inside of it.
There is also a method to get a pair of waypoints per lane determining the starting and ending point inside the junction boundaries for each lane:
```py
waypoints_junc = my_junction.get_waypoints()
```
#### Waypoints
### Waypoints
[carla.Waypoint](python_api.md#carla.Waypoint) objects are 3D-directed points that are prepared to mediate between the world and the openDRIVE definition of the road.
Each waypoint contains a [carla.Transform](python_api.md#carla.Transform) summarizing a point on the map inside a lane and the orientation of the lane. The variables `road_id`,`section_id`,`lane_id` and `s` that translate this transform to the OpenDRIVE road and are used to create an __identifier__ of the waypoint.
A [__carla.Waypoint__](python_api.md#carla.Waypoint) is a 3D-directed point. These are prepared to mediate between the world and the openDRIVE definition of the road.
Each waypoint contains a [carla.Transform](python_api.md#carla.Transform). This states its location on the map and the orientation of the lane containing it. The variables `road_id`,`section_id`,`lane_id` and `s` translate this transform to the OpenDRIVE road. These combined, create the `id` of the waypoint.
!!! Note
Due to granularity, waypoints closer than __2cm within the same road__ will share the same `id`.
Due to granularity, waypoints closer than __2cm within the same road__ share the same `id`.
Besides that, each waypoint also contains some information regarding the __lane__ it is contained in and its left and right __lane markings__ and a boolean to determine when it is inside a junction:
A waypoint also contains some information regarding the __lane__ containing it. Specifically its left and right __lane markings__, and a boolean to determine if it is inside a junction.
```py
# Examples of a waypoint accessing to lane information
inside_junction = waypoint.is_junction()
width = waypoint.lane_width
# Get right lane marking color
right_lm_color = waypoint.right_lane_marking.color
```
Finally regarding navigation, waypoints have a set of methods to ease the flow inside the road:
The `next(d)` creates new waypoint at an approximate distance `d` following the direction of the current lane, while `previous(d)` will do so on the opposite direction.
`next_until_lane_end(d)` and `previous_until_lane_start(d)` will use said distance to find a list of equally distant waypoints contained in the lane. All of these methods follow traffic rules to determine only places where the vehicle can go:
---
## Navigation in CARLA
### Navigating through waypoints
Waypoints have a set of methods to connect with others and create a road flow. All of these methods follow traffic rules to determine only places where the vehicle can go.
* `next(d)` creates a list of waypoints at an approximate distance `d` __in the direction of the lane__. The list contains one waypoint for each deviation possible.
* `previous(d)` creates a list of waypoints waypoint at an approximate distance `d` __on the opposite direction of the lane__. The list contains one waypoint for each deviation possible.
* `next_until_lane_end(d)` and `previous_until_lane_start(d)` returns a list of waypoints a distance `d` apart. The list goes from the current waypoint to the end and start of its lane, respectively.
* `get_right_lane()` and `get_left_lane()` return the equivalent waypoint in an adjacent lane, if any. A lane change maneuver can be made by finding the next waypoint to the one on its right/left lane, and moving to it.
```py
# Disable physics, in this example the vehicle is teleported.
vehicle.set_simulate_physics(False)
@ -98,66 +105,188 @@ while True:
vehicle.set_transform(waypoint.transform)
```
!!! Note
These methods return a list. If there is more than one possible location (for example at junctions where the lane diverges), the returned list will contain as many waypoints.
### Generating a map navigation
Waypoints can also find their equivalent at the center of an adjacent lane (if said lane exists) using `get_right_lane()` and `get_left_lane()`. This is useful to find the next waypoint on a neighbour lane to then perform a lane change:
The instance of the map is provided by the world. It will be useful to create routes and make vehicles roam around the city and reach goal destinations.
---
## Map Navigation
The instance of the map is provided by the world. Once it is retrieved, it provides acces to different methods that will be useful to create routes and make vehicles roam around the city and reach goal destinations:
```py
map = world.get_map()
```
* __Get recommended spawn points for vehicles__: assigned by developers with no ensurance of the spot being free:
* __Get recommended spawn points for vehicles__ pointed by developers. There is no ensurance that these spots will be free.
```py
spawn_points = world.get_map().get_spawn_points()
```
* __Get a waypoint__: returns the closest waypoint for a specific location in the simulation or the one belonging to a certain `road_id`, `lane_id` and `s` in OpenDRIVE:
* __Get the closest waypoint__ to a specific location or to a certain `road_id`, `lane_id` and `s` in OpenDRIVE.
```py
# Nearest waypoint on the center of a Driving or Sidewalk lane.
waypoint01 = map.get_waypoint(vehicle.get_location(),project_to_road=True, lane_type=(carla.LaneType.Driving | carla.LaneType.Sidewalk))
#Nearest waypoint but specifying OpenDRIVE parameters.
waypoint02 = map.get_waypoint_xodr(road_id,lane_id,s)
```
* __Generate a collection of waypoitns__: to visualize the city lanes. Creates waypoints all over the map for every road and lane at an approximated distance between them:
* __Generate a collection of waypoints__ to visualize the city lanes. Creates waypoints all over the map, for every road and lane. All of them will be an approximate distance apart.
```py
waypoint_list = map.generate_waypoints(2.0)
```
* __Generate road topology__: useful for routing. Returns a list of pairs (tuples) of waypoints. For each pair, the first element connects with the second one and both define the starting and ending point of each lane in the map:
* __Generate road topology__. Returns a list of pairs (tuples) of waypoints. For each pair, the first element connects with the second one and both define the starting and ending point of each lane in the map.
```py
waypoint_tuple_list = map.get_topology()
```
* __Simulation point to world coordinates__: transforms a certain location to world coordinates with latitude and longitude defined with the [carla.Geolocation](python_api.md#carla.Geolocation):
* __Convert simulation point to geographical coordinates.__ Transforms a certain location to a [carla.Geolocation](python_api.md#carla.Geolocation) with latitude and longitude values.
```py
my_geolocation = map.transform_to_geolocation(vehicle.transform)
```
* __Road information__: converts road information to OpenDRIVE format, and saved to disk:
* __Save road information.__ Converts the road information to OpenDRIVE format, and saves it to disk.
```py
info_map = map.to_opendrive()
```
---
That is a wrap as regarding maps and navigation around the cities in CARLA.
The next step should be learning more about sensors, the different types and the data they retrieve. Keep reading to learn more or visit the forum to post any doubts or suggestions that have come to mind during this reading:
## CARLA maps
So far there are seven different maps available. Each one has unique features and is useful for different purposes. Hereunder is a brief sum up on them.
!!! Note
Users can [customize a map](tuto_A_map_customization.md) or even [create a new map](tuto_A_map_creation.md) to be used in CARLA.
<table class ="defTable">
<thead>
<th>Town</th>
<th>Summary</th>
</thead>
<tbody>
<td><b>Town01</b></td>
<td>A basic town layout with all "T junctions".</td>
</tr>
<tr>
<td><b>Town02</b></td>
<td>Similar to <b>Town01</b>, but smaller.</td>
</tr>
<tr>
<td><b>Town03</b></td>
<td>The most complex town, with a 5-lane junction, a roundabout, unevenness, a tunnel, and much more. Essentially a medley.</td>
</tr>
<tr>
<td><b>Town04</b></td>
<td>An infinite loop with a highway and a small town.</td>
</tr>
<tr>
<td><b>Town05</b></td>
<td>Squared-grid town with cross junctions and a bridge. It has multiple lanes per direction. Useful to perform lane changes.</td>
</tr>
<tr>
<td><b>Town06</b></td>
<td>Long highways with many highway entrances and exits. It also has a <a href="https://en.wikipedia.org/wiki/Michigan_left"><b>Michigan left</b></a>.</td>
<tr>
<td><b>Town07</b></td>
<td>A rural environment with narrow roads, barely non traffic lights and barns.</td>
</tbody>
</table>
<br>
<!--container -->
<div class="townslider-container">
<!-- Town slide images -->
<div class="townslide fade">
<img src="../img/Town01.png">
<div class="text">Town01</div>
</div>
<div class="townslide fade">
<img src="../img/Town02.png">
<div class="text">Town02</div>
</div>
<div class="townslide fade">
<img src="../img/Town03.png">
<div class="text">Town03</div>
</div>
<div class="townslide fade">
<img src="../img/Town04.png">
<div class="text">Town04</div>
</div>
<div class="townslide fade">
<img src="../img/Town05.png">
<div class="text">Town05</div>
</div>
<div class="townslide fade">
<img src="../img/Town06.png">
<div class="text">Town06</div>
</div>
<div class="townslide fade">
<img src="../img/Town07.png">
<div class="text">Town07</div>
</div>
<!-- Next and previous buttons -->
<a class="prev" onclick="plusSlides(-1)">&#10094;</a>
<a class="next" onclick="plusSlides(1)">&#10095;</a>
</div>
<!-- The dots -->
<div style="text-align:center">
<span class="dot" onclick="currentSlide(1)"></span>
<span class="dot" onclick="currentSlide(2)"></span>
<span class="dot" onclick="currentSlide(3)"></span>
<span class="dot" onclick="currentSlide(4)"></span>
<span class="dot" onclick="currentSlide(5)"></span>
<span class="dot" onclick="currentSlide(6)"></span>
<span class="dot" onclick="currentSlide(7)"></span>
</div>
<script>
var slideIndex = 1;
showSlides(slideIndex);
function plusSlides(n) {
showSlides(slideIndex += n);
}
function currentSlide(n) {
showSlides(slideIndex = n);
}
function showSlides(n) {
var i;
var slides = document.getElementsByClassName("townslide");
var dots = document.getElementsByClassName("dot");
if (n > slides.length) {slideIndex = 1}
if (n < 1) {slideIndex = slides.length}
for (i = 0; i < slides.length; i++) {
slides[i].style.display = "none";
}
for (i = 0; i < dots.length; i++) {
dots[i].className = dots[i].className.replace(" active", "");
}
slides[slideIndex-1].style.display = "block";
dots[slideIndex-1].className += " active";
}
</script>
<br>
---
That is a wrap as regarding maps and navigation in CARLA. The next step takes a closer look into sensors types, and the data they retrieve.
Keep reading to learn more or visit the forum to post any doubts or suggestions that have come to mind during this reading.
<div text-align: center>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="forum.carla.org" target="_blank" class="btn btn-neutral" title="CARLA forum">
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="CARLA forum">
CARLA forum</a>
</p>
</div>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="../core_sensors" target="_blank" class="btn btn-neutral" title="4th. Sensors and data">
4th. Sensors and data</a>

194
Docs/core_sensors.md
View File

@ -1,14 +1,15 @@
# 4th. Sensors and data
The last step in this introduction to CARLA are sensors. They allow to retrieve data from the surroundings and so, are crucial to use CARLA as a learning environment for driving agents.
This page summarizes everything necessary to start handling sensors including some basic information about the different types available and a step-by-step of their life cycle. The specifics for every sensor can be found in their [reference](ref_sensors.md)
Sensors are actors that retrieve data from their surroundings. They are crucial to create learning environment for driving agents.
* [__Sensors step-by-step__](#sensors-step-by-step):
This page summarizes everything necessary to start handling sensors. It introduces the types available and a step-by-step guide of their life cycle. The specifics for every sensor can be found in the [sensors reference](ref_sensors.md).
* [__Sensors step-by-step__](#sensors-step-by-step)
* Setting
* Spawning
* Listening
* Destroying
* [__Types of sensors__](#types-of-sensors)
* Data
* [__Types of sensors__](#types-of-sensors)
* Cameras
* Detectors
* Other
@ -18,17 +19,18 @@ This page summarizes everything necessary to start handling sensors including so
The class [carla.Sensor](python_api.md#carla.Sensor) defines a special type of actor able to measure and stream data.
* __What is this data?__ It varies a lot depending on the type of sensor, but the data is always defined as an inherited class of the general [carla.SensorData](python_api.md#carla.SensorData).
* __What is this data?__ It varies a lot depending on the type of sensor. All the types of data are inherited from the general [carla.SensorData](python_api.md#carla.SensorData).
* __When do they retrieve the data?__ Either on every simulation step or when a certain event is registered. Depends on the type of sensor.
* __How do they retrieve the data?__ Every sensor has a `listen()` method that receives and manages the data.
* __How do they retrieve the data?__ Every sensor has a `listen()` method to receive and manage the data.
Despite their differences, the way the user manages every sensor is quite similar.
Despite their differences, all the sensors are used in a similar way.
#### Setting
### Setting
As with every other actor, the first step is to find the proper blueprint in the library and set specific attributes to get the desired results. This is essential when handling sensors, as their capabilities depend on the way these are set. Their attributes are detailed in the [sensors' reference](ref_sensors.md).
As with every other actor, find the blueprint and set specific attributes. This is essential when handling sensors. Their attributes will determine the results obtained. These are detailed in the [sensors reference](ref_sensors.md).
The following example sets a dashboard HD camera.
The following example sets ready a dashboard HD camera that will later be attached to a vehicle.
```py
# Find the blueprint of the sensor.
blueprint = world.get_blueprint_library().find('sensor.camera.rgb')
@ -40,26 +42,25 @@ blueprint.set_attribute('fov', '110')
blueprint.set_attribute('sensor_tick', '1.0')
```
#### Spawning
### Spawning
Sensors are also spawned like any other actor, only this time the two optional parameters, `attachment_to` and `attachment_type` are crucial. They should be attached to another actor, usually a vehicle, to follow it around and gather the information regarding its surroundings.
There are two types of attachment:
`attachment_to` and `attachment_type`, are crucial. Sensors should be attached to a parent actor, usually a vehicle, to follow it around and gather the information. The attachment type will determine how its position is updated regarding said vehicle.
* __Rigid__: the sensor's location will be updated strictly regarding its parent. Cameras may show "little hops" as the moves are not eased.
* __SpringArm__: movement will be eased with little accelerations and decelerations.
* __Rigid attachment.__ Movement is strict regarding its parent location. Cameras may show "little hops" as the position updated is not eased.
* __SpringArm attachment.__ Movement is eased with little accelerations and decelerations.
```py
transform = carla.Transform(carla.Location(x=0.8, z=1.7))
sensor = world.spawn_actor(blueprint, transform, attach_to=my_vehicle)
```
!!! Important
When spawning an actor with attachment, remember that its location should be relative to its parent, not global.
When spawning with attachment, location must be relative to the parent actor.
#### Listening
### Listening
Every sensor has a [`listen()`](python_api.md#carla.Sensor.listen) method that is called every time the sensor retrieves data.
This method has one argument: `callback`, which is a [lambda expression](https://www.w3schools.com/python/python_lambda.asp) of a function, defining what should the sensor do when data is retrieved.
The lambda function must have at least one argument, which will be the retrieved data:
Every sensor has a [`listen()`](python_api.md#carla.Sensor.listen) method. This is called every time the sensor retrieves data.
The argument `callback` is a [lambda function](https://www.w3schools.com/python/python_lambda.asp). It describes what should the sensor do when data is retrieved. This must have the data retrieved as an argument.
```py
# do_something() will be called each time a new image is generated by the camera.
@ -76,91 +77,155 @@ def callback(event):
sensor02.listen(callback)
```
!!! note
`is_listening` is a __sensor attribute__ that enables/disables data listening at will.
Similarly, `sensor_tick` is a __blueprint attribute__ that allows to set the simulation time between data received so that this is not retrieved every step.
### Data
Most sensor data objects have a function for saving the measurements to disk so it can be later used in other environments.
Sensor data differs a lot between sensor types, but it is always tagged with:
Most sensor data objects have a function to save the information to disk. This will allow it to be used in other environments.
| Sensor data attribute | Type | Description |
| --------------------- | ------ | ----------- |
| `frame` | int | Frame number when the measurement took place. |
| `timestamp` | double | Timestamp of the measurement in simulation seconds since the beginning of the episode. |
| `transform` | carla.Transform | World reference of the sensor at the time of the measurement. |
Sensor data differs a lot between sensor types. Take a look at the [sensors reference](ref_sensors.md) to get a detailed explanation. However, all of them are always tagged with some basic information.
<table class ="defTable">
<thead>
<th>Sensor data attribute</th>
<th>Type</th>
<th>Description</th>
</thead>
<tbody>
<td><code>frame</code> </td>
<td>int</td>
<td>Frame number when the measurement took place.</td>
<tr>
<td><code>timestamp</code> </td>
<td>double</td>
<td>Timestamp of the measurement in simulation seconds since the beginning of the episode.</td>
<tr>
<td><code>transform</code> </td>
<td><a href="../python_api#carlatransform">carla.Transform</a></td>
<td>World reference of the sensor at the time of the measurement.</td>
</tbody>
</table>
<br>
!!! Important
`is_listening` is a __sensor attribute__ that enables/disables data listening at will.
`sensor_tick` is a __blueprint attribute__ that sets the simulation time between data received.
---
## Types of sensors
#### Cameras
### Cameras
These sensors take a shot of the world from their point of view and then use the helper class to alter this image and provide different types of information.
__Retrieve data:__ every simulation step.
Take a shot of the world from their point of view. The helper class [carla.ColorConverter](python_api.md#carla.ColorConverter) will modify said image to represent different information.
| Sensor | Output | Overview |
| ---------- | ---------- | ---------- |
| Depth | [carla.Image](python_api.md#carla.Image) | Renders the depth of the elements in the field of view in a gray-scale depth map. |
| RGB | [carla.Image](python_api.md#carla.Image) | Provides clear vision of the surroundings. Looks like a normal photo of the scene. |
| Semantic segmentation | [carla.Image](python_api.md#carla.Image) | Renders elements in the field of view with a specific color according to their tags. |
* __Retrieve data__ every simulation step.
<table class ="defTable">
<thead>
<th>Sensor</th>
<th>Output</th>
<th>Overview</th>
</thead>
<tbody>
<td>Depth</td>
<td><a href="../python_api#carlaimage">carla.Image</a></td>
<td>Renders the depth of the elements in the field of view in a gray-scale map.</td>
<tr>
<td>RGB</td>
<td><a href="../python_api#carlaimage">carla.Image</a></td>
<td>Provides clear vision of the surroundings. Looks like a normal photo of the scene.</td>
<tr>
<td>Semantic segmentation</td>
<td><a href="../python_api#carlaimage">carla.Image</a></td>
<td>Renders elements in the field of view with a specific color according to their tags.</td>
</tbody>
</table>
<br>
#### Detectors
### Detectors
Sensors that retrieve data when a parent object they are attached to registers a specific event in the simulation.
__Retrieve data:__ when triggered.
Retrieve data when the object they are attached to registers a specific event.
| Sensor | Output | Overview |
| ---------- | ---------- | ---------- |
| Collision | [carla.CollisionEvent](python_api.md#carla.CollisionEvent) | Retrieves collisions between its parent and other actors. |
| Lane invasion | [carla.LaneInvasionEvent](python_api.md#carla.LaneInvasionEvent) | Registers when its parent crosses a lane marking. |
| Obstacle | [carla.ObstacleDetectionEvent](python_api.md#carla.ObstacleEvent) | Detects possible obstacles ahead of its parent. |
* __Retrieve data__ when triggered.
<table class ="defTable">
<thead>
<th>Sensor</th>
<th>Output</th>
<th>Overview</th>
</thead>
<tbody>
<td>Collision</td>
<td><a href="../python_api#carlacollisionevent">carla.CollisionEvent</a></td>
<td>Retrieves collisions between its parent and other actors.</td>
<tr>
<td>Lane invasion</td>
<td><a href="../python_api#carlalaneinvasionevent">carla.LaneInvasionEvent</a></td>
<td>Registers when its parent crosses a lane marking.</td>
<tr>
<td>Obstacle</td>
<td><a href="../python_api#carlaobstacledetectionevent">carla.ObstacleDetectionEvent</a></td>
<td>Detects possible obstacles ahead of its parent.</td>
</tbody>
</table>
<br>
#### Other
### Other
This group gathers sensors with different functionalities: navigation, measure physical properties of an object and provide 2D and 3D models of the scene.
__Retrieve data:__ every simulation step.
Different functionalities such as navigation, measurement of physical properties and 2D/3D point maps of the scene.
| Sensor | Output | Overview |
| ---------- | ---------- | ---------- |
| GNSS | [carla.GNSSMeasurement](python_api.md#carla.GNSSMeasurement) | Retrieves the geolocation location of the sensor. |
| IMU | [carla.IMUMeasurement](python_api.md#carla.IMUMeasurement) | Comprises an accelerometer, a gyroscope and a compass. |
| Lidar raycast | [carla.LidarMeasurement](python_api.md#carla.LidarMeasurement) | A rotating lidar retrieving a cloud of points to generate a 3D model the surroundings. |
| Radar | [carla.RadarMeasurement](python_api.md#carla.RadarMeasurement) | 2D point map that models elements in sight and their movement regarding the sensor. |
* __Retrieve data__ every simulation step.
<table class ="defTable">
<thead>
<th>Sensor</th>
<th>Output</th>
<th>Overview</th>
</thead>
<tbody>
<td>GNSS</td>
<td><a href="../python_api#carlagnssmeasurement">carla.GNSSMeasurement</a></td>
<td>Retrieves the geolocation of the sensor.</td>
<tr>
<td>IMU</td>
<td><a href="../python_api#carlaimumeasurement">carla.IMUMeasurement</a></td>
<td>Comprises an accelerometer, a gyroscope, and a compass.</td>
<tr>
<td>LIDAR raycast</td>
<td><a href="../python_api#carlalidarmeasurement">carla.LidarMeasurement</a></td>
<td>A rotating LIDAR. Generates a 3D point cloud modelling the surroundings.</td>
<tr>
<td>Radar</td>
<td><a href="../python_api#carlaradarmeasurement">carla.RadarMeasurement</a></td>
<td>2D point map modelling elements in sight and their movement regarding the sensor. </td>
</tbody>
</table>
<br>
---
That is a wrap on sensors and how do these retrieve simulation data and thus, the introduction to CARLA is finished. However there is yet a lot to learn. Some of the different paths to follow now are listed here:
That is a wrap on sensors and how do these retrieve simulation data.
* __Gain some practise__: if diving alone in CARLA is still frightening, it may be a good idea to try some of the code recipes provided in this documentation and combine them with the example scripts or some ideas of your own.
Thus concludes the introduction to CARLA. However there is yet a lot to learn.
* __Gain some practise.__ It may be a good idea to try some of the code recipes provided in this documentation. Combine them with the example scripts, test new ideas.
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="ref_code_recipes.md" target="_blank" class="btn btn-neutral" title="Code recipes">
Code recipes</a>
</p>
</div>
* __Continue learning__: there are other more advanced features in CARLA such as rendering options, traffic manager, the recorder, and some more. Now that some fundaments on CARLA have been provided, it is a good moment to learn about these.
* __Continue learning.__ There are some advanced features in CARLA: rendering options, traffic manager, the recorder, and some more. This is a great moment to learn on them.
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="adv_synchrony_timestep.md" target="_blank" class="btn btn-neutral" title="Synchrony and time-step">
Synchrony and time-step</a>
</p>
</div>
* __Experiment freely__: but don't forget to take a look at the __References__ section of this documentation. They contain detailed information on the classes in the Python API, sensors and their outputs, and much more.
* __Experiment freely.__ Take a look at the __References__ section of this documentation. It contains detailed information on the classes in the Python API, sensors, and much more.
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="python_api.md" target="_blank" class="btn btn-neutral" title="Python API reference">
Python API reference</a>
@ -168,10 +233,9 @@ Python API reference</a>
</div>
* __Give your two cents__: share your thoughts. Any doubts, suggestions and ideas about CARLA are welcome in the forum.
* __Give your two cents.__ Any doubts, suggestions and ideas are welcome in the forum.
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="Go to the CARLA forum">
CARLA forum</a>

115
Docs/core_world.md
View File

@ -1,13 +1,14 @@
# 1st. World and client
This is bound to be one of the first topics to learn about when entering CARLA. The client and the world are two of the fundamentals of CARLA, a necessary abstraction to operate the simulation and its actors.
This tutorial goes from defining the basics and creation of these elements to describing their possibilities without entering into higher complex matters. If any doubt or issue arises during the reading, the [CARLA forum](forum.carla.org/) is there to solve them.
The client and the world are two of the fundamentals of CARLA, a necessary abstraction to operate the simulation and its actors.
* [__The client__](#the-client):
This tutorial goes from defining the basics and creation of these elements, to describing their possibilities. If any doubt or issue arises during the reading, the [CARLA forum](forum.carla.org/) is there to solve them.
* [__The client__](#the-client)
* Client creation
* World connection
* Other client utilities
* [__The world__](#the-world):
* [__The world__](#the-world)
* World life cycle
* Get() from the world
* Weather
@ -17,92 +18,93 @@ This tutorial goes from defining the basics and creation of these elements to de
---
## The client
Clients are one of the main elements in the CARLA architecture. Using these, the user can connect to the server, retrieve information from the simulation and command changes. That is done via scripts where the client identifies itself and connects to the world to then operate with the simulation.
Besides that, the client is also able to access other CARLA modules, features and apply command batches. Command batches are relevant to this moment of the documentation, as they are useful as soon as spawning actors is required. The rest though are more advanced parts of CARLA and they will not be covered yet in this section.
The __carla.Client__ class is explained thoroughly in the [PythonAPI reference](python_api.md#carla.Client).
Clients are one of the main elements in the CARLA architecture. They connect to the server, retrieve information, and command changes. That is done via scripts. The client identifies itself, and connects to the world to then operate with the simulation.
Besides that, clients are able to access other CARLA modules, features, and apply command batches. Only command batches will be covered in this section. These are useful for basic things such as spawning lots of actors. The rest of features are more complex, and will be dealt with in other sections.
Take a look at [__carla.Client__](python_api.md#carla.Client) in the Python API reference to learn on specific methods and variables of the class.
#### Client creation
### Client creation
Two things are needed: The IP address identifying it and two TCP ports the client will be using to communicate with the server. There is an optional third parameter, an `int` to set the working threads that by default is set to all (`0`). [This code recipe](ref_code_recipes.md#parse-client-creation-arguments) shows how to parse these as arguments when running the script.
Two things are needed. The __IP__ address identifying it, and __two TCP ports__ to communicate with the server. An optional third parameter sets the amount of working threads. By default this is set to all (`0`). [This code recipe](ref_code_recipes.md#parse-client-creation-arguments) shows how to parse these as arguments when running the script.
```py
client = carla.Client('localhost', 2000)
```
By default, CARLA uses local host and port 2000 to connect but these can be changed at will. The second port will always be `n+1` (in this case, 2001).
By default, CARLA uses local host IP, and port 2000 to connect but these can be changed at will. The second port will always be `n+1`, 2001 in this case.
Once the client is created, set its time-out. This limits all networking operations so that these don't block forever the client but return an error instead if connection fails.
Once the client is created, set its __time-out__. This limits all networking operations so that these don't block the client forever. An error will be returned if connection fails.
```py
client.set_timeout(10.0) # seconds
```
It is possible to have many clients connected, as it is common to have more than one script running at a time. Just take note that working in a multiclient scheme with more advanced CARLA features such as the traffic manager or the synchronous mode is bound to make communication more complex.
It is possible to have many clients connected, as it is common to have more than one script running at a time. Working in a multiclient scheme with advanced CARLA features, such as the traffic manager, is bound to make communication more complex.
!!! Note
Client and server have different `libcarla` modules. If the versions differ due to different origin commits, issues may arise. This will not normally the case, but it can be checked using the `get_client_version()` and `get_server_version()` methods.
Client and server have different `libcarla` modules. If the versions differ, issues may arise. This can be checked using the `get_client_version()` and `get_server_version()` methods.
#### World connection
### World connection
Being the simulation running, a configured client can connect and retrieve the current world easily:
A client can connect and retrieve the current world fairly easily.
```py
world = client.get_world()
```
Using `reload_world()` the client creates a new instance of the world with the same map. Kind of a reboot method.
The client can also get a list of available maps to change the current one. This will destroy the current world and create a new one.
```py
print(client.get_available_maps())
...
world = client.load_world('Town01')
# client.reload_world() creates a new instance of the world with the same map.
```
Every world object has an `id` or episode. Everytime the client calls for `load_world()` or `reload_world()` the previous one is destroyed and the new one is created from from scratch without rebooting Unreal Engine, so this episode will change.
Every world object has an `id` or episode. Everytime the client calls for `load_world()` or `reload_world()` the previous one is destroyed. A new one is created from scratch with a new episode. Unreal Engine is not rebooted in the process.
#### Other client utilities
### Other client utilities
The main purpose of the client object is to get or change the world and many times, it is no longer used after that. However, this object is in charge of two other main tasks: accessing to advanced CARLA features and applying command batches.
The list of features that are accessed from the client object are:
The main purpose of the client object is to get or change the world. Usually it is no longer used after that. However, the client also applies command batches and accesses advanced features. These features are.
* __Traffic manager:__ this module is in charge of every vehicle set to autopilot to recreate an urban environment.
* __[Recorder](adv_recorder.md):__ allows to reenact a previous simulation using the information stored in the [snapshots]() summarizing the simulation state per frame.
* __Traffic manager.__ This module is in charge of every vehicle set to autopilot to recreate urban traffic.
* __[Recorder](adv_recorder.md).__ Allows to reenact a previous simulation. Uses [snapshots](core_world.md#world-snapshots) summarizing the simulation state per frame.
As far as batches are concerned, the latest sections in the Python API describe the [available commands](python_api.md#command.ApplyAngularVelocity). These are common functions that have been prepared to be executed in batches or lots so that they are applied during the same step of the simulation.
The following example would destroy all the vehicles contained in `vehicles_list` at once:
As for command batches, the latest sections in the Python API describe the [available commands](python_api.md#command.ApplyAngularVelocity). These are common functions prepared to be executed in lots during the same step of the simulation. They can, for instance, destroy all the vehicles contained in `vehicles_list` at once.
```py
client.apply_batch([carla.command.DestroyActor(x) for x in vehicles_list])
```
The method `apply_batch_sync()` is only available when running CARLA in [synchronous mode]() and allows to return a __command.Response__ per command applied.
`apply_batch_sync()` is only available in [synchronous mode](adv_synchrony_timestep.md). It returns a [command.Response](python_api.md#command.Response) per command applied.
---
## The world
This class acts as the major ruler of the simulation and its instance should be retrieved by the client. It does not contain the model of the world itself (that is part of the [Map](core_map.md) class), but rather is an anchor for the simulation. Most of the information and general settings can be accessed from this class, for example:
The major ruler of the simulation. Its instance should be retrieved by the client. It does not contain the model of the world itself, that is part of the [Map](core_map.md) class. Instead, most of the information, and general settings can be accessed from this class.
* Actors and the spectator.
* Actors in the simulation and the spectator.
* Blueprint library.
* Map.
* Settings.
* Simulation settings.
* Snapshots.
In fact, some of the most important methods of this class are the _getters_. They summarize all the information the world has access to. More explicit information regarding the World class can be found in the [Python API reference](python_api.md#carla.World).
Some of its most important methods are _getters_. Take a look at [carla.World](python_api.md#carla.World) to learn more about it.
#### Actors
### Actors
The world has different methods related with actors that allow it to:
The world has different methods related with actors that allow for different functionalities.
* Spawn actors (but not destroy them).
* Get every actor on scene or find one in particular.
* Access the blueprint library used for spawning these.
* Access the spectator actor that manages the simulation's point of view.
* Get every actor on scene, or find one in particular.
* Access the blueprint library.
* Access the spectator actor, the simulation's point of view.
* Retrieve a random location that is fitting to spawn an actor.
Explanations on spawning will be conducted in the second step of this guide: [2nd. Actors and blueprints](core_actors.md), as it requires some understanding on the blueprint library, attributes, etc. Keep reading or visit the [Python API reference](python_api.md) to learn more about this matter.
Spawning will be explained in [2nd. Actors and blueprints](core_actors.md). It requires some understanding on the blueprint library, attributes, etc.
#### Weather
### Weather
The weather is not a class on its own, but a world setting. However, there is a helper class named [carla.WeatherParameters](python_api.md#carla.WeatherParameters) that allows to define a series of visual characteristics such as sun orientation, cloudiness, lightning, wind and much more. The changes can then be applied using the world as the following example does:
The weather is not a class on its own, but a set of parameters accessible from the world. The parametrization includes sun orientation, cloudiness, wind, fog, and much more. The helper class [carla.WeatherParameters](python_api.md#carla.WeatherParameters) is used to define a custom weather.
```py
weather = carla.WeatherParameters(
cloudiness=80.0,
@ -114,7 +116,7 @@ world.set_weather(weather)
print(world.get_weather())
```
For convenience, there are a series of weather presets that can be directly applied to the world. These are listed in the [Python API reference](python_api.md#carla.WeatherParameters) with all the information regarding the class and are quite straightforward to use:
There are some weather presets that can be directly applied to the world. These are listed in [carla.WeatherParameters](python_api.md#carla.WeatherParameters) and accessible as an enum.
```py
world.set_weather(carla.WeatherParameters.WetCloudySunset)
@ -123,59 +125,60 @@ world.set_weather(carla.WeatherParameters.WetCloudySunset)
!!! Note
Changes in the weather do not affect physics. They are only visuals that can be captured by the camera sensors.
#### Debugging
### Debugging
World objects have a public attribute that defines a [carla.DebugHelper](python_api.md#carla.DebugHelper) object. It allows for different shapes to be drawn during the simulation in order to trace the events happening. The following example would access the attribute to draw a red box at an actor's location and rotation.
World objects have a [carla.DebugHelper](python_api.md#carla.DebugHelper) object as a public attribute. It allows for different shapes to be drawn during the simulation. These are used to trace the events happening. The following example would draw a red box at an actor's location and rotation.
```py
debug = world.debug
debug.draw_box(carla.BoundingBox(actor_snapshot.get_transform().location,carla.Vector3D(0.5,0.5,2)),actor_snapshot.get_transform().rotation, 0.05, carla.Color(255,0,0,0),0)
```
This example is extended in this [code recipe](ref_code_recipes.md#debug-bounding-box-recipe) to draw boxes for every actor in a world snapshot. Take a look at it and at the Python API reference to learn more about this.
This example is extended in a [code recipe](ref_code_recipes.md#debug-bounding-box-recipe) to draw boxes for every actor in a world snapshot.
#### World snapshots
### World snapshots
Contains the state of every actor in the simulation at a single frame, a sort of still image of the world with a time reference. This feature makes sure that all the information contained comes from the same simulation step without the need of using synchronous mode.
Contains the state of every actor in the simulation at a single frame. A sort of still image of the world with a time reference. The information comes from the same simulation step, even in asynchronous mode.
```py
# Retrieve a snapshot of the world at current frame.
world_snapshot = world.get_snapshot()
```
The [carla.WorldSnapshot](python_api.md#carla.WorldSnapshot) contains a [carla.Timestamp](python_api.md#carla.Timestamp) and a list of [carla.ActorSnapshot](python_api.md#carla.ActorSnapshot). Actor snapshots can be searched using the `id` of an actor and the other way round, the actor regarding a snapshot is facilitated by the `id` in the actor snapshot.
A [carla.WorldSnapshot](python_api.md#carla.WorldSnapshot) contains a [carla.Timestamp](python_api.md#carla.Timestamp) and a list of [carla.ActorSnapshot](python_api.md#carla.ActorSnapshot). Actor snapshots can be searched using the `id` of an actor. A snapshot lists the `id` of the actors appearing in it.
```py
timestamp = world_snapshot.timestamp #Get the time reference
timestamp = world_snapshot.timestamp # Get the time reference
for actor_snapshot in world_snapshot: #Get the actor and the snapshot information
for actor_snapshot in world_snapshot: # Get the actor and the snapshot information
actual_actor = world.get_actor(actor_snapshot.id)
actor_snapshot.get_transform()
actor_snapshot.get_velocity()
actor_snapshot.get_angular_velocity()
actor_snapshot.get_acceleration()
actor_snapshot = world_snapshot.find(actual_actor.id) #Get an actor's snapshot
actor_snapshot = world_snapshot.find(actual_actor.id) # Get an actor's snapshot
```
#### World settings
### World settings
The world also has access to some advanced configurations for the simulation that determine rendering conditions, steps in the simulation time and synchrony between clients and server. These are advanced concepts that do better if untouched by newcomers.
For the time being let's say that CARLA by default runs in with its best quality, with a variable time-step and asynchronously. The helper class is [carla.WorldSettings](python_api.md#carla.WorldSettings). To dive further in this matters take a look at the __Advanced steps__ section of the documentation and read about [synchrony and time-step](adv_synchrony_timestep.md) or [rendering_options.md](adv_rendering_options.md).
The world has access to some advanced configurations for the simulation. These determine rendering conditions, simulation time-steps, and synchrony between clients and server. They are accessible from the helper class [carla.WorldSettings](python_api.md#carla.WorldSettings).
For the time being, default CARLA runs with the best graphics quality, a variable time-step, and asynchronously. To dive further in this matters take a look at the __Advanced steps__ section. The pages on [synchrony and time-step](adv_synchrony_timestep.md), and [rendering options](adv_rendering_options.md) could be a great starting point.
---
That is a wrap on the world and client objects, the very first steps in CARLA.
The next step should be learning more about actors and blueprints to give life to the simulation. Keep reading to learn more or visit the forum to post any doubts or suggestions that have come to mind during this reading:
That is a wrap on the world and client objects. The next step takes a closer look into actors and blueprints to give life to the simulation.
Keep reading to learn more. Visit the forum to post any doubts or suggestions that have come to mind during this reading.
<div text-align: center>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="forum.carla.org" target="_blank" class="btn btn-neutral" title="CARLA forum">
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="CARLA forum">
CARLA forum</a>
</p>
</div>
<div class="build-buttons">
<!-- Latest release button -->
<p>
<a href="../core_actors" target="_blank" class="btn btn-neutral" title="2nd. Actors and blueprints">
2nd. Actors and blueprints</a>

94
Docs/extra.css
View File

@ -13,6 +13,8 @@
}
/************************* DEFAULT TABLES **************************/
table.defTable {
border: 1px solid #242424;
background-color: #f3f6f6;
@ -36,3 +38,95 @@ table.defTable thead th {
table.defTable tbody td{
padding: 7px 13px;
}
/************************* TOWN SLIDER **************************/
* {box-sizing:border-box}
/* Container */
.townslider-container {
max-width: 1000px;
position: relative;
margin: auto;
}
/* Hide the images by default */
.townslide {
display: none;
text-align: center;
}
/* Fading animation for slides */
.fade {
-webkit-animation-name: fade;
-webkit-animation-duration: 1.5s;
animation-name: fade;
animation-duration: 1.5s;
}
@-webkit-keyframes fade {
from {opacity: .4}
to {opacity: 1}
}
@keyframes fade {
from {opacity: .4}
to {opacity: 1}
}
/* "next" and "previous" buttons */
.prev, .next {
cursor: pointer;
position: absolute;
top: 50%;
width: auto;
margin-top: -22px;
padding: 16px;
color: white;
font-weight: bold;
font-size: 18px;
transition: 0.6s ease;
border-radius: 0 3px 3px 0;
user-select: none;
}
/* Position the "next" button*/
.next {
right: 0;
border-radius: 3px 0 0 3px;
}
/* Black background color to buttons when hovering*/
.prev:hover, .next:hover {
background-color: rgba(0,0,0,0.8);
}
/* Caption text for towns */
.text {
color: #f2f2f2;
font-size: 15px;
padding: 8px 12px;
position: absolute;
bottom: 8px;
width: 100%;
text-align: center;
/*background-color:rgba(0,0,0,0.5);*/
}
/* The dot indicators for slides */
.dot {
cursor: pointer;
height: 15px;
width: 15px;
margin: 0 2px;
background-color: #bbb;
border-radius: 50%;
display: inline-block;
transition: background-color 0.6s ease;
}
.active, .dot:hover {
background-color: #717171;
}

BIN
Docs/img/Town01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 73 KiB

BIN
Docs/img/Town01.png~ Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
Docs/img/Town02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
Docs/img/Town02.png~ Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
Docs/img/Town03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 231 KiB

BIN
Docs/img/Town03.png~ Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 127 KiB

BIN
Docs/img/Town04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 179 KiB

BIN
Docs/img/Town05.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 238 KiB

BIN
Docs/img/Town05.png~ Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 186 KiB

BIN
Docs/img/Town06.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
Docs/img/Town07.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 132 KiB

BIN
Docs/img/Town07.png~ Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 86 KiB

4
Docs/python_api.md
View File

@ -384,9 +384,9 @@ Load a new world with default settings using `map_name` map. All actors present
- `duration` (_float_) – Time in seconds that will be reenacted using the information `name` file. If the end is reached, the simulation will continue.
- `follow_id` (_int_) – ID of the actor to follow. If this is 0 then camera is disabled.
- <a name="carla.Client.generate_opendrive_world"></a>**<font color="#7fb800">generate_opendrive_world</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**opendrive**</font>)
Loads a new world with a basic physical topology generated from an OpenDRIVE file passed as `string`. It is similar to `client.load_world(map_name)` but allows for custom OpenDRIVE maps in server side. Cars can drive around the map, but there are no graphics besides the road and sidewalks.
Loads a new world with a basic 3D topology generated from the content of an OpenDRIVE file. This content is passed as a `string` parameter. It is similar to `client.load_world(map_name)` but allows for custom OpenDRIVE maps in server side. Cars can drive around the map, but there are no graphics besides the road and sidewalks.
- **Parameters:**
- `opendrive` (_str_) – OpenDRIVE data as `string`.
- `opendrive` (_str_) – Content of an OpenDRIVE file as `string`.
- <a name="carla.Client.set_replayer_time_factor"></a>**<font color="#7fb800">set_replayer_time_factor</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**time_factor**=1.0</font>)
When used, the time speed of the reenacted simulation is modified at will. It can be used several times while a playback is in curse.
- **Parameters:**

4
PythonAPI/docs/client.yml
View File

@ -157,9 +157,9 @@
- param_name: opendrive
type: str
doc: >
OpenDRIVE data as `string`.
Content of an OpenDRIVE file as `string`.
doc: >
Loads a new world with a basic physical topology generated from an OpenDRIVE file passed as `string`.
Loads a new world with a basic 3D topology generated from the content of an OpenDRIVE file. This content is passed as a `string` parameter.
It is similar to `client.load_world(map_name)` but allows for custom OpenDRIVE maps in server side.
Cars can drive around the map, but there are no graphics besides the road and sidewalks.
# --------------------------------------