Little fixes
This commit is contained in:
parent
e3452edc6c
commit
6463722c17
Binary file not shown.
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
Before Width: | Height: | Size: 4.2 KiB After Width: | Height: | Size: 7.8 KiB |
|
@ -37,9 +37,11 @@ client.replay_file("recording01.log", start, duration, camera)
|
|||
Ex: a value of 10 will start the simulation at second 10.
|
||||
* If the value is negative, it means the number of seconds from the end.
|
||||
Ex: a value of -10 will replay only the last 10 seconds of the simulation.
|
||||
* **duration**: we can say how many seconds we want to play. If the simulation has not reached the end, then all actors will have autopilot enabled automatically. The intention here is to allow for replaying a piece of a simulation and then let all actors start driving in autopilot again.
|
||||
* **duration**: we can say how many seconds we want to play. When the simulation reach the end, then all actors remaining will have autopilot enabled automatically. The intention here is to allow for replaying a piece of a simulation and then let all actors start driving in autopilot again.
|
||||
* **camera**: we can specify the Id of an actor and then the camera will follow that actor while replaying. Continue reading to know which Id has an actor.
|
||||
|
||||
It is good to note that all vehicles at the end of the playback will be set in autopilot to let them continue driving by themselves, and all pedestrians will be stopped at their current place (we plan to set autopilot for pedestrians also, to walk at random places). This behaviour let's you for example replay a piece of simulation and test how they continue after some changes in the environment.
|
||||
|
||||
#### Playback time factor (speed)
|
||||
|
||||
We can specify the time factor (speed) for the replayer at any moment, using the next API:
|
||||
|
@ -50,7 +52,11 @@ client.set_replayer_time_factor(2.0)
|
|||
A value greater than 1.0 will play in fast motion, and a value below 1.0 will play in slow motion, being 1.0 the default value for normal playback.
|
||||
As a performance trick, with values over 2.0 the interpolation of positions is disabled.
|
||||
|
||||
Also the animations can remain at normal speed, because they don't replicate the state of the animation at that exact frame. So animations are not accurate right now.
|
||||
With a time factor of 20x we can see the flow of traffic for example:
|
||||
|
||||
![flow](img/RecorderFlow2.gif)
|
||||
|
||||
The animations about pedestrians will not be affected by this time factor and will remain at normal speed. So animations are not accurate right now.
|
||||
|
||||
The call of this API will not stop the replayer in course, it will change just the speed, so you can change that several times while the replayer is running.
|
||||
|
||||
|
@ -193,8 +199,8 @@ client.show_recorder_actors_blocked("recording01.log", min_time, min_distance)
|
|||
```
|
||||
|
||||
The parameters are:
|
||||
* **min_time**: the minimum time that an actor needs to be stopped to be considered as blocked (in seconds).
|
||||
* **min_distance**: the minimum distance to consider an actor to be stopped (in cm).
|
||||
* **min_time**: the minimum time that an actor needs to be stopped to be considered as blocked (in seconds, by default 30).
|
||||
* **min_distance**: the minimum distance to consider an actor to be stopped (in cm, by default 10).
|
||||
|
||||
So, if we want to know which actor is stopped (moving less than 1 meter during 60 seconds), we could use something like:
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ The recorder system saves all the info needed to replay the simulation in a bina
|
|||
|
||||
![file format 1](img/RecorderFileFormat1.png)
|
||||
|
||||
In summary, the file format has a small header with general info (version, magic string, date and the map used) and a collection of packets of different types (currently we use 8 types, but that will be growing in the future).
|
||||
In summary, the file format has a small header with general info (version, magic string, date and the map used) and a collection of packets of different types (currently we use 10 types, but that will be growing up in the future).
|
||||
|
||||
![global file format](img/RecorderFileFormat3.png)
|
||||
|
||||
|
@ -35,9 +35,10 @@ Each packet starts with a little header of two fields (5 bytes):
|
|||
|
||||
* **id**: is the type of the packet
|
||||
* **size**: is the size of the data that has the packet
|
||||
* **data**: data bytes of the packet (optional)
|
||||
|
||||
If the **size** is greater than 0 means that the packet has **data** bytes. The **data** is optional, and it needs to be reinterpreted in function of the type of the packet.
|
||||
Following the header comes the **data**, as many bytes as **size** field sais.
|
||||
The **data** is optional, si if the **size** is 0 means there is no **data** in this packet.
|
||||
If the **size** is greater than 0 means that the packet has **data** bytes. The **data** needs to be reinterpreted in function of the type of the packet.
|
||||
|
||||
The header of the packet is useful because we can just ignore those packets we are not interested in when doing playback. We only need to read the header (first 5 bytes) of the packet and jump to the next packet just skipping the data of the packet:
|
||||
|
||||
|
@ -47,12 +48,12 @@ The types of packets are:
|
|||
|
||||
![packets type list](img/RecorderPacketsList.png)
|
||||
|
||||
I suggest to use **id** over 100 for user custom packets, because this list will grow in the future in sequence.
|
||||
I suggest to use **id** over 100 for user custom packets, because this list will grow up in sequence in the future.
|
||||
|
||||
|
||||
#### 3.1 Packet 0: Frame Start
|
||||
|
||||
This packet marks the start of a new frame, so it will need to be the first one to start each frame. All packets need to be placed between a **Frame Start** and a **Frame End**.
|
||||
This packet marks the start of a new frame, and it will be the first one to start each frame. All packets need to be placed between a **Frame Start** and a **Frame End**.
|
||||
|
||||
![frame start](img/RecorderFrameStart.png)
|
||||
|
||||
|
@ -152,11 +153,11 @@ A frame consist on several packets, all of them optional, unless the packets tha
|
|||
|
||||
![layout](img/RecorderFrameLayout.png)
|
||||
|
||||
**Event** packets exist only in the frame where happens.
|
||||
**Event** packets exist only in the frame where they happens.
|
||||
|
||||
**Position** and **traffic light** packets should exist in all frames, because they are required to move all actors and set the traffic lights to its state. They are optional but if they are not present then the replayer will not be able to move or set the state of traffic lights.
|
||||
|
||||
The **animation** packets are also optional, but by default they are recorded. That way the walkers are animated and also the wheels follow the direction of the vehicles.
|
||||
The **animation** packets are also optional, but by default they are recorded. That way the walkers are animated and also the vehicle wheels follow the direction of the vehicles.
|
||||
|
||||
### 5. File Layout
|
||||
|
||||
|
|
Loading…
Reference in New Issue