Sorry, a mistake in 3) Case of a brake check area sign, where vehicles must apply pull off behavior
Consider this: 3) Case of a brake check area sign, where vehicles must break. Regards, Lauro. --- Lauro de Lacerda Caetano IEEE and VTS Member On Tue, 16 Oct 2018 at 15:25, Lauro de Lacerda Caetano < laurodelace...@gmail.com> wrote: > Hello Jakob, thanks for getting back to me so quickly. > > I comprehend the aforementioned examples you have given about speed > regulation. > > In sum, I want to extend SUMO with an additional layer composed of street > signs (probably in the form of pois) that would be detected by vehicles > (using a device) that could choose to behave accordingly or not. For this > to be possible, I should be able to change vehicle behavior at run time, > especially adding constraints that will mostly impact mobility in terms of > acceleration/deceleration, lane change, right-of-way rules, overtaking > rules and other issues that may arise. > > Take the four following cases as concrete examples of street signs: > > 1) Case of a car triangle left by some driver that would inevitably > obstruct a lane. Vehicles approaching this car triangle could reduce speed > and apply lane changes in a cooperative way. > 2) Case of a two-way bridge, where overtaking is not allowed. A street > sign could trigger this "rule" and constrain vehicle behavior in the bridge > context. > 3) Case of a brake check area sign, where vehicles must apply pull off > behavior > 4) Case of an intersection right of way, that could be dynamically changed > according to some criteria (traffic flux controlled by a public agent, > approaching emergency vehicle ) > > More importantly, every vehicle and public detectors (which would be > extended devices) should be able to identify norm compliance (every vehicle > would know when it is going against the rules or not). > > Regards, > Lauro. > --- > Lauro de Lacerda Caetano > IEEE and VTS Member > > > > On Fri, 12 Oct 2018 at 16:35, Jakob Erdmann <namdre.s...@gmail.com> wrote: > >> Hello, >> your example is still quite abstract and all I can think of myself are >> signs that regulate speed (e.g. speed limit signs or stop signs). >> Currently, obedience to speed limits is configurable for each vehicle >> type (attribute speedFactor) whereas obedience to stop signs cannot be >> configured (violating red lights can be enabled though). >> Right now you can use TraCI to check whether a vehicle passes a speed >> sign (implicit from the fact that it passes between edges with different >> speed limits). >> Using TraCI you can also apply any kind of behavior adaptation you like. >> You can also use TraCI to figure out whether a vehicle is approaching a >> stop sign or a yield sign and modify its behavior in some way (again the >> signs are encoded in the network model already). >> If you can come up with further concrete examples of signs, then I can >> tell you whether they are already included in the models or how to model >> them. >> regards, >> Jakob >> >> >> >> Am Fr., 12. Okt. 2018 um 17:16 Uhr schrieb Lauro de Lacerda Caetano < >> laurodelace...@gmail.com>: >> >>> Hi Jakob, thanks for replying. >>> >>> The idea is to have a device that can identify traffic signs in run time >>> and apply pre-defined behaviours upon the emergence of these signs. Also, >>> this device could be used to check if a vehicle is complying with traffic >>> norms on the fly and pass this information to others applications. >>> >>> As an interactive reaction to some kind of street sign, take the two >>> following cases: >>> >>> 1) A set of warning signs <https://en.wikipedia.org/wiki/Warning_sign> >>> that advert drivers to change their driving style to a less aggressive >>> behaviour. >>> 2) A set of regulatory signs >>> <https://en.wikipedia.org/wiki/Regulatory_sign> that obligates drivers >>> to behave in a desired manner. >>> >>> It would be interesting to set a rate of obedience to each vehicle type >>> (vtype) in face of different kinds of street signs and check compliance >>> with traffic norms (maybe using a device). >>> >>> The extention of this features could possibly make the traffic >>> simulation a little more realistic. >>> >>> Is this kind of feature possible (maybe with an extension) with SUMO? >>> >>> Regards, >>> Lauro. >>> >>> >>> Em sex, 12 de out de 2018 03:28, Jakob Erdmann <namdre.s...@gmail.com> >>> escreveu: >>> >>>> In SUMO the effect of street signs is already encoded in the network >>>> model (.net.xml) in the form of speed limits and right-of-way rules. For >>>> specialized signs such as variable-speed-signs, additional objects can be >>>> declared and loaded into the simulation at startup ( >>>> http://sumo.dlr.de/wiki/Simulation/Variable_Speed_Signs) >>>> The whole purpose of the street-sign output was to serve as additional >>>> visualization for the end user. >>>> >>>> If you give an example of the type of interactive reaction to street >>>> signs that you have in mind I may be able to give advice on how to model >>>> this in sumo. >>>> >>>> regards, >>>> Jakob >>>> >>>> Am Do., 11. Okt. 2018 um 23:41 Uhr schrieb Lauro de Lacerda Caetano < >>>> laurodelace...@gmail.com>: >>>> >>>>> Hello, SUMO community. >>>>> >>>>> I am currently creating traffic simulations with SUMO and I am >>>>> interested in including street signs and extending a class (maybe a >>>>> device) >>>>> that could help me to identify these street signs and change vehicle >>>>> behavior at run time. >>>>> >>>>> My question is: Is this possible with SUMO? Could vehicles react to >>>>> some kind of street sign (a type of POI of these types >>>>> <http://sumo.dlr.de/wiki/Networks/Further_Outputs#Street_Signs>, for >>>>> instance) during the simulations? >>>>> >>>>> Thanks for your help. >>>>> >>>>> Kind regards, >>>>> Lauro. >>>>> --- >>>>> Lauro de Lacerda Caetano >>>>> IEEE and VTS Member >>>>> _______________________________________________ >>>>> sumo-dev mailing list >>>>> sumo-dev@eclipse.org >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://dev.eclipse.org/mailman/listinfo/sumo-dev >>>>> >>>> _______________________________________________ >>>> sumo-dev mailing list >>>> sumo-dev@eclipse.org >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://dev.eclipse.org/mailman/listinfo/sumo-dev >>>> >>> _______________________________________________ >>> sumo-dev mailing list >>> sumo-dev@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/sumo-dev >>> >> _______________________________________________ >> sumo-dev mailing list >> sumo-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/sumo-dev >> >
_______________________________________________ sumo-dev mailing list sumo-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/sumo-dev
