Increase allowed speeds in NAV modes on multirotors

[DzikuVx]

Current default are very slow, let's give INAV some speed!

[Jetrell]

@DzikuVx I know in theory this idea seems good.
However, the multirotor navigation code just isn't up to the task. Especially for smaller quads.
Bank angle much greater than 30° has a bad tendency to cause -

• Magnetic heading deviation.
• IMU heading deviation (magless operation).
• GNSS EPH increased deviation.

Presently, getting the best multirotor navigation performance with INAV, is a fine balancing act... Especially in missions, that have closer way points.
This was also the reason Julio added #9677.

For INAV's multirotor navigation to work optimally with higher bank angles on all size copters. Only the addition of these, would aid accuracy, control and smoothness of operation.

• More predictive sensor fusion for XY.
• Wind estimation
• And multiple nav_mc_vel_xy controllers. That can be tune specifically to their individual target requirements.

Without them. Multirotors end up wallowing around a WP, POI or Slowdown locations, trying to achieve a target position. While the whole time creating a short term feedback loop, of poor sensor data verses the inability of even tightly tuned navigation XY PID's, being able to meet the target. Especially with a tail wind.

[sensei-hacker]

@Jetrell is that partly because the mag is read as earth frame rather than vehicle frame? Does it assume Z always points straight down?

It sucks that navigation limitations lead the Angle mode being hobbled.

[Jetrell]

@sensei-hacker That may have some influence. But I'm rather sure frame rotation is included in the code.
Its more about the simplicity of how tasks are performed. Without knowing what other factors in the copters hardware layout, can influence sensor accuracy at higher bank angles.

Tasks are performed simply.. e.g. Here is the data >> Now output a response... With too little consideration to whether the data can be trusted.
Error is less noticeable and more easily overcome when things are performed slower. But when they are done faster. You end up with a mess of tasks, all interfering with one another. Based on the speed the hardware can perform it.

This is why Ardupilot has predictive data extrapolation via their extended kalman filter... Which works in the similar way a human does when flying a copter.. We see whats coming up next, and make a decision on how to deal with the anomaly, before we get to it.. By either slowing down, or bypassing and negating the bulk of the problem.

However there are easier ways to partially work around the bank angle/ nav speed issue, to provide a better outcome. But I don't imagine it would likely occur yet. So I won't go into detail here.

[DzikuVx]

I do not entirely agree with the notion that proposed defaults are too big. There are several reasons:

1. Current defaults are well, very conservative. 3m/s for RTH is well, absurdly slow.
2. Increase to 6m/s puts it around 20km/h and based on all my experiments over the years still very reasonable
3. Modern multirotors are able to reach 20km/h without too much of inclination angle and if so mostly during acceleration
4. yes, nav_manual_speed is up to 36km/h but this is manual speed and pilots still have control
5. Current defaults were created when typical INAV craft was an underpowered 10" wobbly bobbly. Now, it's not longer a case

However, let's discuss more conservative speeds

[stronnag]

FYI ... data point: even my 2014 9" wobbly quad can RTH at 7m/s and the even wobblier 2015 10" tri is happy at 6m/s.

[Jetrell]

@DzikuVx Considering that a multirotors navigation speed is a product of nav_auto_speed and nav_mc_bank_angle.. I don't see that increasing nav_auto_speed as any big issue at all. 👍
The was just concerned about having nav_mc_bank_angle increased more than it is presently at 30°.

For reference, I have my 7" cruiser with nav_auto_speed = 2000 and nav_mc_bank_angle = 28. It will make it too that speed on a windless day, with no issues. And bounce off that speed and try to slow down with a tail wind.

[sensei-hacker]

Jetrell expressed that navigation at steeper angles is less precise. Here we have single setting doing double duty - the angle the navigation code uses is also the maximum angle the pilot can command in angle mode, at full stick deflection.

It seems to me, when the pilot inputs full stick, for maximum bank or pitch, they should be allowed to GO.

Would it maybe make sense to do something like:
Max bank (angle mode) 45°
Navigation uses up to 0.67 X max = 30°

[MrD-RC]

Aren’t there also max navigation angles too. Like there are for fixed wing?

[Jetrell]

@sensei-hacker @DzikuVx nav_manual_speed is also used by the navigation position controller.

• Poshold - nav_user_control_mode = Cruise and Attitude
• Cruise flight mode
• MC braking mode.

Sensor data inaccuracy also effects these manual position control modes, just the same as fully autonomous modes.
If the pilot commands the copter to a higher nav_mc_bank_angle, in any of these modes. Then releases the stick to halt the copter. A combination of conflicting IMU data and navigation control function, causing the copter to temporarily runaway, until the GNSS velocity finally overrides it, and tells the copter to stop.. It becomes even worse at higher bank angles.
This condition has been there from the beginning of INAV. And is somewhat mitigated by lower values set in nav_mc_bank_angle. Except in the case of braking mode, which has its own bank angle setting.