Menu
▾
▴
Re: [sumo-user] [sumo-devel] Acceleration Model
|
From: Daniel K. <d.k...@we...> - 2009-06-22 07:56:38
|
Dear Tobias, > -----Ursprüngliche Nachricht----- > Von: "Tobias Mayer" <may...@we...> > Gesendet: 20.06.09 16:33:50 > An: sum...@li... > Betreff: [sumo-devel] Acceleration Model > Hello everyone, > > a couple of days ago, Nicholas Loulloudes asked about the possibility > of adding a new acceleration model to SUMO, namely the IDM. > Well, I am currently already working on exactly that, as a part of > my students thesis at the University Erlangen-Nuernberg. > I didn't announce this earlier on this list, since I'm still in the > phase of > evaluating the current implementation and altering it to get a proof > of concept "hack" to show that it's possible. > It is very nice you want to collaborate. See my comments below: > Since the whole topic of multiple driver behavior models is currently > gaining some attention, I'd like to discuss some points before lining > out a plan of things to do. And the experience and opinions of some > long time contributors will most likely safe us from a lot of duplicate > efforts and misconceptions: > > 1. At which point will the user decide which model to use? > > 2. What is the necessary groundwork, which needs to be done to > provide an interface to add new models in general? > > 3. Concerning IDM: While it is a very accurate model, which offers > a higher degree of realism than Krauss' model, it does not support > intermissions or multiple lanes. What can we do about that? > > I'll keep it to these three for now, but I might already have missed > a few things. > Here are my thoughts: > 1: The specific model should be used simulation-wide as a global > constant (i.e.: no need to have multiple models operating in one > simulation run). I propose adding a command line option to force > a specific model, so that old configurations could be re-used. The > reason for that is, that each model will compute movement based > on different per-vehicle attributes. Attributes not specified in older > configurations could be set to default values. To sum it up: The > behavior model could be chosen at simulation load time. > More fine-grained configurations would also be possible, but > I can't think of any use for such a feature, and it would possible > confuse the user. > I disagree. I think that there are several good reason for mixing different vehicle behaviour models. - using special models for trams, bikes, or whatever - having one vehicle within the simulation which uses a model is fed by a time line of vehicle speeds / used lanes or controlled via TraCI Also, I think that changing the car-following model on the command line would be problematic because different car-following models are using different parameters. Not only their names but also theri semantics differ. Using the same configurations and just trying to switch vehicle models on the command line would arise the need to either define all possible parameter for all potentially used car following models or to build a mapping between the used parameter and the one used by the models. I think that both is impossible in fact, due to different semantics and partial overlapping. So, I think that the car-following model to use should be described in the "vehicle type" of the simulated vehicles. What I am still not sure about is how the definition should be built. Either a) <vtype cfModel="xxx" xxxParam1="..." xxxParam2="..." ... or b) <vtype-XXX xxxParam1="..." xxxParam2="..." ... I personally prefer the first variant (a), because it allows to define both the car-following and the lane-change parameter in one definition. But it still has the disadvantage to be not validatable by an XML schema. > 2: I see three sections here: Vehicle instantiation: This is the > easiest part, since ROVehicleType is already implemented to > support different classes of vehicles as subclasses. Yes, but I suppose it is neeed to rework it. For some more sohisticated routing algorithms, some attributes should be assumed to be always needed; vehicle's class and vehicle's maximum speed are such candidates, because they affect choosing the route. This means that the base class (within routers) should contain at least these attributes. Now, I see again two possibilities of dealing with model-specific parameters a) read them into a map, not evaluating them and simple pass them to the output b) build sub-classes of models, parse the parameter and write them back again. I think that here the first solution is the fastest one to implement and reduces code in routers, because of not implementing the models' representations. The disadvantage but is that the parameters are not (complitely) verified by the routers. Nonetheless, I think that it thoug should be favoured - additional, model-specific evaluation could be built "on top". > Configuration/simulation setup: I don't know how this works > yet, but should not be much of a problem, since it's only added > options. Again, I think changing it on the command line is not an option. > The microsim part: I have to admit, I don't understand the way > position updates are computed in MSVehicle/MSVehicletype/ > MSLaneChanger yet, or let me put it this way: I don't understand > why it's implemented the way it is. I guess is it would be a good > idea to add some abstract classed here which define interfaces > for acceleration/deceleration and lane changing. But as I said, > I have yet to understand the underlying ideas of the current > implementation. Daniel, your help here would be highly > appreciated. > You are welcome. Yes, especially the lane-changing is really badly design. The reson? Well, time-pressure. The initial lane-changing algorithm had problems with navigational lane changes - they are simply not covered by Krauss - nor by Treiber's models (IMD, IDM-LC). I think for the first, we (the DLR will make some work on model exchanges as well as written before) should concentrate on the car-following model interfaces. I think we should take the MSVehicleType class and for each method it contains note which is a part of a model-specific API and which is not - is needed due to something SUMO-specific like differing vehicle classes. Then we should move the model-specific part into a subclass and implement an IDM class - in fact, we will implement a subsecond-model class... My proposal would be to open a page on the wiki about this. > 3: I remember reading that SUMO currently uses the MOBIL > lane changing model, i can't find the source right now though. > The people behind Vanet-Mobisim already integrated an > enhanced version of IDM into their software: IDM-LC, this > seems pretty good, for us, since they already did all the > groundwork. Aeh, no. SUMO uses LC_DK2008 which is the successor of LC_DK2006 which is the successor of LC_DK2004 :-) They are all based on the lane change model described by Krauss, BTW. Honestly. To stay short: models like the original Krauss model or MOBIL resemble how vehicles use lanes to divide on a multi-lane road. They have no methods for simulation of a driver's behaviour for choosing a lane has has to enter because he wants to move into a certain direction. Though, now, after rethinking it, it may be interesting to have a two-layered approach in SUMO - a navigational layer based on what is implemented here for now, and a tactical layer where either MOBIL, or Krauß' lane changing could be used. But: this can get very ugly very fast. I have a principal question: in the recent past (probably with a growing interest in using SUMO) the number of email stating IDM should be used grows. Tobias, you also write that on IDM that "... While it is a very accurate model, which offers a higher degree of realism than Krauss' model ...". Now my question: where does it come from? I mean could you (or anyone else) point me to a comparison of both models? Don't get me wrong - I am a computer scientist and as I started here I was quite surprised that the traffic simulation I was employed to work at models a car driver's behaviour with just three equations. In the mean time I have seen many problems when using Krauß, too. Though, I am not convinced that IDM is better, just because it is more popular. BTW: we made some model comparisons some time ago; you can find the list below: http://elib-v3.dlr.de/6505/1/COMPHYS2002_paper_wagner.pdf http://elib-v3.dlr.de/6506/1/FOVUS2002_Brockfeld_K%C3%BChne_Wagner.pdf http://elib-v3.dlr.de/6653/1/TGF2003_EB_PW_fullpaper.pdf http://elib-v3.dlr.de/6646/1/TRB2003-001164.pdf http://elib-v3.dlr.de/6646/1/TRB2003-001164.pdf http://elib-v3.dlr.de/6709/1/WCTR2004_Brockfeld.pdf http://elib-v3.dlr.de/6706/1/2004_01_08_Braunschweig_Kolloquium.pdf http://elib-v3.dlr.de/21349/1/FOVUS2004_Brockfeld.pdf http://elib-v3.dlr.de/6652/1/TRB2004-001743.pdf sincerely, Daniel > > Here are two links to explanations of IDM: > http://www.vwi.tu-dresden.de/~treiber/MicroApplet/IDM.html > http://xxx.uni-augsburg.de/pdf/cond-mat/0002177v2 > and in action: > http://www.traffic-simulation.de/ > A short explanation of IDM-LC can be found in: > http://vanet.eurecom.fr/publications/anss07.pdf > > OK, that's it for now, I hope I'll get some comments here, as it could > really help me with the work. > Unfortunately, i'll not be able to do a lot of work on the project next > week, since i'll be on vacation. > > greetings, > Tobias > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > sumo-devel mailing list > sum...@li... > https://lists.sourceforge.net/lists/listinfo/sumo-devel > ______________________________________________________ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de |