search

a-b-street / abstreet

Transportation planning and traffic simulation software for creating cities friendlier to walking, biking, and public transit
https://a-b-street.github.io/docs/
Apache License 2.0
7.66k stars 340 forks source link

Possibility to leverage SUMO as simulation backend #835

Closed allenwoods closed 2 years ago

allenwoods commented 2 years ago

Hi, I come from the ITS community and found this project amazing for experiments involving human participants. I'm curious why ABStreet reimplement simulation backend while SUMO is already widely used for experiments? Furthermore, is it possible to use SUMO as another simulation backend? It would be very helpful since there are plenty of algorithms built upon SUMO

dabreegster commented 2 years ago

Hi -- great questions!

What's happened so far: About a year ago, I was starting to explore interoperability between A/B Street and SUMO. In #434, I managed to initially convert SUMO's network format to A/B Street's map model. There were some problems, but it could be possible to get this to work. If we had continued down that path, the few different travel demand models that SUMO has could maybe be used as input to A/B Street's simulation too.

Why implement a new simulation in the first place? Partly for performance -- A/B Street deliberately sacrifices details like acceleration to have a faster and simpler discrete event model. Partly technical -- A/B Street has no non-Rust dependencies in most components, letting us compile to WebAssembly and run on the web. There may be a way to compile SUMO's C++ backend to WASM, or run it remotely through TraCI, but it's not obvious. Also partly historic -- I've known about SUMO and MATSim as the big open source simulators since undergrad, but when starting a new project with very different goals, I've found it easier to start something from scratch, rather than try to integrate with a very large existing codebase.

Would it be possible to use SUMO as an alternate simulation backend? Maaaybe. It would involve:

There's finally the question of what benefits there'd be from integrating with SUMO, since it would have such a high cost. It would be nice for the simulation layer to be pluggable, but I didn't intend that from the start, and it'd be lots of work to get to that point. If SUMO more or less solved all the sources of unrealistic gridlock in traffic simulations -- coming from parking capacity and travel deand models being wrong, traffic signal timing needing tuning, and dealing with funky geometry and complex junctions -- then I'd strongly consider integration, because solving all of these problems is really hard. But last time I imported some areas that A/B Street has trouble simulating, I also saw similar gridlock in SUMO.

I have no plans to integrate with SUMO, but I'm open to the possibility, or exploring other ways to share effort better. I'll also mention that I haven't really been focusing on the traffic simulation part of A/B Street for quite a while -- it's not really that important for the project's core goal, which is transportation planning focused on moving away from motor vehicles. In the past year or so, we've focused on lots of more focused tools that don't need simulation at all to do something useful -- bike.abstreet.org, 15m.abstreet.org, and now ltn.abstreet.org

allenwoods commented 2 years ago

Thanks for the quick reply! So generally speaking, A/B street implements its own simulation because:

  1. It needs a faster simulation with fewer details since it focuses on solving problems different from SUMO,
  2. The way to integrate SUMO while exposing a web-based interface is unclear

Did I understand it correctly? If so, could you further explain:

  1. What exactly are the problems A/B Streat trying to solve and how does it make using SUMO simulation unworthy? At the first glance, I recognize A/B Streat as a tool to analyze impacts of small change (lane directions, phase durations) on the city network, but that means using solid (or at least accepted by the community) simulation is important.
  2. Could you give an example that explains why going through TraCI is not an obvious option? Since one can run sumo without sumo-gui, I suppose using TraCI or a similar mechanism to bridge a frontend with libsumo is a quite normal choice, or did you mean some functionalities that are provided by other tools, such as netconvert is not easy to integrate?
allenwoods commented 2 years ago

The simulation in SUMO is not perfect, of course, but It has been widely accepted by the community. By accepted I mean, if you use SUMO as the experimental environment in a submitted paper, you will hardly be challenged by reviewers🤣

Most important, it attracts quite a lot of resources and is continually improving. Would that be nice if we could just reuse it and focus on problems we want to solve?

dabreegster commented 2 years ago

What exactly are the problems A/B Streat trying to solve and how does it make using SUMO simulation unworthy?

That has changed over time. What you said was true originally. https://a-b-street.github.io/docs/software/ungap_the_map/motivation.html better answers what we're aiming to do nowadays -- facilitate better communication is a big one. If a traffic simulation is unrealistic or gridlocks for technical reasons, that's a distraction.

Another way of looking at it: when new cycle or public transit infrastructure is successfully designed / funded / built, is a detailed microsimulation useful?

Could you give an example that explains why going through TraCI is not an obvious option?

Since a core part of A/B Street's purpose is easy usage by the public, continuing to work in web browsers without any installation is critical. So how would that work with SUMO? One option is to run the SUMO backend remotely and stream data through the network, then handle the UI in the browser. What's the piece of Rust code that talks to SUMO?

One option is making a Rust<->C++ FFI, probably with libsumo. Another is using, TraCI, but it's a custom binary protocol. I don't particularly want to spend my time implementing this. If TraCI had support for something like protocol buffers, this support would come for free, as well as letting somebody talk to TraCI in Python, Java, Javascript, anything.

By accepted I mean, if you use SUMO as the experimental environment in a submitted paper, you will hardly be challenged by reviewers

Definitely so. Only very recently have I rejoined some form of academia; for the past 4ish years, I've had no motivation or interest to write a peer reviewed paper. :) If somebody wants to peer review any aspect of the project, they open an issue here and we discuss it publicly. (And that model has been much more personally satisfying than my few experiences with peer review back in undergrad -- take a look through the issue tracker to get a sense of some of the awesome ideas and collaborations that've come out.)

Would that be nice if we could just reuse it and focus on problems we want to solve?

Of course, but that integration doesn't come for free. If there's another software engineer willing to focus on this problem for a few months, I'd happily support and assist them. But there are like 10 other major things I find more important to do first, so I'm not likely to ever get there. And now A/B Street is not my only focus work-wise.

allenwoods commented 2 years ago

I see, so the major problem is that TraCI support only python, and the benefits of implementing a Rust version are not enough. I might be able to help after March 2022, what would you suggest to do first? Maybe implement a fork version of TraCI using PB and grpc?

dabreegster commented 2 years ago

There's also libsumo, which I think is C bindings. It's possible to glue that to Rust, but it's certainly more effort than protobuf/grpc/something else with autogenerated bindings.

If you'd like to help, then sure -- I think a version of TraCI using proto + grpc would be generally useful. It's something the SUMO team was talking about, so I'd definitely check with them and see what the current plans are. The other thing that'd be helpful is figuring out a specific first use case / application where we can combine the strengths of the two projects. What is SUMO missing that you're interested in using from A/B Street?

allenwoods commented 2 years ago

What SUMO missing are a friendly interface that allows users to modify the traffic environment (changing the phase of the traffic light, switching the direction of a lane, etc) interactively and a beautiful diagram to compare the effects of modifications.

What I want to build is an online platform, where people driving through certain intersections could submit better plans for traffic lights, if they found the current setting is not optimal, and see how their setting will affect the situation immediately.

dabreegster commented 2 years ago

That sounds like one of the original visions of A/B Street. :) I'm pretty happy with the traffic signal editor we wound up with; @muzlee1113 and I went through many iterations and user testing for it.

To rain on your parade a little bit, a few complications...

allenwoods commented 2 years ago

Thanks for the detailed explanation! Now I understand the gap between A/B street and SUMO, it did seem easier to build a new UI on top of SUMO...