Clarification question about how the SUMO interactive integration works

Interactive Scenarios & SUMO Interface
1

Hi, from the provided examples I’m a bit confused how the CommonRoad SUMO integration works. My intuition would be the following:

  • A CommonRoad scenario is basically a map + static objects + dynamic objects
  • For every dynamic object, there is a trajectory in the scenario definition (i.e. position x, y, … at timestep t)
  • The CommonRoad <-> SUMO bridge sets the x, y positions of the dynamic non-ego vehicles via moveToXY everytime we do an environment step
  • If the ego vehicle is (at least partially) on the same lane as a non-ego vehicle, or is about to change onto another lane, we let the SUMO engine take over and control these cars. From there on, the non-ego trajectory for these vehicles will be different from those defined in the scenario.

Looking at the code however, it seems like the CommonRoad scenario is just converted to a SUMO .rou and .net file and SUMO controls all the cars right from the beginning. Did I miss something or is this how this bridge works?

Thanks ahead :slight_smile:

2

Hi Sebastian,

Looking at the code however, it seems like the CommonRoad scenario is just converted to a SUMO .rou and .net file and SUMO controls all the cars right from the beginning.

it works like you said here. Perhaps you might want to clarify what confused you in the examples so we can improve them?

1 Like
3

Hi,

I love how quick you are in this forum with your responses :smiley: That’s interesting. Is there any reason why you don’t follow the mixed approach? Or does this .rou + .net conversion method result in the exact same scenario rollout as if you would run the scenario via CommonRoad? If not, I’m a little disappointed because interactive SUMO scenarios wouldn’t be the “real deal” actually (i.e. would only map the actual source scenario very loosely). The mixed approach would at least partially enforce some closeness to the recorded scenario.

Also, I’ll have a deeper look and give you some feedback. Maybe I just had a biased look on the SUMO integration module, because I wanted it to have this mixed approach.

4

First of all, I think it doesn’t make a big difference, whether you simulate only the closest vehicles or all vehicles with SUMO, because in both cases your planner only directly interacts with the closest vehicles.

In the mixed approach, it’s not so trivial to determine whether you actually influence other vehicles. E.g. in Sumo, you also influence vehicles driving in other lanes, in intersecting lanes, and even some vehicles far away (e.g. if the ego vehicle is causing a traffic jam). To achieve that, we would need to run another monitor in parallel which might add a significant computational overhead depending on the scenario.

There might be other methods that aim at reproducing recorded data as close as possible, but those methods wouldn’t require a traffic simulator like Sumo.

Also note that some of our scenarios are generated purely in simulation, so we don’t have ground truth data from some dataset.

1 Like
5

Cool! Thanks a lot for the clarification. Thinking about it, your approach makes total sense. But good to know. This reduces a lot of prior work I would have to do to integrate your codebase into our project :slight_smile:.

Thanks for your time and your amazing work!

1 Like