Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Simulation is not using the specified Wiedemann Model
Thank you, Jakob.

Could you guide me in using the debugger and the steps I should take? I am not versed in C++ and am slightly confused right now.

Thank you,

Quinton

On Thu, Mar 22, 2018 at 3:51 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
I would use the debugger on the Wiedemann file and check why your D_MAX value takes no effect.
However, you could also start with some print debugging.
After you made me aware of an issue with deceleration I used the attached patch to figure out what was going on.
Note, that print debugging does not work with the msvc build of sumo-gui unless you change the application type to 'console'. It does work with sumo.exe.
regards,
Jakob

2018-03-22 20:31 GMT+01:00 Quinton Velcic <velcic@xxxxxxxxxxx>:
Hi Jakob, thank you for your response.

Could you clarify which code you are suggesting to use the debugger for, TraCI or the MSCFModel_ Wiedemann.cpp file?

I feel that there is no connection between the MSCFModel_Wiedemann.cpp file and SUMO simulation after changing any number in the cpp file. (For example, changing D_MAX to 500)

On Thu, Mar 22, 2018 at 3:06 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
In this case I recommend looking at the code path with a debugger (or at least putting print statements in the code to output the relevant values).
regards,
Jakob

2018-03-22 19:41 GMT+01:00 Quinton Velcic <velcic@xxxxxxxxxxx>:
Hi Jakob,

I have done so and my simulation works as expected, but in terms of changing constant parameters within the Wiedemann model I am not seeing any changes. 

For example, I changed D_MAX from 150 to 500 and then looked at the resulting speed profile. Even when the condition dv > sdv && dx < D_MAX is met, the speed does not reduce until dx is less than 150.

On Wed, Mar 21, 2018 at 5:49 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
To make your own changes you will have to build sumo from the sources files. Guides for different operating systems can be found at http://sumo.dlr.de/wiki/Developer/Main#Build_instructions


2018-03-21 21:24 GMT+01:00 Quinton Velcic <velcic@xxxxxxxxxxx>:
Thanks for your reply Jakob.

I'm not very well acquainted with building source files and using git. As far as I understand, if I clone and checkout the git repo, I don't have to build anything as SUMO is already built in the repo. Please correct me if I'm wrong.

Assuming the above, I did the following:

git clone https://github.com/DLR-TS/sumo.git
git checkout -b v0_32_0
This resulted in following message: 

Switched to a new branch 'v0_32_0'


But I still don't see sumo.exe or sumo-gui.exe files. I want to use them in TraCI to specify sumoBinary. 

Is my procedure for installation correct? How do I use the new sumo with TraCI?


Thanks,

Quinton

On Wed, Mar 21, 2018 at 2:34 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
if you want to build version 0.32.0 from source you can use this: http://prdownloads.sourceforge.net/sumo/sumo-src-0.32.0.zip?download
However, you could just as well clone our git repository and check out the 32 tag: https://github.com/DLR-TS/sumo/releases/tag/v0_32_0
If you figure out further problems with our Wiedemann implementation, please let me know.
regards,
Jakob

2018-03-21 17:40 GMT+01:00 Quinton Velcic <velcic@xxxxxxxxxxx>:
Hi, thank you for your response.

To make any changes to the MSCFModel_Wiedemann.cpp file do I need to build the development version of SUMO?

I noticed that in the sumo-msvc folder there is no src folder.

Thank you,

Quinton

On Tue, Mar 20, 2018 at 3:54 AM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
It would be best if you could provide your scenario, as its hard to get the exact numbers from your plot and dx is missing anyway
(or at least give the exact values of v, vLeader, and gap in step 81).
When trying to replicate this I can see situations where dv > sdv and the vehicle does not decelerate due to the additionial condition of dx < D_MAX. Otherwise, the vehicle brakes as expected.

Also, the usage of 'decel' and 'emergencyDecel' in our implementation of the Wiedemann model is somewhat complicated.
In sumo the decel parameter (in 2011 when this model was implemented) was used to represent two things at the same time:
- (1) comfortable decelaration
- (2) maximum deceleration which should never be exceeded

- the value of bx which controls braking in the approaching regime is based on the 'security' parameter not on decel
- the braking value for the emergency regime was taken from decel with the idea that it represents maximum deceleration.
- the results for acceleration in the approaching regime were also limited to decel, again with the idea that it represents maximum deceleration. The original Wiedemann model has no such limitation!
 Obviously, this gives bad results when you set a low value for decel under the assumption that int controls braking in the approaching regime.

In the meantime we have introduced the new parameter emergency deceleration which seperates the two concepts (1) and (2). Therefore as of yesterday, the 'decel' value isn used anymore by the Wiedemann model for car-following. The 'decel' value is still used in a different formula when the vehicle is supposed to stop at an exact position (something which the original model does not deal with).

regards,
Jakob


2018-03-20 4:14 GMT+01:00 Quinton Velcic <velcic@xxxxxxxxxxx>:
Thank you for your explanation. However, I don't think this problem is related to the use of decel or emergencydecel. But rather it has to do with driving regime.

As I showed in the plot, the speed difference dv becomes higher than approaching regime threshold sdv in time step 81. I have used the formula of sdv from MSCFModel_Wiedemann.cpp file. According to the conditional statements in this file, if dv > sdv and dx < D_Max then the ego vehicle is in approaching regime. Also, in approaching regime the Decel parameter should be used for deceleration.

But even when the vehicle is in approaching regime in time step 81 and dx is way less than D_max, it does not use Decel (or emergencydecel) in the next time step (82). Instead, it starts using Decel at time step 89. There is a difference of 7 seconds in perception of sdv and reaction. What is causing this  difference?

Thanks,

Quinton

On Mon, Mar 19, 2018 at 6:43 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
You could compare the formula for your manual computation with the one in lines 109-153 at https://github.com/DLR-TS/sumo/blob/master/src/microsim/cfmodels/MSCFModel_Wiedemann.cpp

However, I think you have stumbled upon a bug that was first recorded in 2014 (https://github.com/DLR-TS/sumo/issues/1351).
As you may guess from that date, we do not use the Wiedemann model very often.
What it boils down to, is that the actual deceleration was bounded by the 'decel' attribute of the vType instead of the 'emergencyDecel' attibute (the emergencyDecel attribute represents the physical limit of braking and was not yet available 2014).
The bug is now fixed in the development version (binaries updated tomorrow at http://sumo.dlr.de/wiki/Downloads#SUMO_-_Latest_Development_Version).
Note, that in some situations your value of emergencyDecel="5.5" is not sufficient to ensure accident free driving.

regards,
Jakob

2018-03-19 21:13 GMT+01:00 Quinton Velcic <velcic@xxxxxxxxxxx>:
How do I make sure that the simulation is using the Wiedemann Model?

In my simulation this is how I am defining the Wiedemann model:

        <vType id="car1" vClass="passenger" accel="1.4" decel="1.8" length="4.64" maxSpeed="33" color="1,1,1" carFollowModel="Wiedemann" tau="1.0" security="1.0" estimation="1.0" emergencyDecel="5.5" apparentDecel="5.0"> 
</vType>

But the vehicle that uses this vType does not move according to the Wiedemann model.

In this picture "EXT" is the vehicle which has been assigned "car1" from above and "Ford1" is the leader of "EXT" which is moving according to a predefined speed via TraCI.

According to my manual calculations, the speed difference (dv) becomes greater than the threshold (sdv) at time step 81, so it is expected that the driver "EXT" should decelerating in the next time step. But as you can see this does not happen and the driver begins to decelerate at time step 89 resulting in the collision. 

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user



_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user


Back to the top