Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why the input of model is speed? #26

Open
JackokieZhao opened this issue Dec 8, 2022 · 2 comments
Open

Why the input of model is speed? #26

JackokieZhao opened this issue Dec 8, 2022 · 2 comments

Comments

@JackokieZhao
Copy link

JackokieZhao commented Dec 8, 2022

Hi, thanks for the open source of your greate work. There remains a detail that I cannot understand, so I would appreciate it if you can explain it to be.
In my opinion, the line 260 in file 'baselineutils.py' means that the [0-2] columns in dim 2 denotes pedestrain positions while [2:4] columns in dim 2 denotes the speed of pedestrain.

inp_norm=np.concatenate((inp_te_np,inp_speed),2)
However, the input of model are [2:4] in dim 2, which means the input are speeds rather than positions of pedestrain.
inp=(batch['src'][:,1:,2:4].to(device)-mean.to(device))/std.to(device)
pred=model(inp, dec_inp, src_att, trg_att)
I don't know whether there is any mistick for the unserstanding, could you please expalin it to me ?

@BYZANTINE26
Copy link

Hi @JackokieZhao, you are getting it correct, the model is taking the speed as input and I guess it's not a mistake, I experimented with both cases positions and speeds and I found model actually worked better with speeds, and you can look at it this way - speed is just distance when looked for unit time.

I hope I'm able to resolve your doubt.

@JackokieZhao
Copy link
Author

JackokieZhao commented Dec 21, 2022

Hi @JackokieZhao, you are getting it correct, the model is taking the speed as input and I guess it's not a mistake, I experimented with both cases positions and speeds and I found model actually worked better with speeds, and you can look at it this way - speed is just distance when looked for unit time.

I hope I'm able to resolve your doubt.

Thanks for your answer !
But, if this is the case, I think there are some details on the metrics need to be further determine.

In my opinion, the ADE of the positions dosen't equal the ADE of speed.

We assume there are three positions p1, p2, p3, and corresponding speed v1, v2 (prediction results p1_, p2_, p3_, v1_, v2_).

In general, the ADE of positions should be mean(|p1 - p1_| + |p2 - p2_| + |p3 - p3_|).
However, the speed ADE are mean(|v1 - v1_| + |v2 - v2_|).
For the first speed error, it corresponds the position ADE: |v1 - v1_| == |p2 - p2_|.
What's import is that |v2 - v2_| dose not corresponding to |p3 - p3_|, because it still contains the prediction error of v1_.
In other words, we will acquire the prediction of
p3_ == p1 + v1_ * t + v2_ * t
if we transform the speed prediction to the trajectory prediction.
Here, the position errors are
|p3 - p3_| = |p3 - (p1 + v1_ * t + v2_ * t)| = |v1 * t + v2 * t - v1_ * t - v2_ * t| = |(v1 - v1_) + (v2 - v2)| * t.
Therefore, in my opinion, the metrics of speed ADE and FDE are not equal to positions ADE and FDE.

And, I think this is the reason why the performance of position prediction is much lower than speed prediction.

This is just a academic talk, and I am not aggressive or hostile in any way.
And, there might some mistakes for my understanding.

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants