Hi Christian,
Currently the only mechanism to enlarge the logging time prior to the minTTC
would be to increase the criticality threshold.
Best,
Leo
Von: sumo-user-boun...@eclipse.org [mailto:sumo-user-boun...@eclipse.org] Im
Auftrag von christian.damdjow...@zf.com
Gesendet: Donnerstag, 21.
Hi Christian,
Sorry, currently, there is no filter implementation for the C++ client. I think
is not so difficult to add it, though.
For that, one should take a look at what is done in the corresponding methods
of the python client (in tools/traci/_connection.py and tools/traci/_vehicle.py
-
Hi Lan,
The velocity is a vector – a pair (dx,dy) per time step. If you are interested
in the speed, you have to take the vector’s length. That will give you the
value in m/s.
Best,
Leo
Von: sumo-user-boun...@eclipse.org [mailto:sumo-user-boun...@eclipse.org] Im
Auftrag von Emily Z.
I wasn't able to reproduce the error, either. Please send a minimal failing
example.
Best,
Leo
Von: sumo-user-boun...@eclipse.org [sumo-user-boun...@eclipse.org] im
Auftrag von Michael Behrisch [o...@behrisch.de]
Gesendet: Montag, 9. Juli 2018 09:01
An:
Take a look at the following Wiki page:
http://sumo.dlr.de/wiki/Definition_of_Vehicles,_Vehicle_Types,_and_Routes
--> vehicle-attribute arrivalPos
Best,
Leo
-Ursprüngliche Nachricht-
Von: sumo-user-boun...@eclipse.org [mailto:sumo-user-boun...@eclipse.org] Im
Auftrag von Flávio
Hello Maryam,
There is one more thing I can think of as a source of error given the provided
information, which is that the setOrder-command should be sent for each client
*before* sending the first simulationStep-command.
If this does not fix the problem, I’d ask you to provide a more
Hello,
The response (inMsg) is not supposed to return the assigned order. It returns
an acknowledgement of the received command (the command id itself 0x03 in case
of CMD_SETORDER) and a status-flag (0x00 indicates successful execution). So
you should expect to receive the same response even
