Hello, the longitudinal dynamics are mainly determined by the car-following model and subject to a number of constraints listed here: http://sumo.dlr.de/wiki/Simulation/VehicleSpeed Basically the maximum change in speed from one simulation step to the next is bounded by the user-configurable parameters 'accel' and 'decel', multiplied by the simulation --step-length parameter The maximum angle during lane-changing is constrained by the 'maxSpeedLat' parameter (the maximum lateral change in meters per second) as the angle is derived from the longitudinal and lateral speed of the vehicle. To obtain the lane-changing decision for the current time step you would call traci.vehicle.getLaneChangeState for the response semantics, see http://sumo.dlr.de/wiki/TraCI/Vehicle_Value_Retrieval#change_lane_information_.280x13.29 The getBestLanes command may be used to get a look at the strategic change requirements ahead.
regards, Jakob 2017-07-03 18:40 GMT+02:00 Manuel Schmidt via sumo-user < [email protected]>: > Hello, > > thank you for your take on this and your recommendations. > After playing around with the Sublane model, I have to say that it already > performs very well. Especially combined with Krauss/SmartSK or BKerner > car-following models and a good parametrization. > > Could you maybe also provide some insights about how the longitudinal > accelerations/deceleration or velocities are picked within SUMO? Is there > already a first-order lag characteristic implemented? So that velocities > cannot jump for example? > > Because if that is already the case, I believe only the lateral movements > have to be "refined" to better reflect reality. > Is there any parameter that allows to change the maximum angle during lane > changes? The parametrization within the <vType> seems to have just a very > slight effect on it. > > Furthermore - since you confirmed that the lane-change decision are now > provided by SUMO (since 0.30.0), I wonder which information are included > and which TraCI command has to be used. Is it one of getBestLanes, > couldChangeLane or getLaneChangeState? > > Thanks for the great Software - awesome work, really! > > Best regards > > Manuel > > ---------- Forwarded message ---------- > From: Jakob Erdmann <[email protected]> > Date: 2017-07-03 13:59 GMT+02:00 > Subject: Re: [sumo-user] Integration of lateral and longitudinal vehicle > dynamics into SUMO > To: Manuel Schmidt <[email protected]> > Cc: sumo-user <[email protected]> > > > Hello, > what you propose sounds very similar to something that is already being > done but several parties (also in the context of testing automated > vehicles): > coupling a submicroscopic vehicle simulation with SUMO to control one or > more vehicles with increased realism (with SUMO providing the background > traffic). Your case differs somewhat since you wish to extract the > lane-change decisions from SUMO instead of getting them from the > submicroscopic simulator (this extraction can be done since version > 0.30.0). > > So my answer is: yes this can be done. Tractability depends on your dynamic > model which you could "fit to (computational) cost". > > Some remarks regarding your original assessment: > - option --lanechange.duration is a distinct model to realize some effects > of non-instantaneous lane-changes at low computational cost. It is obsolete > when using the sublane model (where the duration is an emergent effect of > vehicle parameters and the traffic situation). > - the sublane model is under continuous development and aims at producing > realistic trajectories > - I recommend contacting sumo@... because we may be able facilitate > contact > with other interested parties to enable joint development efforts. > > best regards, > Jakob > > 2017-07-03 12:59 GMT+02:00 Manuel Schmidt via sumo-user < > [email protected]>: > > > Hi, > > > > I am currently looking for a simulation tool to develop algorithms in > the > > field of automated driving. Realistic traffic is therefore really > important > > in order to project the reality into the simulation. > > SUMO as a microscopic traffic simulator seems to provide great > capabilities > > in simulating traffic flow. > > > > However no sub-microscopic effects are taken into account. The vehicle > > dynamics in particular are disregarded. > > Some recent developments look really promising: > > - Sublane model > > - Enhanced movetoXY function > > - laneChange.duration (but very often not realistic) > > > > Since my knowledge of SUMO is still somewhat limited, I would like to > hear > > your opinions regarding my plan to integrate vehicle dynamics into the > > simulation. > > > > My plan is the following: > > > > A radius around one ego-vehicle will be defined. Other traffic > participants > > exist only within this radius. > > > > A vehicle dynamics model needs to be defined: > > Input: Accelerations (ax, ay) and Yaw-Rate > > Output: Velocities (vx, vy) and Yaw-Angle > > The vehicle state is comprised of accelerations, velocities and yaw-angle > > and can be calculated with finite-differences and saved to a variable. > For > > the longitudinal dynamics, a first-order-lag system could be used (see > > PLEXE). > > > > Ideally SUMO provides a signal for every vehicle that marks the start of > a > > lane-change and also the information of the target-lane or ideally target > > point (x,y,velocity) can be extracted (getBestLanes? getLaneID?). > > > > Next, realistic lane-change trajectories should be learned from data. A > > mean trajectory, parametrized by velocities could be extracted and used > as > > "candidate-trajectories". Some stochasticity can be provided by sampling > > from a distribution and superimpose these over the > > "candidate-trajectories". > > > > The whole process of updating the vehicles could look somehow like this > > (short "pseudo-code"): > > > > for veh_id in veh_ids: > > if laneChangeTrigger(veh_id) == true: > > goal_state = getGoalState(veh_id) <- "x,y,psi,v" > > candidate_trajectory = planTrajectory(veh_id, veh_id_state, > > goal_state) > > realistic_trajectory = overlayTrajectory(candidate_trajectory) > > for trajectory_point in realistic_trajectory: > > veh_id_new_position = moveToXY(moveVehDynamically(veh_id, > > trajectory_point, > > > > veh_id_state) > > > > > > Using a small value of --lateral-resolution should make sure that SUMO > > internally gets the correct representation of the scene and free drivable > > space. > > > > These are some ideas regarding the integration. What do you think about > > this? Does SUMO's TraCI interface provide all the necessary functionality > > in order to realize the above described behaviour? Is it computationally > > tractable? What problems could be encountered? > > > > > > Best regards > > Manuel > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > sumo-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/sumo-user > > > > > > > -- > Mit freundlichen Grüßen, > > Manuel Schmidt > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > sumo-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sumo-user > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ sumo-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-user
