iNavFlight
Inav 8.0.1 Unstable pitch and roll movements when GPS is enabled with 6 satellites
Hello everyone, I'm having a problem inav 8.0.1 with the accelerometer, which is shifting by several degrees on the pitch and roll axes.
This issue occurs on two Matek F405 Wing V2 boards and a Matek M10 GPS.
After several tests, it appears the problem originates with the GPS. The issue starts as soon as I acquire 6 satellites; below 6 satellites, there's no problem.
The problem is present from version inav 7 onwards.
My tests:
I tried disabling the magnetometer, Connecting it to a different I2C/TX/RX port, Powering the GPS with a different power supply than the Matek's, Testing with several versions of iNAV, Testing with a different GPS, Testing with a second, brand-new Matek F405 Wing V2 board, Testing outside of any magnetic field that could cause interference. Even with more than 20 satellites, the issue persists.
Can you help me solve this problem?
https://youtu.be/cCqpKSoqGwo?si=MIZ3JgGv43VAu2vj
This originally appeared on the FB FORUM. It must be significant that the issue only occurs in 7 and 8, and not in 6. What UART baudrate? The M10 has 9600 default Could this be related to the provision to be able to fly without a GPS?
This is caused by the AHRS and is normal when the craft is static on the ground. It's not an indication anything is wrong and will resolve itself in flight when the AHRS has all the info it needs to work correctly.
Ce message a initialement été publié sur le forum Facebook. Il est significatif que le problème ne se produise que sur les versions 7 et 8, et non sur la version 6. Quel est le débit UART ? Le M10 a un débit par défaut de 9 600 bauds. Cela pourrait-il être lié à la possibilité de voler sans GPS ?
At 9600 baud, the GPS does not activate. It works from 57000 baud with many errors. It works and connects quickly at 115000 baud.
Ce phénomène est dû au système AHRS et est normal lorsque l'appareil est immobile au sol. Il n'indique aucun problème et disparaîtra de lui-même en vol, une fois que l'AHRS aura reçu toutes les informations nécessaires à son bon fonctionnement.
Thank you for your feedback. When the drone is in POSHOLD mode immediately after takeoff, it refuses to maintain its position but does maintain its altitude. Could this be due to the AHRS system?
Regarding the 9600 BAUD. The MATEK GPS is set by them to a default of 9600. This can be changed with the right tool. This comes from the MATEK spec document https://www.mateksys.com/?portfolio=m10-5883#tab-id-2
Regarding the AHRS. The poster says that the issue does not occcur with 6, only 7 and 8. 6 had a major AHRS update.
GNSS sensors should be fine at 115200 baud. I'd only ever change it if there are communication problems. So far, I've never changed any.
I expect you are right Mr D. The Physicist in me mistrusts devices used outside their spec. AFAIK it is easy to change the BAUD RATE of the GPS to check. This could well be a communication problem.
In regard to the AHRS I thought it was https://github.com/iNavFlight/inav/pull/9387 that caused the pitch/roll drift and this came in version 7. This pitch/roll drift was mentioned before in another issue but I can't find it.
I see a number of similar issues raised. Presumably a sliding window method is used to smooth the data and reduce noise. Can anyone confirm? It looks like some noise is getting through.
Merci pour votre soutien. Voilà une personne qui a eu le même problème que moi. Sans solution..
https://github.com/iNavFlight/inav-configurator/issues/2147
Actuellement j'ai deux vtol heewing qui sont en 8.0.1 avec une f405 wing v2 et une h743 wlite et qui ont les même symptômes, mais aussi un soucis de POSHOLD qui garde bien l'altitude mais pas ça position et avec l'impossibilité de mise a jour de la position rth.
Tous les paramètres sont bien paramétrer. Le compas es bien activé et correct 3°/4°degré
Je sais pas ci cela peut vous aider... Ci vous avez besoins de plus de détails n'hésitez pas.
Regarding the AHRS. The poster says that the issue does not occur with 6, only 7 and 8. 6 had a major AHRS update.
As breadoven stated. This is just a function of the AHRS. It has been this way since INAV 6.0 when the AHRS DCM was updated to use centrifugal force compensation, to reduce attitude/horizon drift. GNSS velocity is used to augment and correct for IMU drift which can occur under certain conditions of flight. So once the module acquires a satellite fix, And it has a low satellite count and precision. The position and velocity can been seen drifting within many tens of meters from the aircraft's actual stationary position.
Take a look at the position accuracy in meters, in the GPS tab when the Sat count is low. Also notice how your GPS position shifts in the maps. This effect will be much less when the position accuracy and GPS count increases. And will have little effect once a GPS heading is obtain inflight. If it does show up in flight. This will only likely occur if your GNSS precision still remains poor throughout the flight, for what ever reason. Possibly leading to attitude or heading drift, that is slow to correct for the error.
Concernant l'AHRS : l'auteur du message indique que le problème ne se produit pas avec la version 6, mais uniquement avec les versions 7 et 8. La version 6 a bénéficié d'une mise à jour majeure de l'AHRS.
Comme l'a indiqué breadoven, il s'agit d'une fonction inhérente au système AHRS. Ce fonctionnement est inchangé depuis la version 6.0 d'INAV, date à laquelle le module DCM de l'AHRS a été mis à jour pour intégrer la compensation de la force centrifuge et ainsi réduire la dérive d'attitude et d'horizon. La vitesse GNSS est utilisée pour compenser la dérive de l'IMU, qui peut survenir dans certaines conditions de vol. Ainsi, une fois que le module a acquis une position satellite, et compte tenu du faible nombre de satellites et de la faible précision, la position et la vitesse peuvent dériver de plusieurs dizaines de mètres par rapport à la position stationnaire réelle de l'aéronef.
Vérifiez la précision de la position en mètres dans l'onglet GPS lorsque le nombre de satellites est faible. Observez également le décalage de votre position GPS sur les cartes. Cet effet sera nettement moins marqué lorsque la précision de la position et le nombre de signaux GPS augmenteront. Il sera quasiment imperceptible une fois le cap GPS obtenu en vol, si toutefois il s'affiche. Ce problème ne se produira probablement que si la précision de votre GNSS reste faible tout au long du vol, quelle qu'en soit la raison. Cela peut entraîner une dérive d'attitude ou de cap, lente à se corriger.
Bonjour et merci pour votre réponse
Je comprend bien le système AHRS mais comment expliqué que quand je suis en mode angle le drone cherche a partir a ce dévié en permanence sur le pitch et le roll ? Sachant que ci je désactive le gps je n'ais plus aucun problème.
@Jerome26140 There is somewhat of an issue concerning that in releases after 7.0. But its also more often seen when the GNSS precision is poor.
If you have a high end GNSS module like an M9. Or an M10 that has genuine Ublox hardware, with a descent size antenna, its practically never encountered. Mostly because such modules always provide a HDOP less than 1.2.
But if your GNSS hardware isn't the best. Or the module is never getting a good satellite fix, due to localized RF noise from other devices in the model. The likelihood of your issue occurring is much higher.
With a poor satellite fix, I'd often noticed that taking off and flying around a bit to get a strong GPS course, reduces the chance of this occurring the next time you enter a hover. If you feel up to a steep learning curve The AHRS gains and GNSS weights can be adjusted, if your copter consistently experiences poor GNSS position accuracy. This may help a little.
@Jerome26140 Il existe un problème relatif à cela dans les versions postérieures à la 7.0. Ce problème survient plus fréquemment lorsque la précision du GNSS est faible. Si vous possédez un module GNSS haut de gamme comme un M9 ou un M10 équipé de matériel Ublox authentique et d'une antenne de taille convenable, ce problème est pratiquement inexistant. Cela s'explique principalement par le fait que ces modules offrent toujours un HDOP inférieur à 1,2. En revanche, si votre matériel GNSS n'est pas optimal ou si le module ne parvient jamais à obtenir une bonne position satellite en raison de perturbations radiofréquences localisées provenant d'autres appareils du système, la probabilité que ce problème se produise est beaucoup plus élevée.
En cas de mauvaise réception satellite, j'ai souvent constaté que décoller et voler un peu pour obtenir un signal GPS précis réduisait le risque que cela se reproduise lors du prochain vol stationnaire. Si vous êtes prêt à relever le défi, sachez que les gains AHRS et les pondérations GNSS peuvent être ajustés si votre drone rencontre régulièrement des problèmes de précision GNSS. Cela pourrait légèrement améliorer la situation.
Merci de votre Retour, je vais procéder a des tests cette après midi. Vérifié ma quantité de satellite et la qualité du hdop.
Un mauvais hdop (1.6) peut il empêcher le poshold de s'activer ?
Avez vous un descriptif un tutto de la procédure pour le réglage du AHRS ?
Merci 🙏
Poshold, or the activation of any navigation mode is determined by inav_max_eph_epv. It maybe tempting to increase its value above the default. But keep in mind, that if GNSS precision is bad enough to cause wandering at less than 10m. It going to be even worse if you set it higher.
Avez vous un descriptif un tutto de la procédure pour le réglage du AHRS ?
No sorry. That's something have not got around to.
Le seuil de position, ou l'activation de tout mode de navigation, est déterminé par un paramètre
inav_max_eph_epv. Il peut être tentant d'augmenter sa valeur au-delà de la valeur par défaut. Cependant, gardez à l'esprit que si la précision GNSS est suffisamment mauvaise pour provoquer une dérive inférieure à 10 m, ce sera encore pire si vous augmentez ce paramètre.Avez-vous un descriptif un tutto de la procédure pour le réglage de l'AHRS ?
Non, désolé. Je n'ai pas encore eu le temps de m'en occuper.
Je viens de refaire des tests il y a énormément de vent et le vtol n'aime vraiment pas ça, mais vous avez raison avec 26 satellites et un HDOP a 1.15 j'ai trouvé qui était beaucoup plus stable et garde beaucoup mieux son stationnaire en mode angle, je confirmerai avec un autre essai avec un temps sans vent.
Mon dernier soucis se trouve au niveau du poshold. Il garde bien son altitude mais pas du tout son horizontal. J'ai essayé de travailler les valeurs de vélocité et de gain au niveau du GPS sur axe X et Y jusqu'à l'extrême 255 mais rien n'a changé. Le gps est un matek M10 J'ai essayé de changer les baud 9600 a 115000, de passé par u-center même résultat.
J'ai remarqué depuis le début j'ai des erreurs sur le GPS... Et les hz varie entre 5hz et 10 hz jamais vraiment stable.
Pour lever le doute du GPS défectueux j'ai essayé avec un BN250 même résultat...
Thanks Jerome for testing the way the BAUD RATE affects the GPS readings. It seems to me that the best way forward for the quality of your flying is to get the best quality of GPS data that you can. This usually requires checking the antenna arrangement on your quad and making sure that the very sensitive GPS is the only device ontop and VTX and Rx are underneath. Unless you're Tx is in the sky somewhere!
You may want to have a look through this for more detail about tuning navigation PID's. Increasing them up to 255 is not the best idea, as I touched on in that wiki. It can cause undesirable results.
Navigation PIDs should only altered once the stabilization PIDs are first tune correctly. And tuning the Stabilization PIDs for a VTOL isn't as easy as for a proper multicopter. Because as you said, wind heavily influences how tightly a VTOL can actually be tuned. Due to the wing and horizontal/vertical stabilizer area fighting the corrections made by the motors. Plus most VTOL are generally more under powered than an equivalent multicopter.
This all leads to tuning becoming hit and miss, depending on the flight conditions. They often respond better when having the D-term at zero or very low. And also reducing the fw_i_level term. As I touch on here in the fixedwing tuning section. Because the level controller just can't update as fast on a VTOl platform, as a copter.
Also have a read through here. It may provide you some more GNSS related information, you might not be aware of.
Merci Jérôme d'avoir testé l'influence du débit de transmission sur les relevés GPS. Il me semble que pour améliorer la qualité de vos vols, il est essentiel d'obtenir des données GPS de la meilleure qualité possible. Cela implique généralement de vérifier la configuration des antennes de votre drone et de s'assurer que le GPS, très sensible, est le seul appareil placé au-dessus, tandis que l'émetteur vidéo et le récepteur sont en dessous. À moins que votre émetteur ne soit en vol !
Oui exactement c'est pour cela que actuellement je n'ai pas mis le système vidéo sur l'appareil. Pour éviter toute interférence avec le GPS
Vous trouverez peut-être plus de détails sur le réglage des PID de navigation utiles ici . Comme je l'ai mentionné dans ce wiki, il est déconseillé de les augmenter jusqu'à 255, car cela peut entraîner des résultats indésirables.
Les PID de navigation ne doivent être modifiés qu'une fois les PID de stabilisation correctement réglés. Or, le réglage des PID de stabilisation d'un VTOL est plus complexe que celui d'un multicoptère classique. En effet, comme vous l'avez mentionné, le vent influence fortement la précision du réglage d'un VTOL. La surface de l'aile et des stabilisateurs horizontal et vertical s'oppose aux corrections apportées par les moteurs. De plus, la plupart des VTOL sont généralement moins puissants qu'un multicoptère équivalent. Par conséquent, le réglage devient aléatoire et dépend des conditions de vol. Ils réagissent souvent mieux avec un terme D nul ou très faible, et il est également conseillé de réduire ce terme. Comme je l'
fw_i_levelévoque dans la section sur le réglage des avions à voilure fixe, le contrôleur de palier ne peut pas se mettre à jour aussi rapidement sur une plateforme VTOL que sur un multicoptère.Consultez également cette page . Elle pourrait vous fournir des informations supplémentaires sur le GNSS dont vous n'avez peut-être pas connaissance.
C'est super merci pour toutes ces informations et cette connaissance partagée jolie travail, Je vais travailler là-dessus mais je suis pratiquement sûr que mon problème vient de là, je tiendraiau courant de l'évolution. Merci de l'aide
I finally found the problem; it was my command deadbands that were incorrect... strange malfunction, but it works perfectly now. Thank you to the whole team for helping me, and have a good day!
Thanks Jerome for the feedback. Glad you have sorted the problem. Any advice to others with the same issue?