7.1 RC-Test-Phase Feedback

[b14ckyy]

In this post I want to collect general feedback from 7.1 Testers and possible issues that occurred and might need investigation:

General Feedback

Issues found

• on FW flight tests, altitude seems to be not as precise as it was on 7.0 on the same crafts. Specifically fixed wings. 2 Testers reported the INAV reported altitude was about 4m lower than in reality after a short time of flight and we saw errors of up to 16m. Currently under investigation. Might be related to Yaw/Altitude estimation sensor fusion #9387
• Possible issue with Autoland abort if Cruise mode and RTH with AL are enabled at the same time by different channels. Currently under investigation. Unable to disable autoland if cruise is enabled on INAV7.1 RC1 #9731 > Bug found and fixed in the next (RC2) release.

Requests

[kasatka60]

The altitude of the earth above sea level is 47. After 11 minutes of flight and landing, the altitude was 38 meters.

[Choolet]

@b14ckyy I applied your setting recommendations over a course of 9 landings and found they added no noticeable benefit, comparing to the 7.1 default settings.
Some times the landing altitude is precise, And other times it fluctuates by a few meters.
However. Incorrect altitude was always the case, when the landing head-wind was stronger.
When the wind speed was below 10km/h. The touchdown altitude was perfect.
Although, on 2 landings the head-wind was just above 20km/h. At those times I observed a touchdown altitude lower than -9m.

[b14ckyy]

In this case it might be an actual pressure issue in your build.
Airflow causes over pressure and low altitude readings. You could try to tape close an air inlet to see if that makes altitude readings more reliable. If the plane is gliding well it should not be a problem though.

[Choolet]

I thought that may be the case. The air inlet on the aeroplane is small. And the outlet is marginally larger.
A strong head-wind provides the advantage of a gentle glide down to the ground even if the altitude is incorrect.

My flight controller has foam over the barometer. And I have 3 constellations active, with more than 20 satellites.
I increased inav_w_z_gps_p = 0.45. And reduced inav_w_z_baro_p = 0.15.
When I tested it again with a 25km/h head-wind. It reduced my touchdown altitude fluctuation to only -1m and -3m on consecutive landings.
I think I'll stick with this. Thank you for the assistance.

[b14ckyy]

Foam is great if you have high airflow over the FC to reduce noise. But it won't help with airflow pressure.
I will send that feedback back to the devs with the different values. Thanks for the testing!

[Jetrell]

@Choolet I understand why those weights would work for you.. But its likely to be highly dependent on the quality of your GNSS signal on each flight session.
By reducing the weight of the baro. You will reduce the altitude estimators reliance on its data. Which appears to work for you at present. But it may end up providing worse results on other occasions.
INAV's present linear quadratic altitude estimation filter doesn't account for poor satellite EPV data (or EPH).. Meaning it often has trouble determining the trend, of which sensor data can be trusted most of the two.

Lidar/Rangefinder is likely to be the only consistent means of altitude measurement.

[breadoven]

Has anyone tried FW Auto landing for a WP mission landing ? It doesn't seem to work. Looking at the code it only appears to check for Safehome configurations not WP mission configurations so I'm guessing this is the reason why:

inav/src/main/navigation/navigation.c

Line 1733 in 622b601

