Inav: Bigger max loiter radius for airplane current around 100m it to low

[srepfler]

Current Behavior

Would not arm with more then 100m radius.

Desired Behavior

Should be able to loiter in 300m or more radius.

Suggested Solution

increase max allowed loiter radius or allow to limit be change or set with CLI variable

Who does this impact? Who is this for?

for automated flying planes, bigger planes, faster planes...

Additional context

Would be nice to give warnings why it did not armed with bigger radius,
without CLI status did not know why is not arming.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Feature request to this issue, with a confidence of 0.89. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[MrD-RC]

Personally, I find it really hard to believe that there are planes that need to loiter in a 200m circle (100m radius). Even large motor gliders could happily loiter in half that distance.

Do you have any examples of why you need such a large loiter radius?

I agree about the warnings. You should not be able to enter a value of more than what is accepted.

[srepfler]

Personally, I find it really hard to believe that there are planes that need to loiter in a 200m circle (100m radius). Even large motor gliders could happily loiter in half that distance.

Do you have any examples of why you need such a large loiter radius?

I agree about the warnings. You should not be able to enter a value of more than what is accepted.

Yes for just loitering it is enough, but people use it as easy alternative to mission like task,

• cruise around me to check video link quality / antenna position ( if directional range good bad signal)
  
  
  
  • range check
  
  
  • visually check some position depending on height camera angle, if gimbal even more
  
  
  • search and rescue
  
  
  • lost model find
  
  

Even 2.4 ghz radio and 5.8 non directional can easy allow 700m circle
It easier to allow bigger loiter than add special modes or advance mission to have programmable radius.

When mission get better, multiple missions, commands relative to position, programmable task, loiter can be less.
For start even to be able to disable check loiter out of limits for people who need more, rest will have default.
Older firmware could loiter in much bigger radius.
Maybe just add warning in configurator ( loiter radius big) and who ignore warning can fly bigger circle.

[breadoven]

What reason did the CLi status give for it not arming ?

[MrD-RC]

Yes for just loitering it is enough, but people use it as easy alternative to mission like task,

• cruise around me to check video link quality / antenna position ( if directional range good bad signal)
• range check
• visually check some position depending on height camera angle, if gimbal even more
  
  
  
  • search and rescue
  
  
  • lost model find
  
  

Even 2.4 ghz radio and 5.8 non directional can easy allow 700m circle
It easier to allow bigger loiter than add special modes or advance mission to have programmable radius.

Interesting. I never thought of using loiter like that. I guess because the flight mode is called pos hold, so it indicated just to hold the current position.

It sounds like for these kinds of tasks it would also be good if it was able to be switched with iNav programming (logic conditions/global functions)? So on a switch, you could have the default radius (for pos hold, as it currently is in iNav), and two different radii for these simple missions.

It also sounds like having pos hold points in missions, where you can set the radius and duration would also be useful too.

[srepfler]

What reason did the CLi status give for it not arming ?

Loiter out of radius. ( Something like that - status is great, but without status no clue)

[breadoven]

There is a problem where Configurator lets you enter invalid values through the settings tabs and saves them happily to the FC, least it does for Loiter Radius. However, if you try to enter the value through the CLi it won't let you so this needs fixing, ... Configurator issue.

I guess it's worth checking the CLi status after changing settings to see if there are any errors like this before you head off to fly.

[stronnag]

2.6 configurator validates this correctly. Values > 10000 are set to 10000.

[breadoven]

I was using Configurator 2.6 Version 0.42.2.0. Is there a newer version ?

[stronnag]

tested with git commit 6607343e of 2020-10-26 via http://seyrsnys.myzen.co.uk/inav-configurator-next/

[breadoven]

If you change focus to something else the invalid value does change to the max/min limit. However, It seems there is a bug related to changing the value and then clicking Save and Reboot without changing focus from the field you changed. So enter 15000 in the Loiter Radius field and click Save and Reboot with the cursor still in the Loiter Radius field and it saves 15000 to the FC, which then won't Arm. Just realised on reboot it shows a red cross for "Settings Validated" in the Setup tab which shows settings are invalid although you'd still need to use CLi status to understand why.

[MrD-RC]

I can confirm @breadoven 's findings. The data validity isn't checked until the field loses focus. So any field could have incorrect data filled and submitted.

@srepfler having a look a little deeper. It wouldn't be good to set the loiter radius so high by default. I think the 100 m radius is correct. This is because other navigation modes also use the loiter radius, such as RTH and waypoints.

However, I think that setting larger radii via programming would be ok. This is because it would be separate from the nav functions and only override pos hold when the switch is set to change the radius. It would also allow you to have multiple alternate radii for testing. As a safety feature, I think that the minimum value should be no less than the standard loiter radius (can be constrained in code). But it could allow for a much larger radius, for example 1000 m.