AP_Rangefinder: fix override in constructor

[khancyr]

this was catch by coverage.
The issue is that we are calling virtual function in the constructor from the base class, therefore it got no idea of the child class and always use the base class function.
Impact :

• rx_bufsize() on ulanding,
• initial_baudrate() in several backend
  This happen in SITL, I haven't test on STM hardware.

Downside is that it costs a little of flash : around 100bytes as some functions are now used and the not removed on compilation anymore.
I got another patch on rangefinder that will make us save the same amount of flash so it should be good
This is totally tested by the autotest

[peterbarker]

Good find! But how about a uint8_t _serial_instance on AP_Rangefinder_Backend_Serial` instead?

[tridge]

@peterbarker please merge when you are OK with it

[peterbarker]

Merged,thanks!

[rmackay9]

Let's think about whether these fixes need back porting to 4.1 or not.. I don't really understand how significant this is.. if it meant we used the wrong baud rate for the lightware lw20 lidars then that would certainly mean it is worth backporting.

[peterbarker]

On Thu, 26 Aug 2021, Randy Mackay wrote: Let's think about whether these fixes need back porting to 4.1 or not.. I don't really understand how significant this is.. if it meant we used the wrong baud rate for the lightware lw20 lidars then that would certainly mean it is worth backporting.

I wouldn't backport. It's an initialisation thing and it hasn't bitten us for several versions. Let it cook in master.

[rmackay9]

We should backport this fix to 4.1 because it came up in this user report that says we've broken the uLanding driver in 4.1 but this PR fixes it. https://discuss.ardupilot.org/t/ainteins-us-d1-radar-not-working-with-arducopter-4-1-beta/75414/4