inav
inav copied to clipboard
iNavFlight
RTH without a compass
Current Behavior
RTH requires a compass
Desired Behavior
RTH using GPS delta to compute heading
Suggested Solution
- forward command at half nav velocity
- calculate heading as delta GPS coordinate every second
- feed the nav loop with it
- once GPS heading and desired heading match for 10 seconds, go full nav velocity
Who does this impact? Who is this for?
For those who want to use iNav on their expensive 3" quad (and want good RTH)
Additional context
the gyro would detect sudden change in heading that could be caused by wind draft or contact, if heading varries too much then go back to 1.
Issue-Label Bot is automatically applying the label Feature request to this issue, with a confidence of 0.56. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
![issue-label-bot[bot] avatar](https://avatars.githubusercontent.com/in/27079?v=4 "Published by a pub.dev verified publisher"){kind=small}
Why not use Betaflight in this case? Betaflight has a RTH feature which doesn't need a compass.
Please have a look here: https://github.com/betaflight/betaflight/pull/6404 Since betaflight 4 it's configurable!
Just to be clear, the Betaflight rescue mode doesn't bring your model home safely like in INAV. It kinda brings it towards it's creator and then tries to kill them as it crashes.
Like other things, INAV has a higher standard than Betaflight. The Betaflight rescue mode is more of a method of recovering your model (at the expense of it in pieces). The INAV RTH is designed to safely bring the model home and safely land.
There's good reason it's called "rescue mode" and not RTH, as it doesn't RTH, just kinda lures it back and then crashes, hopefully not taking the pilot out.
Yes and autolanding in bf is drop, that's why I'd prefer to stick with it. Also filters have become unfathomable in 4.0 and inav flight characteristics have become quite good.
Apart from the time things take, is there a reason why some things like RTH and autoland cannot be handled with the less precise sense of heading provided by delta GPS pos?
@laurentopia It's easy to determine direction when moving, but once you stop forward progress to land, it's really tough to know what direction to move (without a compass) to make a correction. This is why Betaflight's (kill creator mode) happens when "basically" home.
With this said, I think it's possible (albeit not totally accurate). But, simply using the current Betaflight recovery logic isn't possible without a catastrophic result (which is what INAV tries to avoid). In other words, it's not like the Betaflight code can simply be merged. A LOT of work needs to be done first.
@laurentopia It's easy to determine direction when moving, but once you stop forward progress to land, it's really tough to know what direction to move (without a compass) to make a correction. This is why Betaflight's (kill creator mode) happens when "basically" home.
How much correction does it need during the landing movement? Doesn't the PID loop handle wind related drift?
@laurentopia I believe a compass is needed to know which way to compensate for the wind. Wind seems to blow the quad all around unless GPS/compass-based position hold is activated. From a hundred feet up at my typical flight location (depending on the wind direction) it could end up on a house, tree, or in the river.
I think it's a terrible idea because people will rely on RTH without a compass and when it doesn't work they will blame INAV.
@laurentopia at the risk of suggesting spending more on what you have implied is already an expensive quad, Matek makes a combo GPS/compass module that is hardly bigger than the ceramic GPS antenna.
@humanoid2050 Same with the $15 BN-880. People want this feature not because they want a compass failsafe. They want to use some cheap GPS that doesn't work well on its on it's own and they don't want to spend $15.
Honestly, I don't think the feature should be added. It will be difficult to program correctly (Betaflight's code can't be used), it won't work well, and it will encourage people to use an inferior GPS module without compass which will cause other problems. I think it's a bad idea, especially since it can be solved with $15.
The ONLY way I'm okay with it is as a failsafe that only works if you have a compass that failed during flight. But I haven't heard any cases like that so it seems totally pointless.
Betaflights recovery mode makes sense for 2 reasons. First, the quads are typically designed to crash a lot. Secondly, navigation and safety are not priorities with Betaflight. INAV has expensive/heavy navigation models that don't take a crash well. Also, there's higher safety standards with INAV.
@teckel12 I actually own both the BN880 and the Matek GPS I mentioned. The Matek is about 50% smaller I'd say just eyeballing it. More suitable for a 3" quad as the original poster mentioned they were using.
As for the feature, I'm with you. the difficulty of isolating multiple unknowns in the form of external disturbances (wind) and intentional inputs (flying "forward" without knowing what "forward" is) is not trivial at all. There are ways to mix higher order signals into the quad's motion and attempt to isolate those intentional disturbances to separate external from internal unknowns, but you would still end up with a weird sinusoidal flight back home as a best case scenario. Or you just pick a direction and fly, slowly slewing the heading until you are going in the right direction. That's more likely to make the quad fly a giant arc until the heading is pointing directly into the wind, at which point you have probably put a big dent in your battery power. And if the wind is shifting or chaotic, you may get blown around for an arbitrarily long time depending on the chosen slew rate and the rate of change in the wind. It's the kind of thing that would make an interesting collegiate research project, but not the kind of thing that you want to ship as a functional product.
Thus my suggestion of "go buy a GPS with a compass".
These issues seem relevant, they mention compass failure and using GPS heading on multirotors:
https://github.com/iNavFlight/inav/issues/991 https://github.com/iNavFlight/inav/issues/1323 https://github.com/iNavFlight/inav/pull/2802
Bump - I'm looking at smaller craft where there is no place to fit a magnetometer which isn't drowned in noise.
Another bump - I also have small quads that I can't get a compass to work well enough on, so I am having to use Betaflight on those to get any kind of RTH.
BTW, Ardupilot now has compass-less navigation capability - see [https://ardupilot.org/copter/docs/common-compassless.html]. Maybe a similar thing could be done. If toilet bowling could be detected automatically, this could be used as a fallback to provide a much better chance of RTH in the event of compass failure or interference.
There are a lot of discussions about this topic over the years and this is probably a feature which would give the INAV project a good boost (much more INAV pilots and more INAV developer). But I guess this project is just too small to implement such an option. And that's a petty because almost any flight controller, even AIO boards could work with INAV, except for the magnetometer because of the missing SDC/SCL pads. Just tested two Tinyhawks and they work fine except for GPS rescue and Mission Control. I read a lot about that the INAV RTH is so much better than the Betaflight implementation, but I must say I had a few issues over the years with INAV and magnetometers on failsafes and wished every time there were just an option like in Betaflight. Which works pretty good for me (even on Tinyhawks or Nanohawks) and I had lots of RTHs (80+) and almost all of my quads found their way home. And the two who didn't had a defective gyro ... I know it's a lot of work to rewrite RTH, but it might be worth it ...
The Ardupilot GSF code is open, it would be enough to integrate it in INAV.
The Ardupilot GSF code is open, it would be enough to integrate it in INAV.
I completely agree that there are a lot of problems with the compass, such as pickups, which can only be tracked in flight in real conditions - and this is very bad, since there is a risk of damaging or losing the copter! For example, GPS and just all the electronics of the copter can be checked even before takeoff, while the compass is only in flight and only with a great risk of loss and damage! This is all at least not scientific!
I don't need a landing at all, I just need rescue from signal loss, and if it worked stably in BF, but there it works 2 times out of three ... In general, all this is strange, because this is such a simple function! There is the simplest mathematics- logic, no physics ... I will try to find time in the fall in winter and write it myself!
i'll bump and add a vote for rescue as well.
I don't want to deal with a compass/baro, i don't care about loiter when i'm cruising. I just want my quad to head back till i get control back and can take over and fly it home.
thanks
I'm mostly a fixed wing user, but have spent plenty of time adding tiny wires to unused pins on STM32F411 chips to get I2C for a quad's magnetometer. I'd be very happy with sort of a "spiral climb" phase for RTH that gives me back enough altitude that the video link may recover and with the GPS track figure out what direction the quad is pointing. This isn't about trying to fly back to a precision landing, it is simply a way to keep your tiny little quad from getting lost at the far end of a field of long grass. BTW I suspect that small FC's without I2C pads also are sometimes lacking a barometer (My Happymodel CrazyF4 ELRS AIO for example). How inaccurate do we expect a GPS 3D fix to be ? My little BNE-180 GPS modules often show 20+ satellites. And GPS provides an absolute altitude that won't drift on a long flight if the local weather changes.
@mirov The Spiral Climb RTH option has been in iNav since 3.0. It is a climb first method on the Advanced Tuning page.
Well yeah, that's why I mention it. It is there for fixed wing, is it currently meaningful for quads ? The new twist would be to utilize that forward motion to understand the quad orientation so that it can point home when it finishes that phase.
On Thu, Jul 28, 2022 at 9:13 AM Darren Lines @.***> wrote:
@mirov https://github.com/mirov The Spiral Climb RTH option has been in iNav since 3.0. It is a climb first method on the Advanced Tuning page.
— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/4999#issuecomment-1198357964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJFJKXE36AW3DIH5SP2D53VWKWSBANCNFSM4IKDO6QQ . You are receiving this because you were mentioned.Message ID: @.***>
Why? Quads can go straight up. It is pointless. Quads need magnetometers. Look at BetaFlight, their RTH without magnetometer is rubbish compared to inav.
I've been watching this thread for 3 years now. I think people seem to fall into one of two groups on this issue: "it won't work great, so don't give people false hope" and "i don't care if it's mostly garbage, I just want an extra failsafe if I lose signal or sight". Perhaps the real question is whether it fits in the broader goals of the iNav project. It's open source, and if there is enough interest a dedicated developer could implement it on their own fork.
Well the current inav assumption is that quads need magnetometers. This branch of the discussion is exploring "good enough" RTH behavior utilizing GPS and possibly a spiral climb to synthesize the orientation information that is missing when we don't have a magnetometer. I can imagine the utility in having a "tornado" shaped spiral climb that serves to pull a magnetometer-less quad out of an undesirable low-altitude situation and leaves us with a quad at the RTH altitude flying in the right direction.
@mirov I totally get your point. I do have some concerns about the implementation details of separating commanded motion from environmentally induced motion. I think though someone is just going to have to implement it and show it works well enough in practice on a sufficiently broad set of platforms in real world conditions.
I can certainly see how RTH could be invoked for some distant quad being subjected to strong winds (let's say to the South). If the quad is actually pointing to the West in this example and we told it to move forward it would actually move to the SW. The quad would have no idea that it isn't simply oriented towards the SW, but I don't think it would actually matter. There are probably corner cases to think about, but I think that although the quad might not be travelling in the direction the FPV camera is pointing the software will simply adjust so that it gets to the correct destination (possibly flying at a funny angle if there's a stiff wind). It seems like this could be tested on a simulation of the nav system to protect innocent quads.
Even under constant wind conditions the problem isn't too bad to solve. That shows up as a bias in the results. It's when you get random or inconsistent wind (noise) that things will get much more difficult.
Well the current inav assumption is that quads need magnetometers. This branch of the discussion is exploring "good enough" RTH behavior utilizing GPS and possibly a spiral climb to synthesize the orientation information that is missing when we don't have a magnetometer. I can imagine the utility in having a "tornado" shaped spiral climb that serves to pull a magnetometer-less quad out of an undesirable low-altitude situation and leaves us with a quad at the RTH altitude flying in the right direction.
On Thu, Jul 28, 2022 at 9:51 AM Darren Lines @.***> wrote:
Why? Quads can go straight up. It is pointless. Quads need magnetometers. Look at BetaFlight, their RTH without magnetometer is rubbish compared to inav.
— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/4999#issuecomment-1198396113, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJFJKXW43ZEOVGH6CUPFALVWK27PANCNFSM4IKDO6QQ . You are receiving this because you were mentioned.Message ID: @.***>