Re: [sumo-devel] Speed settings by TraCI

[Björn H. <hen...@ib...>]

Hi Daniel,

On Friday 11 February 2011 13:10:04 wrote Daniel Krajzewicz:
> Ok. We - mainly Michael and me - want to solve these issues for some weeks
> already but simply had not yet the time to sit down and rethink everything.
> That's also why your mails were not answered.

No problem. Focus is always moving and you saw that mine was not on SUMO for 
some time until recently.

> Maybe all of us should discuss this now on the list, and we'll try to fix
> this during the next week.
> 
> I think the following is needed:
> 
> a) give a certain speed to use
> - implemented (4)
> - recheck:
> -- valid for one time step only, or for a (given) duration
> -- extract code from MSVehicle (see c)

ACK

> b) give a certain speed to use, let vehicle regard safe velocity
> - not implemented
> - as a), but vehicle uses MIN(given speed, safe speed)
> - recheck:
> -- valid for one time step only, or for a (given) duration
> -- extract code from MSVehicle (see c)

This is what I would need if it includes the usual randomness AFTER applying 
the given speed limit. Maybe it should be optional if randomness is still 
applied or not.

Technically I would extend the basic MSModel with an applyRandomness function 
so that MSVehicle::moveRegardingCritical can call the model-specific randomness 
function when it's appropriate.

That would make it also easier to correctly implement the 
speedWithoutTraciInfluence function which (in my case) should return the speed 
WITHOUT applying randomness.

For the cases (a) and (b) I see two different use cases. (a) is to simulate a 
device which automatically controls speed like a tempomat or an electronic 
distance keeper. Those are outside of the drivers influence and take over 
responsibility to avoid collisions. On the other hand (b) simulates a velocity 
recommendation to the driver. The driver is still in charge to obey v_safe and 
there is still randomness in following the recommended speed.

Maybe these use cases can help to design the effects of the TraCI commands.

> c) slow down
> - to be reworked
> The point is that we really do not want to have like three or what
> variables in MSVehicle just for controlling the speed. My idea is to have
> some kind of an influencing decorator which performs the computation and
> sets the vehicle's speed - hopefully using the the same methods as in a/b.
> I assume "slow down" is basically an "adapt speed" or similar. A speed is
> given and the time to reach it - the speed may be lower or higher than the
> current. The vehicle should accelerate/decelerate to the given speed within
> the given time interval. It should be verified whether this matches the
> current implementation.
> 
> d) slow down, regarding safe velocity
> Is this needed? Or is c) unneeded?

I'd throw out the slow down commands. Especially in the current design where 
the speed limits ceases completely after the duration. This appears to me to 
be very project specific. If such behavior is needed it can be implemented with 
above low level commands (a) or (b).

Instead of such high level commands like slow down I'd suggest a plugin 
interface. The interface offers to call any of the internal TraCI command 
functions and it is connected to a new pair of value set/retrieval commands. 
Additionally the plugin gets a call on every timestep.

So, the plugin gets called whenever the TraCI client passes a plugin value 
set/retrieval command with the given variable ID. Then the plugin may call 
read/write functions for the simple data types to exchange the values with the 
TraCI client. The plugin call on every timestep could further be used to 
implement long term algorithms like the mentioned slow down.

Technically the interface could be a base class from which the plugin has to 
derive. Additionally there might be a proxy plugin which connects to a dynamic 
library (.dll or .so) so that you can simply load another plugin without 
recompiling SUMO.

Maybe the SUMO user community will provide some handy plugins as time goes by.

Of course, the drawback would be that there would be another public interface 
to maintain. Alternatively, projects could achieve the same with a TraCI proxy 
between SUMO and the actual client but that might require more implementation 
skills and costs more performance.

> e) Change vehicle's type max speed
> Ok, this is done, and yes, it has several side-effects. I'd keep it .

Currently some vehicle set value commands replace the vehicle's type with a 
temporary one. IMHO the effects are difficult to understand for the TraCI user.

Instead I would add a set vehicle type value command to change the properties 
of an existing type. Additionally there should be a variable to copy an 
existing type to a new one with another ID. Then there should be a set vehicle 
variable to reassign the vehicle to another type.

With these commands the TraCI user would have full control which vehicle 
belongs to which type and what properties those types have.

Of course, to complete this there should be another set vehicle type variable 
to delete an existing type which returns an error if the type is still 
assigned to an existing vehicle or one waiting to be emitted. This would allow 
cleanup for TraCI clients which heavily copy types.

> Now, yes, the default model - we should not call it Krauß anymore in fact -
> is somehow odd. Several years ago, we replaced the static acceleration by
> one that depends on the maximum velocity. In most of our use cases, this
> works alright. But as soon as you start to use the vehicle's maximum speed
> honestly - for simulating slower trucks, or for GLOSA-like speed control,
> the model is pretty bad as the slower vehicles can not properly accelerate.
> One solution would be to use vmax/2 instead of vmax for reducing the
> acceleration. What do you think?

I've also seen the truck max speed problem. I'm afraid we would need another 
speed value for the vehicle type. The existing max speed is the physical max 
speed of that type which, of course, can only be reached asymptotically. 
Additionally we would need an "allowed max speed" or "max speed by law" which 
will be applied like the lane's max speed. So in case of trucks their physical 
max speed could be, let's say, 95 km/h and their max speed by law 80 km/h. If 
unset the max speed by law could be equal to the physical max speed.

Unfortunately the max speed by law might depend on the type of road. IIRC 
there are vehicles which are allowed to go 80 km/h on the Autobahn and 60 km/h 
on country roads. So, their might be the requirement to configure a mapping of 
road type on max speed by law for each vehicle type. But maybe this could be 
future work.

OK, those are my ideas for now about TraCI's future. What do you think?

Regards
Björn