Hello! I think I've found some puzzling areas in the metric calculation after the simulation ends. What I'm discussing is the extract_ego_jerk function in nuplan/planning/metrics/utils/state_extractors.py.
First Sample
As shown in my schematic, the green part represents the calculated jerk, which is the function processed by approximate_derivatives; the orange part, ego_acceleration_diff, is the result I obtained directly using np.diff. Since the timestamps x are almost an arithmetic sequence (with a common difference very close to 0.1s), these two should theoretically be similar in shape (even though there may be differences in absolute values due to division by 0.1). However, in reality, there is a high jump in the jerk at the end, which is very inconsistent with the trend of the orange curve. Simply looking at the original acceleration curve, it's hard to guess why there is such a huge jerk at the end. I'm considering whether it is indeed reasonable to use a function like savgol_filter to process the curve? This sample was not carefully selected; it was merely the first sample I ran randomly while trying to understand the method of calculating jerk.
Second Sample
The second picture shows the second sample, which also has some perplexing parts, such as a very small fluctuation in acceleration observed at the beginning of the curve, but a large peak in jerk.
Third Sample
To test the effect of jerk, I adjusted the acceleration to a very large value (deceleration -90m/s^2, acceleration 52m/s^2), and then alternately performed several strong accelerations and several strong decelerations in a loop. I guess the jerk should be very large in this extreme situation. But when I drew the jerk curve (in the third figure), I found that the jerk was very small (even not exceeding 1 in the middle), fluctuating well below the official threshold (the official magnitude range is around 8). I'm wondering whether it is truly reasonable to calculate jerk this way? Since the time interval is 0.1, from the graph, it can be seen that the jerk estimated by np.diff (the orange line) should be multiplied by 10, which looks more like a reasonable value.
Hello! I think I've found some puzzling areas in the metric calculation after the simulation ends. What I'm discussing is the extract_ego_jerk function in nuplan/planning/metrics/utils/state_extractors.py.
First Sample As shown in my schematic, the green part represents the calculated jerk, which is the function processed by approximate_derivatives; the orange part, ego_acceleration_diff, is the result I obtained directly using np.diff. Since the timestamps x are almost an arithmetic sequence (with a common difference very close to 0.1s), these two should theoretically be similar in shape (even though there may be differences in absolute values due to division by 0.1). However, in reality, there is a high jump in the jerk at the end, which is very inconsistent with the trend of the orange curve. Simply looking at the original acceleration curve, it's hard to guess why there is such a huge jerk at the end. I'm considering whether it is indeed reasonable to use a function like savgol_filter to process the curve? This sample was not carefully selected; it was merely the first sample I ran randomly while trying to understand the method of calculating jerk.
Second Sample The second picture shows the second sample, which also has some perplexing parts, such as a very small fluctuation in acceleration observed at the beginning of the curve, but a large peak in jerk.
Third Sample To test the effect of jerk, I adjusted the acceleration to a very large value (deceleration -90m/s^2, acceleration 52m/s^2), and then alternately performed several strong accelerations and several strong decelerations in a loop. I guess the jerk should be very large in this extreme situation. But when I drew the jerk curve (in the third figure), I found that the jerk was very small (even not exceeding 1 in the middle), fluctuating well below the official threshold (the official magnitude range is around 8). I'm wondering whether it is truly reasonable to calculate jerk this way? Since the time interval is 0.1, from the graph, it can be seen that the jerk estimated by np.diff (the orange line) should be multiplied by 10, which looks more like a reasonable value.