In your own device, you can implement the methods getParameter and setParameter. See src/microsim/devices/MSDevice_Example.cpp The example device supports the call traci.vehicle.getParameter(vehID, "device.example.customValue1") By adapting the code you can set/get all the parameters you want.
regards, Jakob Am Mo., 5. Nov. 2018 um 22:46 Uhr schrieb Lauro de Lacerda Caetano < [email protected]>: > 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 >
_______________________________________________ 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
