AP_Proximity: add RPLidar S2, remove memory copy for each measurement

[mirkix]

This PR adds RPLidar S2 support. RPLidar S2 sends out data with 1MBit/s via serial, at the moment the driver copy / move data in the driver internal buffer with each measurement, which result in high MCU load (S2 send up to 32.000 measurements per second). With this PR the driver consume the data direct from serial driver which result in a less MCU load.

For RPLidar S2 set SERIALx_BAUD 1000

Tested with:

• [x] RPLidar A1
• [ ] RPLidar A2
• [ ] RPLidar C1
• [x] RPLidar S1
• [x] RPLidar S2

[rmackay9]

I am so happy to see this!!

[rmackay9]

Good to see that @peterbarker is on the review list 'cuz he's the expert on our serial parsers.

BTW, I think this parser does need to be different from most because it has to process so much data that we don't want to use an intermediate buffer.

Txs again!

[mirkix]

What hardware has this been tested on?

It is tested with the hardware in the description of the PR, A1, S1 and S2

Has this been tested on Rover running at 50Hz?

Has this been tested with injection of a (small!) amount of serial corruption? Under Valgrind?

No. It was tested by unplug and re plug it again while running and it recovers safely.

What benchmarking has this had on real hardware? I would suspect it is faster than the existing code, but I think we need to know. microseconds-spent-doing-this-stuff-per-10-seconds-of-runtime is the sort of number I'm thinking here.

Yes it is much faster then the code before, because we are not copy data in the buffer after each measurement. @peterbarker How can I get the microseconds-spent for this?

I certainly don't hate this.

[peterbarker]

It is tested with the hardware in the description of the PR, A1, S1 and S2

OK, I can test this on A2.

Has this been tested on Rover running at 50Hz? Has this been tested with injection of a (small!) amount of serial corruption? Under Valgrind?

No. It was tested by unplug and re plug it again while running and it recovers safely.

We do need to test it under the conditions I mention.

What benchmarking has this had on real hardware? I would suspect it is faster than the existing code, but I think we need to know. microseconds-spent-doing-this-stuff-per-10-seconds-of-runtime is the sort of number I'm thinking here.

Yes it is much faster then the code before, because we are not copy data in the buffer after each measurement. @peterbarker How can I get the microseconds-spent for this?

Usually you would disable_interrupts_save, grab a uint32_t micros , do your work, get final timestamp, restore interrupts. Search for ENABLE_EKF_TIMING

[rmackay9]

Hi @mirkix @peterbarker,

I wonder what the next steps on this PR are? More changes from @mirkix? more feedback required from @peterbarker?

[rmackay9]

@mirkix,

We discussed this on the dev call this morning and PeterB pointed out two things that we need to do before merging:

1. run it through Valgrind ideally with some serial corruption to ensure there are no buffer overrun issues. It should be possible to do this within SITL. sim_vehicle has an argument for running Valgrind (maybe it's -V?). PeterB also says that there should be a SIM_xxx parameter to turn on some serial corruption
2. test with an A2 (PeterB said he could do this)