namdre
commented
4 years ago If I understand you correctly, you need an API to modify the speed computed by the SUMO models in accordance with an external model of how a physical vehicle reacts (engine response etc..). To do so you need "intendedAcceleration" and this should affect the observed vehicle acceleration, speed and position.
The existing commands are not well suited for this:
- moveToXY requires x,y positions rather than accelerations/speed (it does however updated speed along with the position)
- moveTo only corrects the lane-position but does not correct speed/accelration and also requires knowledge of the road topology when adapting speeds at edge boundaries
- setSpeed sets a fixed speed for future time steps rather than doing a one-time correction
A new command vehicle.adaptPreviousSpeed(vehID, speed) could fix this.
- it would reposition the vehicle along it's route as if it had driven with the corrected speed rather than the previously computed speed
- Since TraCI commands take effect before new vehicle movements are computed, other vehicles would react to the ego vehicle exactly as if it had driven with the correctedSpeed (https://sumo.dlr.de/docs/Developer/Implementation_Notes/Simulation_Loop.html)
Would this solve your problem or did I misunderstand you?
Domsall
IKMUN95
To create a submicroscopic simulation, I have combined a virtual vehicle in Simulink with SUMO via the C++ TraCI-API (or using TraCI4Matlab). Many different TraCI-commands already exist for achieving such tasks: e.g. with getLeader, getNextTLS, getBestLanes, and so on, one can retrieve the variables needed for a CF/LC-model working outside of SUMO. Another way of communicating with SUMO is to work with the CF-models already implemented in SUMO via commands like getfollowSpeed and getStopSpeed. In my opinion, it is a hard task to create own driver models for the submicroscopic simulation with SUMO, which should work similar to the included CF/LC/junction-models.
Back in my SUMO v1.0.1 fork, I added a TraCI-command which lets the Simulink model benefit from the extensive model library of SUMO. Now I would like to know if it makes sence to push this command back to the newest SUMO version in the main branch (or if such tasks "SUMO<->virtual vehicle" are normally handled differently). The command is called get/setFutureSpeed and works similar to get/setSpeed. When using the command setFutureSpeed, the SUMO-vehicle is put into a remote listening mode. In every time step and for every vehicle, SUMO calculates vNext. Instead of now updating the ego-vehicle with vNext, the intended acceleration is sent to the Simulink-vehicle, which tries to reach vNext. As the Simulink-vehicle will never perfectly reach this velocity, the actual achieved speed and position is sent back to SUMO (moveTo, setFutureSpeed). SUMO then calculates the next vNext with the new position and speed. The advantage of this operation mode is that the user can use the different models of SUMO (e. g. ACC, CACC, IDM) and benefit from further development without changing the control concept of the Simulink vehicle. Overriding vNext of SUMO is still possible (e. g. when transitioning between automated and conventional driving or to force a lane change).