|
From: Björn H. <hen...@ib...> - 2011-02-14 14:46:07
|
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 |