Implementation of airspeed sensor based on venturi pipe into PX4 firmware

[kaklik]

Snímač odvozený z anemometru by nyní bylo potřeba implementovat do PX4 firmware. Což by znamenalo založit nový driver v PX4 (odvozením od současného driveru SPD33), který bude rozšířen o inicializaci toho IMU čipu tak, aby bylo možné číst data přímo z tlakového senzoru. Vyčítat IMU data z IMC-20948 budeme v případě airspeed senzoru řešit později, až bude využit k měření úhlu náběhu.

[roman-dvorak]

Další použití IMU jednotky je jako externí magnetometr při pevném připevnění senzoru.

[kaklik]

V PX4 plánují změny, které se zřejmě týkají tohoto řešení.

[dagar]

Let me know if you have any questions about the direction of drivers in PX4. In general the plan is make the actual drivers as simple as possible, only publishing raw data via uORB. All processing (calibration, filtering, etc) will be done downstream.

[slimonslimon]

@dagar thank you for your interest! Your advice is welcomed!

We are using this PCB in https://github.com/ThunderFly-aerospace/TFSLOT01 so, primarily we need to get a diff pressure sensor to work.

These days we have only a simple (dummy) driver for icm20948 connected over I²C - it only enables bridging of the I2C bus. So we can use the original sdp3xx driver of the diff pressure sensor.

But The question is, how to update the original icm20948 driver (now SPI only, I think) to be able to work on I2C? Or do you have another opinion on implementing this kind of driver? (The drivers for I2C devices on some secondary/slave bus generated by primary device? - or is it so unusual that is better to copy the primary driver into the primary driver like this example ?

[slimonslimon]

I think our PCB not support SPI. @kaklik ?

[kaklik]

I think our PCB does not support SPI. @kaklik ?

Yes, it supports SPI, the TFASPDIMU01 design accept SPI connection also. It is supposed that SPI to be used in some applications requiring high-rate readout like Angle of Attack sensors for example.

[dagar]

These days we have only a simple (dummy) driver for icm20948 connected over I²C - it only enables bridging of the I2C bus. So we can use the original sdp3xx driver of the diff pressure sensor.

But The question is, how to update the original icm20948 driver (now SPI only, I think) to be able to work on I2C? Or do you have another opinion on implementing this kind of driver? (The drivers for I2C devices on some secondary/slave bus generated by primary device? - or is it so unusual that is better to copy the primary driver into the primary driver like this example ?

I was going to do a dummy icm20948 that simply enables i2c passthru because I don't think the IMU is all that useful on I2C. We can still add it if someone wants it though.

[roman-dvorak]

New passthrough driver icm20948_i2c_passthrough from @dagar (https://github.com/ThunderFly-aerospace/PX4Firmware/commit/ad934b49116afd6e615742c108d0ebfa90db05b3) solves the problem of how to connect TFSLOT to PX4 autopilot and how to route SDP3x I2C through ICM20948.

TFASPDIMU01 sensor board module has the default icm20948 address 0x68. The driver assumes address 0x69 (connected addr0 to VCC). Therefore, the address jumper needs to be replaced from position R2 (GND) -> R1(VCC). Then the driver starts itself, including airspeed measurements.

It was tested with the current PX4/master (from QGC).

To complete support of TFSLOT in PX4, we need to solve this issue: https://github.com/PX4/PX4-Autopilot/issues/17576 While solving this issue, I found this bug https://github.com/PX4/PX4-Autopilot/issues/17579

Interestingly, it behaves differently for different i2c ports. Is it known?

[kaklik]

Let me know if you have any questions about the direction of drivers in PX4. In general, the plan is to make the actual drivers as simple as possible, only publishing raw data via uORB. All processing (calibration, filtering, etc) will be done downstream.

Hi @dagar, I have a question about the general approach of drivers - how to handle corrupted transfers on the I²C bus? In the current situation, we experiencing issues with the SDP33 sensor. The airspeed message in every test flight reports NaN after a while. At the beginning of resolving that issue, we supposed it is a hardware issue in TFASPDIMU01 circuit. Therefore we made a new version TFASPDIMU02 with significantly increased physical robustness of the I²C bus.
Unfortunately, the failure behavior of the sensor did not change noticeably.

According to recent measurements made by an oscilloscope, I am almost sure, that situation is not primarily a hardware issue. The SDA and SCL signals are sharp and look good even after the failure of the SDP33 sensor. The PX4 reportedly continues in the reading of the ICM20948 magnetometer. But at the same time as SDP33 failure, the logs contain a "stopping compass use!" message.

To debug the issue I looked into SDP3X driver and I found that the driver never calls an SDP sensor reset. Therefore it is possible that the SDP33 sensor or driver hangs by a single corrupted I²C transfer (which cannot be simply caught by oscilloscope), maybe by a software race condition between multiple sensors on the same bus. But the driver is not capable to resolve that. That corresponds to the behavior that airspeed readout recovers only after the power cycle of the autopilot. Software reboot does not bring up SDP33 back.

[dagar]

Hi @kaklik,

In general I try to have each driver monitor itself and be able to fully reset and reinitialize if anything goes wrong. The SDP3X is a bit of an annoying case because it only responds to a general call reset, which potentially impacts other things on the same bus.

Can you take a look at this PR to see if it helps? https://github.com/PX4/PX4-Autopilot/pull/18085/files#diff-708907b3bad0b6bfa3201cfb9c98397b9d8b287f33c3ce78459f24e3328ed1eaR77

[kaklik]

Hi @kaklik,

In general I try to have each driver monitor itself and be able to fully reset and reinitialize if anything goes wrong. The SDP3X is a bit of an annoying case because it only responds to a general call reset, which potentially impacts other things on the same bus.

Can you take a look at this PR to see if it helps? https://github.com/PX4/PX4-Autopilot/pull/18085/files#diff-708907b3bad0b6bfa3201cfb9c98397b9d8b287f33c3ce78459f24e3328ed1eaR77

Ok, I have performed a simple ground test and I am able to get error from the airspeed sensor:

I made the test with TFASPDIMU02, therefore I have icm20948_i2c_passthrough activated and SDP33 was not alone on the bus, as you expect in the code.

Actually, I do not quickly know where the DEVICE_DEBUG("alone on the bus, issuing general call reset"); message should be issued to check that sensor was actually attempted to reset.

But the sdp3x_airspeed driver is running after the failure:

Could be also stopped and started again:

Unfortunately, the airspeed value does not bring back in QGC again. The new situation is that PX4 software reboot gets the airspeed sensor back into QGC values. It seems to be an improvement. :)

[kaklik]

Recently @roman-dvorak found in log files, that the differentiall_pressure message is actually logged even after airspeed_sensor failure.

The root of the problem probably is that the airspeed sensor is marked as invalid, after a while of flight.

[kaklik]

The main goal of this issue - seamless integration of the sensor to PX4 firmware is already resolved. The sensor is additionally able to work as an external magnetometer. The next features like

• Ability to adopt different possible TFSLOT geometries (airfoils)
• Ability to detect airframe vibrations (flutter)
• Angle of attack sensing

will be resolved in the future, after some demand will develop (if any). The additional discussion is already moved to PX4 PR: https://github.com/PX4/PX4-Autopilot/pull/18593