Sergi e/synch step (#2452)
* Second draft. Rendering options added. * New draft with fixes * Rebase. fixed some links.
This commit is contained in:
sergi.e
GitHub
parent
db81cb6c91
commit
de7f3e3478
|
|
@ -340,7 +340,7 @@ points in a measurement reflect the same "static picture" of the scene.
|
|||
|
||||
!!! tip
|
||||
Running the simulator at
|
||||
[fixed time-step](configuring_the_simulation.md#fixed-time-step) it is
|
||||
[fixed time-step](simulation_time_and_synchrony.md) it is
|
||||
possible to tune the horizontal angle of each measurement. By adjusting the
|
||||
frame rate and the rotation frequency is possible, for instance, to get a
|
||||
360 view each measurement.
|
||||
|
|
|
|||
|
|
@ -261,7 +261,7 @@ CARLA forum</a>
|
|||
<div class="build-buttons">
|
||||
<!-- Latest release button -->
|
||||
<p>
|
||||
<a href="../core_actors" target="_blank" class="btn btn-neutral" title="3rd. Maps and navigation">
|
||||
<a href="../core_map" target="_blank" class="btn btn-neutral" title="3rd. Maps and navigation">
|
||||
3rd. Maps and navigation</a>
|
||||
</p>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ CARLA forum</a>
|
|||
<div class="build-buttons">
|
||||
<!-- Latest release button -->
|
||||
<p>
|
||||
<a href="../core_actors" target="_blank" class="btn btn-neutral" title="4th. Sensors and data">
|
||||
<a href="../cameras_and_sensors" target="_blank" class="btn btn-neutral" title="4th. Sensors and data">
|
||||
4th. Sensors and data</a>
|
||||
</p>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Follow [Art Guide][artlink] for creating the Skeletal Mesh and Physics Asset. An
|
|||
Add the animation graph as shown in the links given above
|
||||
(or look for it in other cars' animation, like Mustang).
|
||||
|
||||
4. Create folder `Content/Blueprints/Vehicles/<vehicle-model>`
|
||||
4. Create folder `Content/Carla/Blueprints/Vehicles/<vehicle-model>`
|
||||
|
||||
5. Inside that folder create two blueprint classes derived from "VehicleWheel" class.
|
||||
Call them `<vehicle-model>_FrontWheel` and `<vehicle-model>_RearWheel`. Set their "Shape Radius"
|
||||
|
|
|
|||
|
|
@ -8,7 +8,8 @@
|
|||
<h3>Quick start</h3>
|
||||
|
||||
* [Python API tutorial](core_concepts.md)
|
||||
* [Configuring the simulation](configuring_the_simulation.md)
|
||||
* [Rendering options](rendering_options.md)
|
||||
* [Simulation time and synchrony](simulation_time_and_synchrony.md)
|
||||
* [Cameras and sensors](cameras_and_sensors.md)
|
||||
* [F.A.Q.](faq.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -51,6 +51,28 @@ Typically we won't need the client object anymore, all the objects created by
|
|||
the world will connect to the IP and port provided if they need to. These
|
||||
operations are usually done in the background and are transparent to the user.
|
||||
|
||||
Changing the map
|
||||
----------------
|
||||
|
||||
The map can be changed from the Python API with
|
||||
|
||||
```py
|
||||
world = client.load_world('Town01')
|
||||
```
|
||||
|
||||
this creates an empty world with default settings. The list of currently
|
||||
available maps can be retrieved with
|
||||
|
||||
```py
|
||||
print(client.get_available_maps())
|
||||
```
|
||||
|
||||
To reload the world using the current active map, use
|
||||
|
||||
```py
|
||||
world = client.reload_world()
|
||||
```
|
||||
|
||||
#### Blueprints
|
||||
|
||||
A blueprint contains the information necessary to create a new actor. For
|
||||
|
|
|
|||
|
|
@ -0,0 +1,188 @@
|
|||
<h1>Rendering options</h1>
|
||||
|
||||
Before you start running your own experiments there are few details to take into
|
||||
account at the time of configuring your simulation. In this document we cover
|
||||
the most important ones.
|
||||
|
||||
* [__Graphics quality__](#graphics-quality):
|
||||
* Vulkan vs OpenGL
|
||||
* Quality levels
|
||||
* [__No-rendering mode__](#no-rendering-mode)
|
||||
* [__Off-screen mode__](#off-screen-mode)
|
||||
* Off-screen Vs no-rendering
|
||||
* [__Running off-screen using a preferred GPU__](#running-off-screen-using-a-preferred-gpu):
|
||||
* Requirements
|
||||
* Configure the X
|
||||
* Emulate the virtual display
|
||||
* Extra
|
||||
* Running CARLA
|
||||
* [__Command line options__](#command-line-options)
|
||||
|
||||
|
||||
!!! Important
|
||||
Some of the command options shown below are not directly equivalent when using the CARLA packaged releases. Read the [Command line options](#command-line-options) section to learn more about this.
|
||||
|
||||
---------------
|
||||
##Graphics quality
|
||||
|
||||
<h4>Vulkan vs OpenGL</h4>
|
||||
|
||||
Vulkan is the default graphics API used by Unreal Engine and CARLA (if installed). It consumes more memory, but performs faster and makes for a better frame rate. However, it is quite experimental, especially in Linux, and it may lead to some issues.
|
||||
For said reasons, there is the option to change to OpenGL simply by using a flag when running CARLA. The same flag works for both Linux and Windows:
|
||||
|
||||
```sh
|
||||
cd carla && ./CarlaUE4.sh -opengl
|
||||
```
|
||||
When working with the build version of CARLA it is Unreal Engine the one that needs to be set to use OpenGL. [Here][UEdoc] is a documentation regarding different command line options for Unreal Engine.
|
||||
[UEdoc]: https://docs.unrealengine.com/en-US/Programming/Basics/CommandLineArguments/index.html
|
||||
|
||||
<h4>Quality levels</h4>
|
||||
|
||||
CARLA also allows for two different graphic quality levels named as __Epic__, the default, and __Low__, which disables all post-processing, shadows and the drawing distance is set to 50m instead of infinite and makes the simulation run significantly faster.
|
||||
Low mode is not only used when precision is nonessential or there are technical limitations, but also to train agents under conditions with simpler data or regarding only close elements.
|
||||
|
||||
The images below show how do both modes look like and how to start the CARLA packaged release with the appropiate flag in order to set a quality level. The same flag works for both Linux and Windows. There is no equivalent option when working with the build, but the UE editor has its own quality settings in _Settings>Engine Scalability Settings_ that allow for a greater customization of the desired quality.
|
||||
|
||||
 | 
|
||||
:-------------------------:|:-------------------------:
|
||||
`./CarlaUE4.sh -quality-level=Epic` | `./CarlaUE4.sh -quality-level=Low`
|
||||
|
||||
!!! Important
|
||||
The issue that made Epic mode show an abnormal whiteness has been fixed. If the problem persists delete `GameUserSettings.ini` as it is saving the previous settings. It will be generated again in the next run. __Ubuntu path:__ ` ~/.config/Epic/CarlaUE4/Saved/Config/LinuxNoEditor/` __Windows path:__ `<Package folder>\WindowsNoEditor\CarlaUE4\Saved\Config\WindowsNoEditor\`
|
||||
|
||||
---------------
|
||||
##No-rendering mode
|
||||
|
||||
This mode completely disables rendering in the simulator, Unreal Engine will skip everything regarding graphics. This facilitates a lot simulating traffic and road behaviours at very high frequencies without the rendering overhead. To enable or disable no-rendering mode the user can either change the world settings in a script or use the provided script in `/PythonAPI/util/config.py` that does that same thing automatically.
|
||||
Here is an example on how to enable and then disable it via script.
|
||||
```py
|
||||
settings = world.get_settings()
|
||||
settings.no_rendering_mode = True
|
||||
world.apply_settings(settings)
|
||||
...
|
||||
settings.no_rendering_mode = False
|
||||
world.apply_settings(settings)
|
||||
```
|
||||
And here is an example on how to disable and then enable rendering using the `config.py`:
|
||||
```sh
|
||||
cd PythonAPI/util && ./config.py --no-rendering
|
||||
```
|
||||
```sh
|
||||
cd PythonAPI/util && ./config.py --rendering
|
||||
```
|
||||
|
||||
On of the example scripts in `PythonAPI/examples/no_rendering_mode.py` will enable no-rendering mode and use __Pygame__ to create an aerial view using simple graphics:
|
||||
```sh
|
||||
cd PythonAPI/examples && ./no_rendering_mode.py
|
||||
```
|
||||
|
||||
!!! Warning
|
||||
In no-rendering mode, cameras and GPU sensors will return empty data. The GPU is not used, as Unreal Engine is not drawing any scene.
|
||||
|
||||
---------------
|
||||
##Off-screen mode
|
||||
|
||||
Unreal Engine needs for a screen in order to run, but there is a workaround for this that makes possible to work on rendering for remote servers with no display or desktop users with a GPU not connected to any screen.
|
||||
The simulator launches but there is no available window. However, it can be connected in the usual manner and scripts run the same way. For the sake of understanding let's sake that this mode tricks Unreal Engine into running in a fake screen.
|
||||
|
||||
|
||||
<h4>Off-screen vs no-rendering</h4>
|
||||
|
||||
These may look similar but are indeed quite different. It is important to understand the disctintion them to prevent misunderstandings. In off-screen Unreal Engine is working as usual and rendering is computed as usual. The only difference is that there is no available display. In no-rendering, it is Unreal Engine the one that is said to avoid rendering and thus, graphics are not computed. For said reasons, GPU sensors return data when off-screen and no-rendering mode can be enabled at will.
|
||||
|
||||
<h4>Setting off-screen mode</h4>
|
||||
|
||||
Right now this is __only possible in Linux while using OpenGL__ instead of Vulkan. Unreal Engine crushes when Vulkan is running off-screen, and this issue is yet to be fixed by Epic.
|
||||
|
||||
To force the simulator run off-screen set the environment variable `DISPLAY` to empty and run CARLA using OpenGL:
|
||||
|
||||
```sh
|
||||
# Linux
|
||||
DISPLAY= ./CarlaUE4.sh -opengl
|
||||
```
|
||||
Note that this method, in multi-GPU environments, does not allow to choose the GPU that the simulator will use for rendering. To do so, read the following section.
|
||||
|
||||
---------------
|
||||
##Running off-scren using a preferred GPU
|
||||
|
||||
!!! note
|
||||
There is an alternative solution with mixed results using SDL2 for CUDA enabled devices in the issue [#225](https://github.com/carla-simulator/carla/issues/225).
|
||||
|
||||
This tutorial only works in Linux and makes it possible for a remote server using several graphical cards to use CARLA on all GPUs. This is also translatable to a desktop user trying to use CARLA with a GPU that is not plugged to any screen. To achieve that, the steps can be summarized as:
|
||||
|
||||
__1.__ Configure the server to have Nvidia working with no display.
|
||||
__2.__ Use VNC and VGL to simulate a display connected to any GPU.
|
||||
__3.__ Run CARLA.
|
||||
|
||||
This tutorial was tested in Ubuntu 16.04 using NVIDIA 384.11 drivers.
|
||||
|
||||
<h4> Requirements </h4>
|
||||
|
||||
* __[Latest Nvidia drivers](http://www.nvidia.es/Download/index.aspx)__
|
||||
* __[OpenGL](https://www.khronos.org/opengl/wiki/Getting_Started)__: needed to use Virtual GL (VGL). OpenGL can be installed via apt:
|
||||
```sh
|
||||
sudo apt-get install freeglut3-dev mesa-utils
|
||||
```
|
||||
* __[VGL](https://virtualgl.org/vgldoc/2_2_1/#hd004001)__: redirects 3D rendering commands from Unix and Linux OpenGL to the hardware in a dedicated server.
|
||||
|
||||
* __[TurboVNC 2.11](https://cdn.rawgit.com/TurboVNC/turbovnc/2.1.1/doc/index.html#hd005001)__: graphical desktop-sharing system to connect remotely to the server.
|
||||
|
||||
* __Extra packages__: necessary to make Unreal work.
|
||||
```sh
|
||||
sudo apt install x11-xserver-utils libxrandr-dev
|
||||
```
|
||||
!!! Warning
|
||||
Make sure that VNC version is compatible with Unreal. The one above worked properly during the making of this tutorial.
|
||||
|
||||
|
||||
<h4>Configure the X</h4>
|
||||
|
||||
Generate a X compatible with the Nvdia installed and able to run without display:
|
||||
|
||||
sudo nvidia-xconfig -a --use-display-device=None --virtual=1280x1024
|
||||
|
||||
<h4> Emulate the virtual display </h4>
|
||||
|
||||
Run a Xorg. Here number 7 is used, but it could be labeled with any free number:
|
||||
|
||||
sudo nohup Xorg :7 &
|
||||
|
||||
Run an auxiliary remote VNC-Xserver. This will create a virtual display "8":
|
||||
|
||||
/opt/TurboVNC/bin/vncserver :8
|
||||
|
||||
If everything is working fine the following command will run glxinfo on Xserver 7 selecting the GPU labeled as 0:
|
||||
|
||||
DISPLAY=:8 vglrun -d :7.0 glxinfo
|
||||
|
||||
!!! Important
|
||||
To run on other GPU, change the `7.X` pattern in the previous command. To set it to GPU 1: `DISPLAY=:8 vglrun -d :7.1 glxinfo`
|
||||
|
||||
<h4> Extra </h4>
|
||||
|
||||
To disable the need of sudo when creating the `nohup Xorg` go to `/etc/X11/Xwrapper.config` and change `allowed_users=console` to `allowed_users=anybody`.
|
||||
|
||||
It may be needed to stop all Xorg servers before running `nohup Xorg`. The command for that could change depending on your system. Generally for Ubuntu 16.04 use:
|
||||
|
||||
sudo service lightdm stop
|
||||
|
||||
<h4> Running CARLA </h4>
|
||||
|
||||
To run CARLA on a certain `<gpu_number>` in a certain `$CARLA_PATH` use the following command:
|
||||
|
||||
DISPLAY=:8 vglrun -d :7.<gpu_number> $CARLA_PATH/CarlaUE4/Binaries/Linux/CarlaUE4
|
||||
|
||||
!!! Note
|
||||
The `8` and `7.X` variables in the previous command depend on which were used while emulating the virtual display.
|
||||
|
||||
----------------
|
||||
|
||||
That is all there is to know about the different rendering options in CARLA.
|
||||
Open CARLA and mess around for a while to make sure that everything is clear and yet, if there are any doubts, feel free to post these in the forum.
|
||||
|
||||
<div class="build-buttons">
|
||||
<p>
|
||||
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="Go to the CARLA forum">
|
||||
CARLA forum</a>
|
||||
</p>
|
||||
</div>
|
||||
|
|
@ -0,0 +1,154 @@
|
|||
<h1>Simulation time and synchrony</h1>
|
||||
|
||||
This section deals with two concepts that are fundamental to fully comprehend CARLA and gain control over it to achieve the desired results. There are different configurations that define how does time go by in the simulation and how does the server running said simulation work. The following sections will dive deep into these concepts:
|
||||
|
||||
* [__Simulation time-step__](#simulation-time-step)
|
||||
* Variable time-step
|
||||
* Fixed time-step
|
||||
* Tips when recording the simulation
|
||||
* Time-step limitations
|
||||
* [__Client-server synchrony__](#client-server-synchrony)
|
||||
* Setting synchronous mode
|
||||
* Using synchronous mode
|
||||
* [__Synchrony and time-step__](#synchrony-and-time-step)
|
||||
|
||||
---------------
|
||||
##Simulation time-step
|
||||
|
||||
The very first and essential concept to understand in this section is the difference between real time and simulation time. The simulated world has its own clock and time, conducted by the server. Between two steps of the simulation, there is the time spent to compute said steps (real time) and a time span that went by in those two moments of the simulation (simulated time). This latest is the time-step.
|
||||
Just an example for the sake of comprehension: When simulating, the server can take a few miliseconds to compute two steps of a simulation, but the time-step, the time that went by in the simulated world, can be configured to be, for instance, always a second.
|
||||
The time-step can be fixed or variable depending on user preferences, and CARLA can run in both modes.
|
||||
|
||||
!!! Note
|
||||
After reading this section it would be a great idea to go for the following one, __Client-server synchrony__, especially the part about synchrony and time-step. Both are related concepts and affect each other when using CARLA.
|
||||
|
||||
<h4>Variable time-step</h4>
|
||||
|
||||
This is the default mode in CARLA. When the time-step is variable, the simulation time that goes by between steps will be the time that the server takes to compute these.
|
||||
In order to set the simulation to a variable time-step the code could look like this:
|
||||
```py
|
||||
settings = world.get_settings()
|
||||
settings.fixed_delta_seconds = None
|
||||
world.apply_settings(settings)
|
||||
```
|
||||
The provided script `PythonAPI/util/config.py` automatically sets time-step with a flag where variable time-step is zero.
|
||||
```sh
|
||||
cd PythonAPI/util && ./config.py --delta-seconds 0
|
||||
```
|
||||
|
||||
<h4>Fixed time-step</h4>
|
||||
|
||||
Going for a fixed time-step makes the server run a simulation where the elapsed time remains constant between steps. If it is set to 0.5 seconds, there will be two frames per simulated second.
|
||||
Using the same time increment on each step is the best way to gather data from the simulation, as physics and sensor data will correspond to an easy to comprehend moment of the simulation. Also, if the server is fast enough, it makes possible to simulate longer time periods in less real time.
|
||||
To enable this mode set a fixed delta seconds in the world settings. For instance, to run the simulation at a fixed time-step of 0.05 seconds apply the following settings:
|
||||
|
||||
```py
|
||||
settings = world.get_settings()
|
||||
settings.fixed_delta_seconds = 0.05
|
||||
world.apply_settings(settings)
|
||||
```
|
||||
Thus, the simulator will take twenty steps (1/0.05) to recreate one second of the simulated world. This can also be set using the provided script `PythonAPI/util/config.py` that automatically does this with a flag.
|
||||
```sh
|
||||
cd PythonAPI/util && ./config.py --delta-seconds 0.05
|
||||
```
|
||||
|
||||
<h4>Tips when recording the simulation</h4>
|
||||
|
||||
CARLA has a [recorder feature](recorder_and_playback.md) that allows a simulation to be recorded and then reenacted. However, when looking for precision, some things need to be taken into account.
|
||||
If the simulation ran with a fixed time-step, reenacting it will be easy, as the server can be set to the same time-step used in the original simulation. However, if the simulation used a variable time-step, things are a bit more complicated.
|
||||
Firstly, if the server reenacting the simulation also runs with a variable time-step, the time-steps will be different from the original one, as logic cycles differ from time to time. The information will then be interpolated using the recorded data.
|
||||
Secondly, the server can be forced to reproduce the exact same time-steps passing them one by one. Must be mentioned though that as those time steps were the result of the original simulation running as fast as possible, as the time taken to represent this time-steps now will mostly be different, the simulation is bound to be reproduced with weird time fluctuations. The steps simulated are the same, but the real-time between them changes.
|
||||
Finally there is also the float-point arithmetic error that working with a variable time-step introduces. As the simulation is running with a time-step equal to the real one, being real time a continuous and simulation one a float variable, the time-steps show decimal limitations. The time that is cropped for each step is an error that accumulates and prevents the simulation from a precise repetition of what has happened.
|
||||
|
||||
|
||||
<h4>Time-step limitations</h4>
|
||||
|
||||
Physics must be computed within very low time steps to be precise. The more time goes by, the more variables and chaos come to place and so, the more defective the simulation will be.
|
||||
CARLA uses up to 6 substeps to compute physics in every step, each with a maximum delta time of 0.016667s.
|
||||
To know how many of these are needed, the time-step used gets divided by the maximum delta time a substep can use `number_of_substeps = time_step/0.016667`.
|
||||
Being these a maximum of 6, `6*0.016667 = 0.1`. If the time-step is greater there will not be enough physical substeps and thus, the physics will not be in synchrony with the delta time.
|
||||
|
||||
!!! Warning
|
||||
__Do not use a time-step greater than 0.1s.__<br>
|
||||
As explained above, the physics will not be representative for the simulation. The original issue can be found here: Ref. [#695](https://github.com/carla-simulator/carla/issues/695)
|
||||
|
||||
----------------
|
||||
##Client-server synchrony
|
||||
|
||||
CARLA is built over a client-server architecture. This has been previously stated: the server runs the simulation and the client retrieves information and demands for changes in the world. But how do these two elements communicate?
|
||||
By default, CARLA runs in __asynchronous mode__, meaning that the server runs the simulation as fast as possible, without waiting for the client. On the contrary, running on __synchronous mode__ will make the server wait for a client tick, a "ready to go" message, before updating to the following simulation step.
|
||||
|
||||
!!! Note
|
||||
In a multiclient architecture, only one client should make the tick. The server would react to receiving many as if these were all coming from one client and thus, take one step per tick.
|
||||
|
||||
<h4>Setting synchronous mode</h4>
|
||||
|
||||
Changing between synchronous and asynchronous mode is just a matter of a boolean state. In the following example, there is the code to make the simulation run on synchronous mode:
|
||||
```py
|
||||
settings = world.get_settings()
|
||||
settings.synchronous_mode = True
|
||||
world.apply_settings(settings)
|
||||
```
|
||||
|
||||
To disable synchronous mode just set the variable to false or use the provided script in `PythonAPI/util/config.py`.
|
||||
```sh
|
||||
cd PythonAPI/util && ./config.py --no-sync
|
||||
```
|
||||
Must be mentioned that synchronous mode cannot be enabled using the script, only disabled. Enabling the synchronous mode makes the server wait for a client tick, and using this script the user cannot send ticks when desired.
|
||||
|
||||
<h4>Using synchronous mode</h4>
|
||||
|
||||
The synchronous mode becomes specially relevant when running with slow clients applications and when synchrony between different elements, such as sensors, is needed. If the client is too slow and the server does not wait for it, the amount of information received will be impossible to manage and it can easily be mixed. On a similar tune, if there are ten sensors waiting to retrieve data and the server is sending all these information without waiting for all of them to have the previous one, it would be impossible to know if all the sensors are using data from the same moment in the simulation.
|
||||
As a little extension to the previous code, in the following fragment, the client creates a camera sensor that puts the image data received in the current step in a queue and sends ticks to the server only after retrieving it from the queue. A more complex example regarding several sensors can be found [here][syncmodelink].
|
||||
```py
|
||||
settings = world.get_settings()
|
||||
settings.synchronous_mode = True
|
||||
world.apply_settings(settings)
|
||||
|
||||
camera = world.spawn_actor(blueprint, transform)
|
||||
image_queue = queue.Queue()
|
||||
camera.listen(image_queue.put)
|
||||
|
||||
while True:
|
||||
world.tick()
|
||||
image = image_queue.get()
|
||||
```
|
||||
[syncmodelink]: https://github.com/carla-simulator/carla/blob/master/PythonAPI/examples/synchronous_mode.py
|
||||
|
||||
!!! Important
|
||||
Data coming from GPU-based sensors (cameras) is usually generated with a delay of a couple of frames when compared with CPU based sensors, so synchrony is essential here.
|
||||
|
||||
|
||||
----------------
|
||||
##Synchrony and time-step
|
||||
|
||||
The configuration of both concepts explained in this page, simulation time-step and client-server synchrony, leads for different types of simulation and results. Here is a brief summary on the possibilities and a better explanation of the reasoning behind it:
|
||||
|
||||
| | __Fixed time-step__ | __Variable time-step__ |
|
||||
| --- | --- | --- |
|
||||
| __Synchronous mode__ | Client is in total control over the simulation and its information. | Risk of non reliable simulations. |
|
||||
| __Asynchronous mode__ | Good time references for information. Server runs as fast as possible. | Non easily repeatable simulations. |
|
||||
|
||||
* __Synchronous mode + variable time-step:__ This is almost for sure a non-desirable state. Physics cannot run properly when the time-step is bigger than 0.1s and, if the server needs to wait for the client to compute the steps, this is likely to happen. Simulation time and physics then will not be in synchrony and thus, the simulation is not reliable.
|
||||
|
||||
* __Aynchronous mode + variable time-step:__ This is the default CARLA state. Client and server are asynchronous but the simulation time flows according to the real time. Reenacting the simulation needs to take into account float-arithmetic error and possible differences in time steps between servers.
|
||||
|
||||
* __Asynchronous mode + fixed time-step:__ The server will run as fast as possible, and yet, the information retrieved will be easily related with an exact moment in the simulation. This configuration makes possible to simulate long periods of time in much less real time if the server is fast enough.
|
||||
|
||||
* __Synchronous mode + fixed time-step:__ In this mode, the client will have complete ruling over the simulation. The time step will be fixed and the server will not compute the following step until the client sends a tick saying so. This is the best mode when synchrony and precision is relevant, especially when dealing with slow clients or different elements retrieving information.
|
||||
|
||||
!!! Warning
|
||||
__In synchronous mode, always use a fixed time-step__. If the server has to wait for the user to compute the following step, and it is using a variable time-step, the simulation world will use time-steps too big for the physics to be reliable. This issue is better explained in the __time-step limitations__ section.
|
||||
|
||||
|
||||
----------------
|
||||
|
||||
That is all there is to know about the roles of simulation time and client-server synchrony in CARLA.
|
||||
Open CARLA and mess around for a while to make sure that everything is clear and yet, if there are any doubts, feel free to post these in the forum.
|
||||
|
||||
<div class="build-buttons">
|
||||
<p>
|
||||
<a href="https://forum.carla.org/" target="_blank" class="btn btn-neutral" title="Go to the CARLA forum">
|
||||
CARLA forum</a>
|
||||
</p>
|
||||
</div>
|
||||
|
|
@ -25,7 +25,8 @@ nav:
|
|||
- '4th. Sensors and data': 'cameras_and_sensors.md'
|
||||
- Advanced steps:
|
||||
- 'Recorder': 'recorder_and_playback.md'
|
||||
- 'Configuring the simulation': 'configuring_the_simulation.md'
|
||||
- 'Rendering options': 'rendering_options.md'
|
||||
- 'Simulation time and synchrony': 'simulation_time_and_synchrony.md'
|
||||
- References:
|
||||
- 'Python API reference': 'python_api.md'
|
||||
- 'Code recipes': 'python_cookbook.md'
|
||||
|
|
|
|||
Loading…
Reference in New Issue