Devices do have access to all loaded shapes using MSNet::getShapeContainer. POis which are defined relative to a lane have the parameter "lane" set to the corresponding id. The only thing that is missing is lookup table that returns all POIs for a given lane id. Such a container could be created within the device (e.g. as a static member).
Am Di., 23. Okt. 2018 um 01:25 Uhr schrieb Lauro de Lacerda Caetano < [email protected]>: > 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 >
_______________________________________________ sumo-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-dev
