Snapshot function for Laser components

[bmegli]

Add possibility to take 360 degree snapshots from lasers to simple csv files.

For now:

• in local reference frame
• stationary (not interpolated for movement, plain laser data)
• to be taken as configured series of consecutive snapshots (for SD calculation)
• button in UI "snapshot"
• data format in row, distance0, distance1, ..., distance359
• mockup value beyond range when invalid data flag is set
• saved to "SNAPSHOT" directory

[bmegli]

Already working in snapshot branch but:

• triggering snapshot during taking another snapshot is not thread safe
• when laser communication is failing snapshot data may be corrupted (e.g. mixed from 2 scans)

This is good enough for what I need now.

[bmegli]

Now I need gyroscope/odometry corrected snapshots (non-stationary, during movement)

This can be either:

• in global reference frame
• in local reference frame, referenced anew each lidar revolution

Global reference frame seems easier to implement now.

[bmegli]

Implemented in #50 including:

• csv with row format x1;y1;z1;...;x360;y360;z360
• global (corrected)/local (not corrected) reference frame depending on Laser plot type setting
• thread safe triggering
• failing laser communication handled correctly (incomplete scans should be ignored)
• readings exceeding distance marked as invalid
• saved to SNAPSHOT directory

[bmegli]

This implementation still can result in scans from 2 revolultions mixed.

The reasons may be following:

• odometry results are gathered separetly and laser readings are corrected as they arrive, this has to be taken into account when detecting scan "end"
• occasionally udp packet may not arrive or arrive not in correct time order, this can be taken into account by marking readings as invalid when starting new revolution and/or keepeing track of next expected angle reading

In 960 scans taken around 3 were corrupted this way. This has to be fixed now, it will be extremely difficult to spot when scanning continously.

[bmegli]

Ok, this is how problem manifests (in snapshots, it doesn't affect the main mapping engine)

This is what should be seen (this is next snapshot):

This is what I get:

So it seems that one or 2 UDP packets have not yet been converted to global reference frame when dumping snapshot

[bmegli]

Ok, I believe this is what is happening:

1. Laser packet arrives
2. It's calculated in local reference frame
3. Odometry data has not yet arrived, so it's marked as pending for local2global transform
4. Second laser packet has arrived
5. Odometry data for first packet still hasn't arrived
6. The second packet local-global transform sets pending state to false
7. The second packet eventually gets transformed but the first was left in local reference frame

The reason this happens is timing - we are not on real time OS and always some lag (even unlikely) is possible.

[bmegli]

I can either:

• trash the first packet if this happens (easy but leaves "hole" in scan)
• join both packets data as pending for transform (difficult, has to handle circular arithmetic in pending packets)

[bmegli]

The second aproach taken:

• on receiving packet first try to translate and push pending data
• calculate packet in local reference frame
• calculate packet in global reference frame, join with pending data if necessary
  • if pending exceeds 360 discard excess data
• if calculated in global reference frame push everything that was calculated

As a side effect now also thread internal/thread shared data push has to be circular