Allow negative differential pressure if parameter enabled

[AWheats]

Solved Problem

If pressure tubes for static/dynamic pressure are not accessible without disassembling the aircraft, it may be preferable to users to set a parameter rather than redo the pipe routing. This change enables this to happen for all supported pressure sensors by setting SENS_DIFF_PRES_REV to 1.

Changelog Entry

For release notes:

New parameter: SENS_DIFF_PRES_REV
Documentation: Need to amend airspeed calibration to state that SENS_DIFF_PRES_REV can be used: https://docs.px4.io/main/en/config/airspeed.html#airspeed-calibration

Alternatives

Could change the UORB message itself rather than the sensors, but this would require changing both the publish and the subscribe functions.

Test coverage

• Unit/integration test:
• Tested on SITL to check parameter appears in param list and is stored in non volatile
• Tested on Pixhawk 6X hardware with DroneCAN airspeed sensor (matek digital airspeed sensor ASPD-DLVR) to check parameter behaves as required; if SENS_DIFF_PRES_REV is set to anything other than 1, then airspeed calibration fails and negative values for airspeed are will be used when differential pressure is applied. If SENS_DIFF_PRES_REV is set, then airspeed calibration passes and only positive values will be seen when applying differential pressure (except for offsets below zero)

[bresch]

We could also automatically detect and change the parameter during airspeed calibration by checking the sign instead of asking the user to swap the tubes, right?

[AWheats]

We could also automatically detect and change the parameter during airspeed calibration by checking the sign instead of asking the user to swap the tubes, right?

We can change the code to do it automatically, yes, but I'd be worried about it taking the choice away from the user.

If users want to reverse the tubes, then it doesn't matter if the swap is automatic or manual via a parameter, because they'll want to do it anyway.

However if users don't want to reverse the tubes, the only time they will know there is an issue is during airspeed cal, where we'll send them a message stating negative differential pressure and the parameter has been set to 1 (unless we flash a periodic message?)

Having a negative value of differential pressure may mean the tubes are connected the wrong way, but it could also mean a tube has come loose in flight, which could have dangerous results for different aircraft if airspeed starts messing with the EKF. By having it as a parameter that the user has to manually enable, the user is accepting this risk - the parameter text (I hope) also makes this clear. Therefore I'd rather keep the parameter as a manually set value so that the user has to consciously accept the risk.

Do you still want me to make the change?

[bresch]

Ok, fair enough.

BTW, why taking the absolute value rather than adding a minus sign? If the tubes are swapped, you also don't want to use the "raw positive values", right?

[AWheats]

Initially I was worried about the value flip flopping between cycles - if positive and multiplied by negative, result is negative, if negative and multiplied by negative, positive. It might not have happened but I thought it was safer to just use the absolute value, so I went with that and tested it rather than trying the negative sign.

…

On Thu, 6 Mar 2025, 09:36 Mathieu Bresciani, ***@***.***> wrote: Ok, fair enough. BTW, why taking the absolute value rather than adding a minus sign? If the tubes are swapped, you also don't want to use the "raw positive values", right? — Reply to this email directly, view it on GitHub <#24434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI743TLAGG7RKZ2KCPPEN3D2TAJKJAVCNFSM6AAAAABYFMQ4J6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBTGMYDMMJXHA> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: bresch]*bresch* left a comment (PX4/PX4-Autopilot#24434) <#24434 (comment)> Ok, fair enough. BTW, why taking the absolute value rather than adding a minus sign? If the tubes are swapped, you also don't want to use the "raw positive values", right? — Reply to this email directly, view it on GitHub <#24434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI743TLAGG7RKZ2KCPPEN3D2TAJKJAVCNFSM6AAAAABYFMQ4J6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBTGMYDMMJXHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bresch]

I was worried about the value flip flopping between cycles

It's just about changing the sign of the measurement, we're not changing the sign of a member variable at every iteration.

it was safer to just use the absolute value

But you also just said about automatically changing the sign that "it could also mean a tube has come loose in flight, which could have dangerous results for different aircraft if airspeed starts messing with the EKF". By taking the absolute value we exactly do this.

[AWheats]

I was worried about the value flip flopping between cycles

It's just about changing the sign of the measurement, we're not changing the sign of a member variable at every iteration.

it was safer to just use the absolute value

But you also just said about automatically changing the sign that "it could also mean a tube has come loose in flight, which could have dangerous results for different aircraft if airspeed starts messing with the EKF". By taking the absolute value we exactly do this.

Fair point, I'll make the change to use the negative sign then, standby :)

[AWheats]

Change has been made but now it seems to have a merge conflict with another change, can't figure out how to resolve it because every time I try to push git says everything up to date

[bresch]

@NotAWalrus You probably added all your changes with git add . while having local changes on mavlink and gazebo (or submodules that where not up to date).

You can undo your last commit with git reset HEAD^, then stage each hunk of code using git add -p (do not add the submodule changes). Then commit and force push (git push -f origin pr-addabsolutediffpres).

[bresch]

@NotAWalrus I think you forgot to commit the last changes (after you staged them with git add -p you need to git commit, then push)

[bresch]

"inverse" is 1/value, let's rather call it "reverse", no?

Also, it's probably cleaner to have a single implementation in sensors.cpp rather than in each and every driver.

[bresch]

You didn't push your latest changes

[AWheats]

You didn't push your latest changes

Sorry, my bad, still getting used to git/github as I'm sure you can tell. I've pushed them now, tested the code, the last issue seems to be with the automated code testing? Any tips for how to resolve please?

[bresch]

the last issue seems to be with the automated code testing? Any tips for how to resolve please?

The SITL test for standard_vtol is under maintenance, the failing check is not related to your PR, we can ignore it.

[dagar]

This should have been done alongside SENS_DPRES_OFF rather than in every individual driver.