Trajectory coordinate transformation causes the trajectory to be unsmooth

[suannairen]

Hello, I found that when processing the past trajectory of the ego vehicle, after the global coordinates are converted into local coordinates, the trajectory will become very unsmooth, but the real trajectory in the future will be smooth after this transformation. I found that when converting the past and future global coordinates, using two different functions resulted in different results.
They are convert_absolute_to_relative_poses, convert_absolute_quantities_to_relative (there may be problems)
Since the trajectory of the agent vehicle is also processed using convert_absolute_quantities_to_relative, this trajectory is also not smooth.
Below is the code diagram and the visualization you provided, the non-smooth trajectory that exists

How to solve this problem

[MCZhi]

Hello @suannairen, thank you for bringing this to my attention. Since I am using the functions provided by the nuPlan devkit, I am not exactly sure why the noise is occurring. However, I believe that the lack of smoothness in the trajectories should not negatively affect the network's performance. Nevertheless, if you still wish to obtain smoother trajectories, you can try using the convert_absolute_to_relative_poses function with some minor adjustments.

[DanielDauner]

I have seen this non-smoothness in nuPlan before, often due to floating-point precision. When transforming from global to local coordinates (or vice versa), it's best to use float64 (aka double precision). The internal functions of nuPlan sometimes don't consider that. The less smooth trajectories should not really affect performance, though.

[suannairen]

@

你好@suannairen，谢谢您让我注意到这一点。由于我使用 nuPlan devkit 提供的功能，因此我不确定为什么会出现噪音。但是，我相信欠缺平滑度不应该对网络的性能产生负面影响。因此，如果您仍然希望获得更平滑的体重，您可以尝试使用该convert_absolute_to_relative_poses功能进行一些简短的调整。

Thank you!

[suannairen]

我以前在nuPlan中见过这种不平滑的情况，通常是由于浮点精度造成的。当从全局坐标转换为局部坐标（或反之亦然）时，最好使用float64（也称为双精度）。 nuPlan 的内部函数有时不考虑这一点。不过，不太平滑的计算不会真正影响性能。

Thank you!