Confusion about the platform trajectory

[xjy11]

What I want to do is restore the scan angle of the real data since it may influence the shape of the waveform. The trajectory of the ALS platform provided by the .trj file includes GPSTime, x, y, z, roll, pitch, and yaw. Is that possible to reproduce the trajectory in the simulation with a defined .trj file? I see there is a demo named als_interpolated_trajectory but the simulated point clouds are different from the linearpath platform. I am not clear about the interpolation here.

Thank you all very much.

[han16nah]

Dear @xjy11 Our new "interpolated trajectory" feature should allow exactly this: reproducing a survey based on a real trajectory file, no matter if it's a more or less straight path or a curve. So in general, it should allow reproducing your real survey more closely, given that you also define the other sensor settings (scan angle, pulse frequency, etc.).

However, the feature is still experimental and under development. You can follow the progress in #174. We just tested the interpolated trajectory with a real trajectory of one of our datasets and noticed some problems, see #227. We try to take care of this as soon as possible and will then provide a working example for you.

It is always a great help for our development to have test data. If you want to provide your trajectory and sceneparts, the survey and scene XMLs, and potentially also the expected point cloud output (your real point clouds), we would greatly appreciate this. This is the quickest way to find a solution for your specific problem.

Best regards Hannah

[xjy11]

Dear @han16nah Thank you very much for responding so quickly.

I've been following the progress in #174, and it is a great way to replicate the trajectory in a real survey as follows. input trajectory:

HEADER:,"t","y","x","z","roll","pitch","yaw"

88787.0000,5016583.6452,475811.1694,1018.4615,1.621420,-5.432309,97.445382 88787.1000,5016584.0419,475807.1045,1018.4789,1.548257,-5.281543,97.389681 88787.2000,5016584.4335,475803.0367,1018.5019,1.447079,-5.091683,97.344875 88787.3000,5016584.8224,475798.9649,1018.5297,1.327485,-4.898112,97.301682 88787.4000,5016585.2089,475794.8888,1018.5604,1.213258,-4.696064,97.250023 88787.5000,5016585.5930,475790.8076,1018.5914,1.110904,-4.491066,97.194218 88787.6000,5016585.9777,475786.7220,1018.6228,0.996056,-4.286872,97.139318 88787.7000,5016586.3587,475782.6322,1018.6508,0.858413,-4.102822,97.082374 ...

output trajectory:

HEADER:,"x","y","z","t","roll","pitch","yaw"

475811.1694 5016583.6452 1018.4615 88787.0000 1.6214 -5.4323 97.4454 475807.1041 5016584.0419 1018.4789 88787.1000 1.5482 -5.2815 97.3897 475803.0359 5016584.4336 1018.5019 88787.2000 1.4471 -5.0916 97.3449 475798.9637 5016584.8225 1018.5297 88787.3000 1.3275 -4.8981 97.3017 475794.8872 5016585.2090 1018.5604 88787.4000 1.2132 -4.6960 97.2500 475790.8057 5016585.5932 1018.5914 88787.5000 1.1108 -4.4910 97.1942 475786.7197 5016585.9779 1018.6228 88787.6000 0.9960 -4.2868 97.1393 475782.6295 5016586.3590 1018.6508 88787.7000 0.8583 -4.1027 97.0823 ...

And there's also a new issue. With the real trajectory and the off-nadir forest scene, there is no simulated point cloud output. I can confirm that the scene is in the correct location, hence the issue may be due to the trajectory characteristics. As shown by the coordinates in the real trajectory, the aircraft climbs gradually from the x-positive to the x-negative axis. However, the corresponding pitch is negative, and the yaw is around 90 degrees, counting clockwise from the south. So may I ask what is the exact definition of roll, pitch, and yaw in the interpolated trajectory mode? Is this the same as https://opals.geo.tuwien.ac.at/html/stable/ModuleDirectGeoref.html#dirgeoref_trajectory_file? If that's the case, maybe I can first modify the values in the real trajectory to make sure the ray can be casted to the right scene.

Thank you so much for your assistance.

[lwiniwar]

Dear @xjy11, thank you for providing this example. As you see in the output, HELIOS++ tries to replicate the position and attitute of the input trajectory as close as possible. When thinking of an airplane, it might make sense to calculate the yaw from two subsequent points, but this is not a strict limit. For example, winds may shift the airplane perpendicular to its heading direction, while the yaw angle (and therefore the orientation of the laser scanner's scanning plane) stays the same. When you think of ULS systems or helicopters, this becomes even more important, as they may sway to the side (accelerating sidewards by tilting). Having said that, I see that the output trajectory above perfectly replicates the input trajectory. Now, for the meaning of the angles: The 'yaw' angle starts at 0 degrees "north" (i.e., parallel to the secondary axis/y-axis) and increases mathematically positive (counterclockwise), so 90 degrees is due west. This is inverse to the common "yaw" angle as provided as (magnetic) heading. The 'pitch' angle is positive if the platform' nose (facing in yaw direction) goes up, and negative if it goes down. The 'roll' angle is positive if the platform's right wing (or arm, again with respect to the yaw) goes up, and negative if it goes down. You can also see this in the plots in the wiki: https://github.com/3dgeo-heidelberg/helios/wiki/Platforms#dynamic-platforms (scroll down to "multicopter"). I find visualizing the trajectory file by coloring the angles helps a lot. If you find behaviour that is not fitting this description, please let us know as it might be a bug and this feature is still very much in development.

Best, Lukas

[han16nah]

Dear @xjy11 please see my update posted on #227 As @lwiniwar stated, the trajectory output and behaviour is perfectly fine. The issue is that you are probably doing and airborne simulation and expecting the scanner to point downwards and scan left to right. This is applied when using e.g. the platform data\platforms.xml#sr22 due to the rotations defined in the scannerMount. We are currently lacking this option in the interpolated trajectory implementation. We will keep you posted once we have an update about this!

Best, Hannah

[xjy11]

Dear @han16nah and @lwiniwar Thank you for explaining. Now I understand that a minor change in airplane attitude may not be required to replicate the angle of the emitted pulse. So I'll try to define parameters like scannerMount to match the real ray transfer direction. Looking forward to your update, and please let me know if you require any further tests or examples.

[han16nah]

There is now the basePlatform argument, which allows using the scannerMount defined for the respective platform in the platform.xml. We will therefore close this issue.