add settling time on sensor start-up

[ASM3]

Add settling time after setting adis16448 registers

[LorenzMeier]

This delays the whole system. Instead it would be appropriate to add functionality to back off in the next call / schedule the following call later.

[dagar]

Would further delaying the first cycle resolve the problem? https://github.com/ASM3/Firmware/blob/79bdf007741750c8a78b56e8c2a0b571d0b3ecff/src/drivers/imu/adis16448/adis16448.cpp#L1358

[ASM3]

Obviously, this is the purpose. We want to prevent the uc to perform any kind of SPI writing cycle during this epoch, what potentially could mess up the adis16448 registers (happened in very rare cases). If this delay during boot-up sequence is so critical for the system another solution can potentially be figured out.

[ASM3]

BTW, the main purpose of this functionality is to set all units with the default calibration values so that the system can align with a standard configuration. One can decide that it is up to the user to perform this step and then this functionality can be completely removed from the start up sequence.

[ASM3]

The restore factory calibration functionality is unnecessary on the boot-up sequence and therefore removed

[philipoe]

@dagar @LorenzMeier To explain a bit: We noticed that the _set_factory_default() functionality can in rare cases (ca 5% of all bootups of the ADIS driver + Pixhawk) put the ADIS in a faulty state where it delivers updates too slowly (causing a "GYRO: STALE" warning by PX4). The reason is that the set_factory_default() call requires (as per the Analog Devices datasheet) a certain time period without any communication on the SPI bus, but apparently something within PX4 is writing stuff to the SPI bus (@ASM3 measured this using a logic analyzer). The set_factory_default() call is however not really necessary and was just added in case a user messes up the ADIS configuration, but we at ASL have actually never needed that call even in 4 years of using ~5 platforms with the ADIS. Therefore, it is now removed, and testing has shown that with the fix in this PR everything works 100% reliably (tested during ~50 bootups) now.