Interpolated trajectory fails when using real trajectory file

[han16nah]

The problem Simulating a surveys using a real trajectory file (from an ALS flight) with the format

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

in the interpolated mode fails.

How to reproduce Explain in detail how to reproduce the bug. You can structure the individual steps as a numbered list, like below.

1. Take real trajectory and save as comma separated ASCII file.
2. Create corresponding scene from real point cloud (xyzloader)
3. Create survey using this trajectory and scene

Survey, scene, scenepart and trajectory can be found here: https://heibox.uni-heidelberg.de/d/f7d4d07107dd4e1dbf31/

Execute the survey with

run\helios data\surveys\trajectory_demo.xml

Expected behavior

A simulation is executed for which the trajectory output is similar to the input trajectory. The point cloud output should show a forest plot (with a visible voxel structure, because 0.5 m voxels are used).

Actual behavior The survey does not stop and produces no point cloud output. The counter shows percentages > 100 %. A trajectory output is written but coordinates seem off (10-digit numbers for x and y, y is negative, z-values seem okay but are all the same, time does not correspond with time in input trajectory, pitch and yaw seem to be off).

3676529571.0739 -2037480680.0767 955.5500 367965.000000000 -80.9375 7.9072 203.0997
3676529993.6995 -2037480914.9462 955.5500 367965.054000169 -80.9375 -21.1896 199.2586
3676530458.3790 -2037481173.1866 955.5500 367965.113373688 -80.9375 -53.1818 195.0354
3676530928.1195 -2037481434.2397 955.5500 367965.173393875 -80.9375 -85.5223 190.7661
3676531397.8600 -2037481695.2927 955.5500 367965.233414063 99.0625 -62.1371 6.4968
3676531867.6005 -2037481956.3458 955.5500 367965.293434250 99.0625 -29.7965 2.2276
3676532337.3410 -2037482217.3988 955.5500 367965.353454438 99.0625 2.5440 357.9583
3676532807.0816 -2037482478.4519 955.5500 367965.413474625 99.0625 34.8846 353.6890
3676533276.8221 -2037482739.5049 955.5500 367965.473494813 99.0625 67.2252 349.4198
3676533746.5626 -2037483000.5580 955.5500 367965.533515001 -80.9375 80.4342 165.1505

Your environment (please complete the following information):

• OS: Windows 10
• HELIOS++/pyhelios version (or Git revision) that exhibits the issue: 1.1.0 (built from 2022/05/04)

Can you identify the location in the source code where the problem exists? (Optional)

Assumption: The problem is that it passes through the point too fast so the waypoint check is never passed because it skips from one extreme to the other (@albertoesmp ).

Additional context (Optional) Add any other context about the problem here.

[han16nah]

The trajectory output has been fixed with 13c55a1fe7f13ca4e9173289185aa98f4297259e

The survey still produces no output. But there is a very simple explanation for this.

Explanation In the waypoint-mode, we use the platform parameter to specify a platform. In my case, I would use data\platforms.xml#sr22 This platform has two rotations applied in the scanner Mount, -90° around the x axis and 90° around the z axis, so that the scanner looks downwards and scans left to right.

With the interpolated platform, we use the platform parameter to specify the "interpolated" mode. No other platform configurations are applied. Hence, the scanner scans forward up and down by default.

Proposed solution Keep the platform argument to specify a platform from the platform.xml (this way, all platforms are accessible as usual). Add an additional parameter in the <survey> tag of the survey.xml for specifying interpolated mode.

@albertoesmp

[han16nah]

This has been solved and a basePlatform parameter was added. Remaining TO DOs:

• [x] update documentation in Wiki
• [x] Add/update demo survey (and reference in Wiki)

[han16nah]

@albertoesmp Another feature idea: Add a flag, sth. like --always_interpolate_traj The purpose is to control trajectory files with bigger gaps in the GPSTime. These may occur, because some data is missing and was not recorded. Or it exists, because the trajectory is a merge of several flight missions. Currently, the simulation would interpolate between the gaps, which might not be what the user wants.

When there is a GPSTime gap, the --always_interpolate_traj flag should act like this:

0 (default) -> Throw an error / exception. This way we make sure the user understands what is going on. 1 -> Linear interpolation

If the user doesn't care and just want the simulation to run, the linear interpolation is already implemented, and it is what the platform is expected to do when the flag is enabled. If the user wants to have a time-jump, the exception can show the time frontiers of the gap so it will be quite straight forward to configure tStart and tEnd. With this approach, there is no need for extra parameters but a single flag, and it should be easy for the user to understand what is going on and decide the best approach.

[han16nah]

Closing this, as it should be fixed with basePlatform argument and is documented in the Wiki. --always_interpolate_traj does not seem to be necessary (for now)

Further comments on development of interpolated trajectories can be added to the initial issue #174