Elements in this tab allow the user to load and transform Commonroad scenarios which follow the 2018 or 2020 specifications. The scenario will then be drawn in the MapView of the LCC and obstacles will either be simulated or used to control real vehicles with VehicleCommandTrajectory messages. (TODO:) Planning problems, obstacles etc. defined in the scenario will be used for the simulation and will be communicated to the participants when the simulation is started in Setup.
The tab also shows some basic information about the set planning problems, allows to transform the problem (and to store that transformation) and gives options on what elements of the problem to show.
A scenario can be chosen similarly to the script selection in Setup. Either use the Open button or edit the path text field and hit Enter.
Some unsupported features and minor problems during parsing lead to warnings visible in the LCC Errors Tab. More severe warnings will lead to an error message (see below). Traffic lights are currently not being simulated, but their position is shown, if possible. We also do not (yet) have a consistent handling of inexact positional values (we currently use the average) and rotations for shapes. The assumed default value for positions is (0,0) (origin). |
Your chosen scenario gets centered when it is loaded, w.r.t the middle of the Lab's IPS boundaries. It is not automatically resized, though, so you might not see the whole scenario when you load it.
Upon loading a scenario. you might receive an error message. Parts of the implemented loader check your scenario for consistency with the Commonroad specification. If it is malformed, values are missing or wrong types are used, you will find that the scenario will not load. Instead, a window will appear, which refers you to the line (in your scenario file) that raised the error.
IMPORTANT: There are also less relevant errors, e.g. related to drawing, which might be caused by currently missing implementation or decisions made on which Commonroad types to support. These error messages are shown in the LCC Errors Tab and will not prevent your scenario from loading. Keep in mind that these parts of the scenario might then not be supported in the simulation and also might not show up on the screen.
You can also transform your scenario:
Just enter the desired values in the according text boxes and either hit Enter if you just want to change one value, or set values for multiple fields first before applying them by clicking on Apply transformation. The values in the fields are set to 0.0 again after the transformation was applied.
When you change the time steps, you change the time between each time step set in commonroad. Larger timesteps mean a slower simulation and vice-versa. Speed and acceleration values are adjusted accordingly. (Example: Changing from 0.1seconds to 0.2seconds means half the speed)
IMPORTANT: The scenario gets centered when it is first loaded, as the set coordinates might be out of scope. This means, if your scenario only uses coordinates e.g. larger than 200 for x and y values, it should still show up in the MapView. The current centering is not perfect, so you may want to translate it further.
You might be interested in keeping the transformation that you set for your scenario. We use a YAML profile to accomplish this. You do not need to access it directly:
Rotation is not being stored. It is the only operation where the order truly matters, and it is also non-linear. It was thus left out for now. |
If you want to see what the scenario looks like during the simulation, you can preview the movement of the obstacles from within the Commonroad Tab:
We did not want the view to become too cluttered. Thus, parts of the simulation like traffic signs or vehicle information are only drawn on demand. They can be toggled in this part. The explanation of the toggled descriptions can be found on the bottom of this page. Please note that the view below might be outdated (more toggles might exist), but it still works the same way.
The loaded Commonroad scenario may define obstacles. The obstacle ID set in Commonroad is interpreted as the ID of the vehicle in the scenario. This is especially important if you choose to use the movement defined for the obstacle to be used as trajectory for a real vehicle. In this case, the real vehicle with the same ID will respond to the message.
In the image above, the path of obstacle 1 is communicated in form of trajectory messages for vehicle 1 - which can also be received and followed by a real vehicle - while the other obstacles are simulated without controlling real vehicles.
We only allow for obstacle IDs up to 256 due to the message types in use (uint8_t for ID) (TODO?), thus the ID is taken mod 256 if it is higher than that - we do not expect that you need to use more than 256 obstacles within one scenario (this might also have bad consequences for the performance of a simulation). |
Commonroad defines DynamicObstacle, StaticObstacle and EnvironmentObstacle as different obstacle classes. We only allow for trajectory simulation for the first two, as environment obstacles should not be on the lanelet (and don't move as well). Static obstacles may include static vehicles, so we decided to allow trajectory simulation for them, although they also never move (as their name already implies). |
Additional information about the goal states are shown at the bottom of the Commonroad-Tab. Please note that goals are only drawn in the MapView if a position for the goal was set.
Additional information about the lanelets are shown below the goal information. The lanelet IDs can be toggled to know which lanelet the information belongs to.
Most information that are not visible in this table are visible implicitly or explicitly on the MapView (and / or can be toggled as additional information).
To actually see / use the obstacle simulation, you need to:
This should be your usual workflow for starting your own script via the LCC as well.
As soon as you press Deploy, the obstacles disappear. This is done on purpose! The obstacle simulation, as all other simulation, is performed as soon as the lab simulation is started in the Timer Tab. As soon as the timer is started, the obstacles will reappear. |
Descriptions for obstacles, lanelets etc. use few latters to save space. Their meaning is explained here.
| Symbol | Meaning |
|---|---|
| E | Pose is exact |
| I | Pose is not exact |
| M | Obstacle is moving |
| S | Obstacle is static |
| Unk | Unknown obstacle |
| Car | Obstacle is a car |
| Truck | Obstacle is a truck |
| Bus | Obstacle is a bus |
| MCycle | Obstacle is a motorcycle |
| BCycle | Obstacle is a bicycle |
| Ped | Obstacle is a pedestrian |
| Prio | Obstacle is a priority vehicle |
| Train | Obstacle is a train |
| Taxi | Obstacle is a taxi |
| Constr | Obstacle is a construction zone |
| Parked | Obstacle is a parked vehicle |
| Boundary | Obstacle is a road boundary |
| Building | Obstacle is a building (not on the road) |
| Pillar | Obstacle is a pillar (should not be on the road) |
| Median | Obstacle is a median strip in between lanes |
The text drawn for traffic signs is taken from its definition in the Commonroad file:
Traffic Sign ID (list of additional values) Traffic Sign ID (list of additional values) Traffic Sign ID (list of additional values) ...
ID (ID of the planning problem) - time when the goal should be reached (mean), v speed within the goal (mean)
| Color | Meaning |
|---|---|
| Filled Orange | Dynamic obstacle with exact position |
| Filled Violet | Dynamic obstacle with inexact position |
| Orange Border, not filled | Non-Dynamic obstacle (static or environment) with exact position |
| Violet Border, not filled | Non-Dynamic obstacle (static or environment) with inexact position |
| Arrowhead | Meaning |
|---|---|
| Arrow / Triangle | Gives the lanelet orientation. No user is allowed to use the lanelet in the other direction. |
| Circle / Point | At least one user is allowed to use the lanelet in both directions. The Lanelet information table, given the ID of the Lanelet (if shown, which can be toggled), shows which user is allowed to use the lanelet in both directions (e.g. a bicycle). |
Lanelet Border Colors
| Color | Meaning |
|---|---|
| Blue | Lanelets are adjacent and have the same driving direction → Crossing this line should be allowed |
| Black | All other lanelets |
| Light grey | Lanelets for which no_marking was defined. Is overwritten by blue in case of adjacency to another lanelet. |
The Lanelet Border Style can be defined in the Commonroad file (e.g. dashed or broad). Unknown and no_marking are not easy to draw. Thus, unknown is drawn like any solid line, and no_marking is drawn in a transparent grey color. Both colors can be overwritten by blue in case of adjacency (this information is more important). |