if (!posControl.fwLandState.landAborted && (shIdx >= 0 || missionIdx >= 0) && (fwAutolandApproachConfig(shIdx)->landApproachHeading1 != 0 || fwAutolandApproachConfig(shIdx)->landApproachHeading2 != 0)) {

[b14ckyy]

Interesting. It worked well last time I tested on the dev build based on 7.0. @Scavanger?

[b14ckyy]

Oh btw, Autoland for WP Missions use the exact same data array as Safe Homes.
So it checks for the mission index in that line and then checks if an approach heading on the same index for the autoland parameter array is present != 0
So that check should be correct.

Index 0-7 are used for Safe Homes. 8-17 are used for the WP mission with its index.

[Scavanger]

Yeah, confirmed.
Did not work if no land parameters were configured for at least one Safehome.
Fix here: #9754

[breadoven]

Also it's not possible to save a WP mission file in Configurator if FW Auto landing is set up for a Landing WP. Fails at line:

    let approachIdx = 0;
    for (let i = SAFEHOMES.getMaxSafehomeCount(); i < FW_APPROACH.getMaxFwApproachCount(); i++){
        let approach = FW_APPROACH.get()[i];
        if (approach.getLandHeading1() != 0 || approach.getLandHeading2() != 0) {
            var item = { $: {
                'index': approachIdx,
                'no': approach.getNumber(),
                'approach-alt': approach.getApproachAltAsl(),
                'land-alt': approach.getLandAltAsl(),
                'approach-direction': approach.getApproachDirection() == 0 ? 'left' : 'right',
                'landheading1': approach.getLandHeading1(),
                'landheading2': approach.getLandHeading2(),
                'sealevel-ref': approach.getIsSeaLevelRef() ? 'true' : 'false'
            }};
            data.fw_approach.push(item);    **FAILS HERE**

script.js:46680 Uncaught TypeError: Cannot read properties of undefined (reading 'push')
at saveMissionFile (script.js:46680:34)
at script.js:46358:17
at HTMLInputElement. (script.js:6672:13)

[Scavanger]

Thanks, just a typo.

[breadoven]

Another bug is FW Auto landing disarms by FAILSAFE at the start of NAV_STATE_FW_LANDING_APPROACH when FS RTH is active because the following drops out to idle causing an instant FS landing and disarm to occur in the Failsafe module:

inav/src/main/navigation/navigation.c

Line 4893 in 622b601

rthState_e getStateOfForcedRTH(void)

inav/src/main/flight/failsafe.c

Line 537 in 622b601

disarm(DISARM_FAILSAFE);

In fact it's not good the way it changes the flight modes (mapToFlightModes) during the different Auto landing phases without actually switch to that mode. The flight mode flags affect various things in unpredictable ways if you're not actually in that mode. Would it not be better to have an Auto Land mode instead ?

[breadoven]

Also noticed the FW Auto landing phases are using stateFlags NAV_REQUIRE_MAGHOLD | NAV_REQUIRE_THRTILT which are multirotor specific so not relevant to a fixed wing only mode.

[dz0ny]

I think the auto-landing has a bit of an issue with compensating for wind from the sides. The landing strip was defined as following the edge meadow. In 2 out of 3 it landed nice, this third had it a bit rough. :)

Screen.Recording.2024-03-02.at.23.47.18.mov

Also before mentioned landing altitude is around 10m off.

[b14ckyy]

Thanks for your feedback. Can you send a diff of your setup please and a screenshot of your landing graph for reference?
Please check if you have enabled and tuned the Waypoint Path Tracking. For pinpoint precision and precise approaches this needs to be enabled. Otherwise wind can indeed influence the approach angle.

regarding the altitude, with RC2 we will revert back the sensor weights for fixed wings to the 7.0 values, that seems to show better results on some builds.

btw did you configure your landing spot with altitude over sea level enabled? To me it looks like that location has a bit of a slope and you standing on an elevated location. By default the launch altitude is always reference altitude at Zero. If you have a different landing location altitude, even just a few meters, you should use Sea Level Reference instead and check with the plane's GPS and a good fix first, what altitude it reads at the planned landing spot. Don't fully rely on the map altitude data if you don't have a Lidar.

[dz0ny]

Diff is here with history going back to iNav 6.0.0.

Please check if you have enabled and tuned the Waypoint Path Tracking.

I believe that was enabled (nav_fw_wp_turn_smoothing)?

you should use Sea Level Reference instead and check with the plane's GPS and a good fix first

Will do that for the next time.

a screenshot of your landing graph for reference

For a safety feature, this is great even if it misses a couple of meters.

[b14ckyy]

Ah I see. What I mean with path tracking is this:

Set that to 6 as a starting point. This will force the plane to fly on top of the track connecting the waypoints instead of flying straight towards the WP.
The approach length also seem to be a bit short. Consider making that 50% longer to give the plane a bit more time to align and do a shallower descent.

Turn Smoothing is always used during the landing, no matter if its enabled or not for general waypoint navigation.

[b14ckyy]

as we are about to get 7.1 final released and no other Topics showed up, I will close this here off. Thanks all for participating in the testing phase :)