Osclillating scanner does not use acceleration

[lwiniwar]

Oscillating scanners should slow down (decrease) the angular step width at the extremes of the swath. Currently, the change in angle is calculated in OscillatingMirrorBeamDeflector::currentScanLinePulse (line 56):

int bla = std::min(currentScanLinePulse, cached_pulsesPerScanline / 2) - std::max(0, currentScanLinePulse - cached_pulsesPerScanline / 2);

state_currentBeamAngle_rad = -this->cfg_setting_scanAngle_rad + cached_angleBetweenPulses_rad * bla;

[albertoesmp]

This issue has been addressed. Please, don't close the issue until new implementation has been exhaustively tested because this is a significative update.

[han16nah]

@albertoesmp I tested the implementation and while the pattern looks realistic now, the simulated swath width is too small.

(Altitude a.g.l: 1000 m, scan angle: 20°, expected swath width: ~728 m, actual swath width: ~425 m.)

This figure shows a simulated wath with the old implementation (correct swath width) in red and the new implementation in blue

[lwiniwar]

Some python code how to solve for the turning points is included here: oscillating.zip

Results look like this:

Note the name of variables used in the script:

[albertoesmp]

This issue has been solved in pull request https://github.com/3dgeo-heidelberg/helios/pull/171

It has not been merged yet because there is a test case which is not passed. But I think it is because changing the OscillatingMirrorBeamDeflector changed the size of the output point cloud. Please, confirm it and merge the pull request if it is okay for you too.

The output point cloud with new implementation looks like this:

The plots monitoring simulation look like this: