Multirotor toilet bowling detection

[breadoven]

Adds toilet bowling detection for multirotors. If toilet bowling is detected a heading correction is applied which should stop the toilet bowling occurring. A system message is also shown on the OSD.

Detection is based on inconsistency between the required heading to the hold point and the GPS course over ground and also a speed/distance to hold point factor. These are only active when the quad is > 1m away from the hold point and has a speed of at least 1m/s (GPS ground course is unreliable below this speed).

The speed/distance to hold point factor, speed * distance, seems to provide a good indication of the main characteristic of toilet bowling which is rapidly increasing speed and distance from the hold point. From testing this factor is in the low hundreds for normal position hold. When toilet bowling occurs it rapidly rises to 10's of thousands.

Detection can be tuned for sensitivity by a setting that effectively sets the threshold value of the speed/distance to hold point factor. When set to 0 (default) toilet bowling detection is disabled .

This has been tested during position hold on a 5" multirotor and appears to work well. The testing initiated toilet bowling by adding an offset to posControl.actualState.yaw. 45 degs didn't seem to do much, no toilet bowling, but 90 degs immediately causes problems. When toilet bowling was detected and the heading correction applied the toilet bowling stopped immediately. The heading correction was typically within 20 degs of the actual true heading which seems to work OK given even a 45 deg heading error doesn't seem to cause toilet bowling.

Currently only works when holding position. This doesn't include when adjusting position although it appears this should work, needs more testing. Also could be extended to work with RTH etc when on route to home/WP. There is also the possibility to use this detection to flag the magnetometer as unreliable in the IMU preventing its use when Course Over Ground is reliable at higher ground speeds.

[Jetrell]

I like the concept.

Also could be extended to work with RTH etc when on route to home/WP

This would be very useful.
I've seen many logs that show magnetic deviation when a copter tilts at higher bank angles in navigation flight, as a result of the motors magnetic fields intercepting the magnetometer. to a greater degree.

May I ask.. Did you write this as a result of your copters experiencing toilet bowling over the last year ?

[breadoven]

I like the concept.

Also could be extended to work with RTH etc when on route to home/WP

This would be very useful. I've seen many logs that show magnetic deviation when a copter tilts at higher bank angles in navigation flight, as a result of the motors magnetic fields intercepting the magnetometer. to a greater degree.

May I ask.. Did you write this as a result of your copters experiencing toilet bowling over the last year ?

I've had a couple of crashes caused by toilet bowling. The first was close to trees, it hit them before you had a chance to do anything. The second was recently and shouldn't have been a problem given it was high and away from things to hit except it also had a problem with an incorrect Z velocity (caused by the toilet bowling ?) which resulted in it disarming from quite a height. It's not always immediately obvious it's toilet bowling looking through the FPV View and it had held position happily for several minutes beforehand so I assumed the compass was OK (the toilet bowling starting after yawing 180 degs so inconsistent heading all the way around). I ended up hitting RTH and it managed to make it home albeit in a massive sweeping arc then drifted off as it turned to the home heading at which point it actually recovered to a stable landing hover (the heading was actually vaguely correct in that direction). It was trying to land but the Z velocity estimation was screwed up which caused it to climb rapidly when it thought it was descending. This confused the landing detector leading to the disarm. In hindsight I should have just switch out of Nav modes and flown back manually which I tried literally at the point it disarmed. At least with this PR it probably would have stopped the instability and thrown up a message telling you it's got a problem with the compass. Would have just made thing a lot more immediately obvious. Amazingly all the quad suffered was a bent (S shaped) frame spacer post which I think was the only bit that hit a tree branch.

[Jetrell]

The reason I asked. Is because two of my test copters have expereinecd toilet bowling as well over the latter half of the 8.0 master, I tried re-calibrating the compass etc. With varied success. But haven't really pinned down why its happening.. Being that both these copters are well established in the hardware layout, over many releases. With both only having small crashes. Not enough to damage much at all.

[breadoven]

The reason I asked. Is because two of my test copters have expereinecd toilet bowling as well over the latter half of the 8.0 master, I tried re-calibrating the compass etc. With varied success. But haven't really pinned down why its happening.. Being that both these copters are well established in the hardware layout, over many releases. With both only having small crashes. Not enough to damage much at all.

I don't know much about this. But I had wondered ?

The problem in my case seemed to be caused by an old BN-880 compass and possibly a new GPS mount which was a cm lower and closer to the frame than the old mount. The heading was out by around 70 degs going from NW to S when the toilet bowling occurred. Recalibrating afterwards and fiddling with compass alignment settings to account for the fact the new mount was a few degs different to the old one didn't seem to help, the heading was always 30-40 degs off at some point in the circle. A new Walksnail WS-M181compass worked straight away, consistent compass and quicker GPS lock + smaller and lighter.

[sensei-hacker]

The reason I asked. Is because two of my test copters have expereinecd toilet bowling as well over the latter half of the 8.0 master, I tried re-calibrating the compass etc. With varied success. But haven't really pinned down why its happening.. Being that both these copters are well established in the hardware layout, over many releases. With both only having small crashes. Not enough to damage much at all.

Are you willing and able to test this?

Compiled targets can be found here, or if it's more convenient I can compile for whichever board so you don't have to hunt for them.
https://github.com/iNavFlight/inav/actions/runs/14904692673/job/41864265308?pr=10854

[breadoven]

I've been testing this using BEEPER mode with the following bit of extra test code in navigation.c

inav/src/main/navigation/navigation.c

Line 2896 in 9591dee

void updateActualHeading(bool headingValid, int32_t newHeading, int32_t newGroundCourse)

:

void updateActualHeading(bool headingValid, int32_t newHeading, int32_t newGroundCourse)
{
    /* Update heading. Check if we're acquiring a valid heading for the
     * first time and update home heading accordingly.
     */
    // TEST
    if (STATE(MULTIROTOR) && IS_RC_MODE_ACTIVE(BOXBEEPERON)) {
        newHeading = wrap_36000(newHeading + 7000);   // 7000 = 70 deg heading offset, change as required
    } else {
        mcToiletBowlingHeadingCorrection = 0;
    }
    // TEST
    navigationEstimateStatus_e newEstHeading = headingValid ? EST_TRUSTED : EST_NONE;

I've noticed you need some wind to induce toilet bowling. Even with a 70 deg heading error it wouldn't toilet bowl the other day when conditions were calm but it started pretty quickly when there was some wind on another day. Toilet bowling is more reliable with a 90 deg heading error. Which is interesting because I've wondered how accurate the compass really needs to be to avoid problems in Poshold. Seems not that accurate. I struggled to get any instability at 45 degs even with wind.

[Jetrell]

Which is interesting because I've wondered how accurate the compass really needs to be to avoid problems in Poshold. Seems not that accurate.

I figure with MAX_MAG_NEARNESS allowing for 25% magnetic field error. That maybe be why.

Which raises a question I've seen a lot of in the later part of 8.0.. How much is the magnetometer actually doing in 8.0. Because I've noticed some unusual bearing error.
I'm finding when looking over logs, that magless operation doesn't appear to work much worse. And sometimes better.

[Jetrell]

Testing with this firmware.
I lowered the GNSS module in this copter to help simulate magnetic deviation between the motors. Which it did very slightly at nav bank angles greater than 29°... So I set it to 30° for this test.
nav_mc_toiletbowl_detection was set to 3 for this 3".

In the first part of this log (not pictured here to save video file size). I was travel straight in Poshold (Cruise) and released the stick to center. And the copter pulled-up straight and in-line with the course it was traveling on.. I did this again, and the result was the same, with no deviation.
Then I turned the copter around and traveled in the opposite direction. Which incurred a sudden hook to the left by navigation. Seen by the rcCommand[roll] and not rcData[0].
As can be seen, this lead to the toilet bowl effect, until it slowly leveled out after a few swirls.

It is interesting that this also happened after a 180° turn around, as you experienced.. Which leaves the question. What is actually causing it. And why did the copter just hook to the left ? Its not the only copter I've seen this happen with over the last 8 months or so. I doubt there was enough mag deviation to cause that to happen, or it would have happen in the two stops, just before.

Once the copter had settled down to a fixed hover position, while toilet bowling. I assume systems message warning should have appeared ?

Deviation.mp4

If you would like to look at the whole log. Just ask, and I'll DM you it on Discord.

[breadoven]

Not sure it detected that toilet bowling @Jetrell given there was no system message. It also tends to very obviously snap back under control when detection happens. Looks more like the toilet bowling simply faded away by itself.