AP_RangeFinder: initial support for the DFRobot07 lidar

[landswellsong]

Support for DFRobot07 which is also sold as VSemi Atom

Documentation: https://dfimg.dfrobot.com/nobody/wiki/1840a7b7b14e02f3566e0cef5b51e9ba.pdf

Implementation caveats:

• UART only for now;
• 50 ms fixed data rate, can be synced up with update() but it involves waiting for the result since the sensor does take a bit of time to process commands;
• there are a bunch of values coming from the sensor that don't have a clear mapping to anything in AP so they are ignored for now, although potentially can be used to estimate the signal quality;

Code quality and style questions that I'd love to have a senior developer feedback:

• Should the initialization be done like I did in update() or should I rather have overriden init_serial? Given how sensor works it would mean the thread that runs it needs to be waiting for a while.
• Is the offset macros fine or should I rather make structures/unions for a more clear picture of the data layout?
• The CRC32 in the sensor seems to work in opposite bit order reflection mode in comparison to the AP implementation (and frankly any standard implementation). Is it okay to put extra CRC32 utils hidden like I did or should I move that to AP_Math / optimize it etc?

[landswellsong]

SITL test in the room conditions:

[landswellsong]

https://github.com/ArduPilot/ardupilot/actions/runs/11257361975/job/31301422237?pr=28366#step:9:1282

Right, guess I'll rewrite the offset part to work with ARM and test that locally too.

[landswellsong]

Resolved all the issues, removed any sleeping whatsoever. Will test on the weekend on the sensor.

[landswellsong]

Tested the code against a real device, corrected a few mistakes. Works alright indoors. Outdoors it seem to be getting shorter distances alright, but when pointed to the horizon it apparently times out while waiting for the laser bounce and thus the message rate drops dramatically, ultimately spamming 65536 outputs.

Will also test on a plane on whether this is suitable for landing, but for indoor use I'd say it's ready to be used.

[Hwurzburg]

@landswellsong status?

[landswellsong]

@Hwurzburg flight-testing over this weekend. SITL operation stable and as expected.

[landswellsong]

@Hwurzburg sorry took me a while to get airborne. I have 2 news about the code in this PR:

1. It's operational as intended. No holes in the log, no lock ups, no crashes. Gives out a 65.535 m reading when out of range which is very far from it's practical ceiling of 10 m so easy to set the bad data filter with _MAX_CM. I caught a bunch of near-zero readings but I was literally flying inside a cloud so I guess that's expected. This, for example, is landing with a small bounce from the ground.
2. Now the bad news: It has just been discontinued by the manufacturer

I'll be keeping the patch for myself until I crash all of the units I've bought, but very unsure if this needs to be merged. Basically dead code since it's not a good recommendation for new builds.

If this is still somehow a good idea to keep it, I can rebase and update. What do you think?

[Hwurzburg]

Since its not made, probably no reason to keep this active....thanks

[peterbarker]

Thanks anyway, @landswellsong