Hello Jakob, Device is implemented by now. I was wondering if it is possible to use device to send which signs it detected using python lib traci <http://www.sumo.dlr.de/pydoc/traci._vehicle.html#VehicleDomain-getParameter> or libsumo. I can easily get device state using the following line: traci.vehicle.getParameter(veh, "has.signDetector.device") But for me it is not enough.
It seems SUMO only allows to get info from these devices/parameters <http://sumo.dlr.de/wiki/TraCI/Vehicle_Value_Retrieval#Supported_Device_Parameters> . Do you believe there is a workaround for this? Regards, Lauro de Lacerda Caetano On Thu, 25 Oct 2018 at 16:15, Jakob Erdmann <[email protected]> wrote: > 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 >
_______________________________________________ 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
