[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| 
Re: [sumo-dev] Setting individual traffic light state via TraCI (follow up)
 | 
Hey Jakob,
this already sounds a lot like what I had in mind. Very nice that the 
linkIndices can be edited in NETEDIT now!
The linkIndex attribute seems not to arbitrary, in that I can only set 
it between 0 and [number of links - 1]. Is this a restriction by design? 
Longer numbers could by themselves suffice, I could use them as an id 
also in my own application. Otherwise, mapping is good idea and indeed a 
way better option than adding some arbitrary string to the core models 
of SUMO.
As for the mapping, I could also easily do that in my own (C#) 
application. Having it inside SUMO would of course be nice, but if this 
is a rare requirement, I would not prioritize it. Being able to edit 
<param> values in NETEDIT may however be a nice feature in general? If 
that is implemented, implementing the mapping for links may be trivial.
Is the command traci.trafficlight.setLlinkState only available for 
Python? The wiki does not list this as a seperate TraCI command.
Cleanup states seems not to have effect in the nightly build I am using; 
the strings stay the same. Changing the linkIndex does have effect.
A thing I noticed: hit testing for links seems not to work well for long 
straight lines: clicking on the line further away from the connected 
edge (edgeFrom), that is, closer to edgeTo, selects the junction instead 
of the link. Not a major bug, but I thought I'd mention it nonetheless.
Thanks, greets,
Menno
Op 14-12-2017 om 9:49 schreef Jakob Erdmann:
Hello,
in the latest development version of sumo the following things are 
implemented:
- you can assign custom numerical values for each traffic-light 
controlled connection in netedit (inspect connections and set attribute 
linkIndex)
- multiple connections can share the same numerical value and thus form 
a group
- traffic light programs can be shortened to the number of used values 
(button 'cleanup states' in traffic light mode)
- these numerical values can be shown in netedit and sumo-gui (junction 
settings 'show link tls index')
- the command traci.trafficlight.setLinkState sets the state for the 
given numerical value
So the only thing that is missing is the capability to assign stringIDs 
for the numerical group ids. I'm reluctant to add string-aliases to the 
core data model of a connection because it is somewhat redundant. 
However, sumo supports key-value maps for storing non-core parameters 
and abitrary user data. These maps can be read and written via TraCI and 
are also shown in SUMO-GUI (The only thing currently missing is editing 
them in netedit).
For example traffic light parameters see 
http://sumo.dlr.de/wiki/Simulation/Traffic_Lights#Actuated_Traffic_Lights
I think adding a new parameter
<param key="alias" value="K1 K2 K3 K4"/>
that would map the alphanumerical Ids K1 to K4 onto the numerical group 
IDs 0 to 3 would be fine.
Things that would be needed:
1) in the gui, when selecting show link tls index, the alias should 
automatically be shown below the index value if it exists
2) in traci.trafficlight.setLlinkState a non-numerical index should 
automatically be translated into the numerical ID using the alias 
parameter if it exists
3) in netedit, there should be a way to show and edit <param> values.
Points 1 and 2 should be very easy to do but 3) requires some thinking 
about UI design to make it fit nicely into the general architecture 
(many objects besides traffic lights can use <param>s). 3) is on our 
to-do list anway and would probably be done in the first quarter of 2018.
I guess if you mostly keep your signal plans in separate xml files or 
you set them via TraCI anyway then 3) is not urgently needed for your 
use case.
What kind of use do you anticipate?
regards,
Jakob
2017-12-12 10:48 GMT+01:00 Menno van der Woude <menno@xxxxxxxxxxxxxxxxxx 
<mailto:menno@xxxxxxxxxxxxxxxxxx>>:
    Hello,
    a while ago I patched SUMO to allow me set state for individual
    traffic lights via a Traci command (see the patch I sent on 23th
    July 2017). This worked, but I still would like to implement it in a
    more robust way, preferably:
    - allow (via netedit) setting a property on a connection in an
    intersection; not a unique ID, because sometimes multiple
    connections will belong to group of lights controlled as a single
    phase. So it would be a string property called "TrafficLightId" or
    similar.
    - add a Traci call that allows setting the trafficlight state for a
    'single' traffic light, where a 'single' traffic light means all
    connections that have a given value set for the "TrafficLightId"
    string property.
    This scenario would, at least in my case, make it much more easy to
    control an intersection using Traci: I could thus easily set the
    TrafficLightId values for all connections of an intersection, and
    from my Traci client implementation, call a
    SetSingleTrafficLightState function, using those (not unique) Id values.
    This as opposed to the current situation, where I have to closely
    look at the connections in Netedit, to determine their index in the
    traffic light state string (e.g. "yyyGGrr"), and subsequently map
    the traffic lights from my program to that indexed string.
    The latter means much manual work and manually coding the named
    mapping of lights to the string. It is also very sensitive for
    mistakes. The former could be implemented in the Traci client in a
    much more generic way.
    What is your view on this? I would be happy to take time to
    implement this, however, I wonder if this would be a feature that
    could find its way back into the SUMO master branch? Otherwise it
    would make little sense, as I would have rewind my changes onto the
    master branch very often. If this is a welcome addition, I would
    need some advice where to start with adding the named property to a
    connection, and how to add a textbox to the UI of netedit for this.
    Thanks, kind regards,
    Menno van der Woude
    CodingConnected e.U. (Wien - Österreich)
    E menno@xxxxxxxxxxxxxxxxxx <mailto:menno@xxxxxxxxxxxxxxxxxx>
    W www.codingconnected.eu <http://www.codingconnected.eu>
    _______________________________________________
    sumo-dev mailing list
    sumo-dev@xxxxxxxxxxx <mailto:sumo-dev@xxxxxxxxxxx>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit
    https://dev.eclipse.org/mailman/listinfo/sumo-dev
    <https://dev.eclipse.org/mailman/listinfo/sumo-dev>
_______________________________________________
sumo-dev mailing list
sumo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-dev