Hi Jakob, thanks for the guidelines that you suggested. Well, it seems that a C++ extended device (such as this example <http://sumo.dlr.de/wiki/Developer/How_To/Device#MSDevice_Example>) does not directly track static information such as POIs unless through utils/traci/TraCIAPI.h. Am I right? Is there any other workaround to track poiLanes using only C++ coding?
I will give it a try on the Python way by trying libsumo or traci (through subscriptions). Thanks a lot. regards, Lauro. On Tue, 16 Oct 2018 at 16:34, Jakob Erdmann <[email protected]> wrote: > I think I understand your uses cases better now and I can offer a > suggestion for implementing this in SUMO. > There are three layers to this: > 1) representation of signs / road side objects > 2) modification of vehicle behavior > 3) tracking of rule compliance > > For 1) I think using POIs which are defined relative to a lane are the > simplest solution (using attributes lane, pos, posLat). POIs already > support the type attribute which can be set to an arbitrary string. > Furthermore, POIs support assignment of additional user parameters ( > http://sumo.dlr.de/wiki/Simulation/GenericParameters) > If TraCI is used for 2) and 3), It would be helpful (and fairly simple) to > add some traci function to retrieve POIs that are defined relative to a > given lane. > > For 2) The choice between implementing a device and using TraCI boils down > to choosing between execution speed and implementation effort. By using > libsumo (http://sumo.dlr.de/wiki/TraCI#Using_SUMO_as_a_library) the speed > issue of TraCI can be mitigated. > > For 3) This is similar to 2) When using a device It's probably simpler to > track compliance within the same device that also affects behavior. > Aggregation of compliance data could be done in post processing. Adding > custom detectors that track compliance would require a thorough > understanding of the simulation architecture > > regards, > Jakob > > > Am Di., 16. Okt. 2018 um 20:36 Uhr schrieb > > Lauro de Lacerda Caetano > > <[email protected]>: > >> 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 < >> [email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]>: >>>> >>>>> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]>: >>>>>> >>>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/sumo-dev
