SSM device: questionable TTC and PET values #5527
Comments
|
Some indication from the "ssm.trajectories" output: TTC=0 happens when both vehicles have come to a standstill (velocity vector -0.000,-0.000). For most time steps, "NA" is returned, but 0 for others. All in all looks like a numerical problem. |
|
Update:
|
|
We're getting closer: It seems SSM device does not consider split connections properly when calculating the distance. In my example, the gap between two vehicles drops sharply when the first touches the ped crossing. The variable egoDistToConflictLane stays at 0 for an ego vehicle waiting at the traffic light upstream. |
|
Snippet of the SSM DEBUG output showing the last timestep with NA value and the first with TTC=0. Veh. Pkw1.4 wants to follow Pkw1.2 and turn right but stops at the red signal. Pkw1.2 reaches the stopping position at the pedestrian crossing. |
|
@m-kro I have trouble reproducing the situation above. When calling manual.sumofg with version 1.1, 1.2 or the latest development version, the vehicles are far past the junction at time 135. Any idea why that could be? |
|
Sorry, I have used a slightly different configuration (see below) for that output. Essentially, the traffic demand from other than the northern aproach has been deleted to concentrate on the described error case. |
|
I'm not confident enough to close this issue as I'm still unfamiliar with the code base but the reported situation should be fixed now. |
Signed-off-by: m-kro <m.barthauer@t-online.de>
|
You didn't consider the inverse vehicle relation (both are equipped with the SSM device). I will submit a pull request shortly. |
|
There is at least one crossing situation with invalid TTC/PET, too. I'll try to provide you with a reproducible example. Just what happens: The foe vehicle turns left and stops in front of the ped crossing there. The ego vehicle arrives from the opposite direction and passes behind the foe vehicle. However, the conflict position is set to the front of the foe vehicle. |
|
Have a look at the following conflict using the sumocfg from the first post in this thread. |
|
Reminder for another case observable within the same simulation: |
|
Current development versions now stop with an invalid operator exception: |
|
In my example, two conflicts are detected during the same simulation step and are closed after a while. When they are to be sorted in the priority_queue type data structure, the invalid operator error occurs. To our knowledge, the custom compare function provided by the SSM device does not fulfil the requirements listed at C++ reference, as explained in #5387 . |
|
Changing the definition of Encounter::compare from |
|
That will reverse the order of items that have the same value. Though this does not mean that the old code did not have a bug. #include <iostream>
#include <sstream>
#include <queue>
using namespace std;
struct S { int idx; int val; };
int main()
{
auto print = [](auto q) {
stringstream ss;
cout << "idx=";
while(!q.empty()){
cout << q.top().idx;
ss << q.top().val;
q.pop();
}
cout << "\nval=" << ss.str() << endl;
};
vector<int> v = {1,2,3,4,3,6,3,8,3};
auto cmp1 = [](S l, S r) { return l.val > r.val; };
priority_queue<S, vector<S>, decltype(cmp1)> q1(cmp1);
auto cmp2 = [](S l, S r) { return l.val >= r.val; };
priority_queue<S, vector<S>, decltype(cmp2)> q2(cmp2);
for (int i=0; i < v.size(); ++i){
S tmp{i, v[i]};
q1.push(tmp);
q2.push(tmp);
}
cout << ">" << endl;
print(q1);
cout << ">=" << endl;
print(q2);
}will produce |
|
I think the order of elements with the same begin value should not matter here. |
|
Debug output from the simulation linked in the first post. An invalid TTC=0 is calculated for the ego vehicle Pkw.21.7 turning left. Only the relevant lines (last time step before and first time step with TTC=0) are displayed.
|
|
Anyhow, the already passed encounter is classified again as "CROSSING_FOLLOWER". Still it is quite difficult to say where this standard case should be catched... |
|
Do you think you could manage to recreate the problematic situation with fewer vehicles? That would really help in debugging. |
|
Well I will try. But I fear that the number of vehicles may be a necessary condition for this to happen. |
|
I found one bug related to the distance computation. The debug output looks more sensible now but I still don't see the encounter in the xml output. |
|
My mistake, I did not think to increase the ttc treshold sufficiently. Now I get a value of 1.949 for the conflict between Pkw.33.4 and Pkw.25.4 (at time 1996.6) |
|
I can confirm that. Thank you for your help! Nonetheless, I think I will explore some more runs to see whether there are more seldom error cases. It still frightens me that my debug built didn't exhibit the same behaviour... |
|
And I was too fast. The collision notice in the SSM log has reappeared after some simulation runs of the same sumocfg :-( Maybe still some memory issue? |
|
I have compared the logged speeds and positions for this conflict between the most recent DLR built (producing minTTC=0 at time 2002.3s) and my own debug built (minTTC=2.585s at 1996.9s). Even the ego speed and position data is slightly different from the beginning of the conflict. |
|
I did notice conflict outputs change their order so I can confirm there is non-determinism somewhere. |
|
Yes, I also got different results for the current DLR build. That's why I first thought that the error went away when this morning I ran the first simulation on my computer. When I ran it again just to be sure, TTC=0 reappeared. All following runs also feature TTC=0. On the other hand, I managed to run it 3 times on another computer with more RAM and every time got your TTC value (1.949s). |
|
@namdre: You asked for a scenario with less vehicles. At least, I can indicate one with a shorter duration: Please use seed 7. There is a conflict |
|
The last conflict (Pkw.9.1 vs. Pkw1.3) is due to a limitation in the SSM design: A "merging" conflict is re-classified as "following" as early as the front of the leader vehicle reaches the target lane. However, the relative back position of the leader and the position of the follower are combined into the conflict distance which influences TTC (see source). It is forgotten that the vehicles do not travel along the same route yet, given that they are still (partially) on different connections. |
|
What do you think about changing the design so that the reclassification only happens when the leader has completely left the intersection? |
|
I'm already looking into that. Is there any easy way to check this? Note that in this message, "leader" refers to the vehicle reaching the merging area first, "follower" to the second vehicle. Some thoughts on how to check the vehicle positions more thoroughly: Requirements:
Conditions:
Implementation:
|
|
Next problem: TTC << 1s for vehicles at big distances like below: |
|
Looks again like the internal data structures of the SSM device get corrupted. The error from the previous post happens because the estimated conflict times are invalid at the time of TTC calculation - which they shouldn't for crossing conflicts... |
|
The last problem is caused by the design of the FoeInfo data structure:
Strangely enough, the crossing conflict is detected at least once and then overwrites the non-conflict encounter types chosen in following time steps. For this reason, estimated conflict times are not initialised. |
|
Thanks for diving into this mess. I won't have time to do anything about it for at least the next two weeks though as I'm going offline (vacation). |
|
After some more time, I think it is a matter of how the scan is implemented. Currently, all foe vehicles on a junction get assigned the same ego conflict lane on the same junction. This is misleading for vehicles which have no conflict with the ego vehicle there but at another place. Both locations are marked in yellow here:
EDIT: The new scan order can be reviewed in my fork... |
|
|
I also get odd values:
|
|
The negative tgap values were fixed yesterday via #7844 |
|
I must admit I did not read everything but can this be closed? |
|
Yes. Anyone still seeing questionable values should open up a new issue. |
I evaluate conflict situations at a signalized intersection using the SSM device. Recently I have come across some strange values for TTC and PET measures I don't think they are intended:
Both phenomenons can be observed in the same example simulation attached...
results_K048_Festzeit_Nullfall1_ssm.zip
The text was updated successfully, but these errors were encountered: