GPS-i2C drotek

[wareck 9]

Bonjour,

Je viens de finir les tests en vol du GPS i2c drotek...

Ca fonctionne plutot bien...un peu compliqué lors de la mise au point, mais là çà vole super bien.

Le position hold est super stable et précis.

Le return to home nickel, et le headfree pas mal non plus...

Il ne reste plus beaucoup de place en ram de l'arduino, mais ça fonctionne bien...

Reste plus qu'a attendre le soft pour placer les waypoint...

pour plus d'infos , j'ai fait une article complet sur ce produit:

GPS-i2C-Drotek

Olivier

[Invité]

Salut Wareck,

Ton lien ne fonctionne pas.

Antoine

[wareck 9]

ah?

regarde à : http://www.fernitronix.fr

[Invité]

Tu utilise quoi comme puce pour être limite en ram ?

[wareck 9]

un arduino pro mini...

avec les options (IMU, GPS, Battery monitor, ppm sum, led control,wp) je suis à 28180 bytes sur les 32400 dispo...

[Invité]

Tu utilise quoi comme puce pour être limite en ram ?

Merci à tous!

[Invité]

un arduino pro mini...

avec les options (IMU, GPS, Battery monitor, ppm sum, led control,wp) je suis à 28180 bytes sur les 32400 dispo...

Ah oui, en effet !

Tu aurais pas mal a gagner a passer sur du 2560 non ???

Mon bo frere en a un clone en version ADK ( compatible android il me semble ) qui n a pas trop coûté chère.

Du temps ou je discutais avec les dev de l APM, un des dev m avait dit que c était plus prudent de faire tourner le PPM sum sur un autre chip que celui qui gere tous les capteurs et les calculs.

En gros sur l apm tu a un atmega 328 pour le ppm sum ( qui fait fail safe aussi ) et apres tu as un 2560 ( pour les version 2 et 2.5 ) pour le reste.

[wareck 9]

En fait j'ai une carte qui me fait le sum à partir d'un recepteur 9 voie.

Et l'injecte sur un fil dans l'arduino...

Je vais passer au 2560 sous peu...La carte en est cours de design sur mon pc

encore quelque jours de taf et je soude tout cela...

En tout cas, je suis assez content du module GPS, la tenue en position hold est vraiment efficace.

Bon moins que le naza, car le soft est encore jeune et manque un peu de maturité, mais disont que l'helico evolue dans un cercle de 2 mettre de diametre, si l'helico derive plus de 2 mettre, le gps prends les commandes et le remet au centre du cerle.

Ce calcul est fait comme cela pour eviter de surcharger la puce, et de rendre le vol robotique qui au final donneras un truc de pas bon sur les prises de vues.

Une lègere variations d'altitude ou de position ne gene pas la prise de vue propre, par contre des corrections permanente ça se vois plus...

Je dois encore farfouiller le code et les PID, le return to home ressemble plus à un apontage qu'a un poser en douceur, mais bon...ça se regle...

Olivier

[wareck 9]

voila, ma carte est pleinement fonctionnelle, le gps fonctionne à merveille

[gabe 0]

Salut Wareck,

Tu as affiné les PID GPS ou tu as utilisé un nouveau code?

[wareck 9]

Alors en fait j'ai testé:

-Le code multiwii 2.1 + i2c-gps-nav

Ce couple, permet de voler deja très bien, mais les boucle de codage concernant les pid sont en "dur"

C'est a dire que les PID sont intégrés au soft i2c-GPS-Nav et ne peuvent etre reglés par le gui.

Cela demande donc à chaque essai de reprogrammer completement le GPS

C'est lourd

mais au final les PID d'origine donnent le meilleur resultat.

C'est un peu compliqué à expliquer, mais en gros je cherchait à avoir un helico super verouillé.

Ca fonctionne ,mais pour verouiller la position en l'air, il corrige en permanence.

Cela se traduit par une consommation moteur accrue, moins d'autonomie et un helico en vol qui bouge dans tous les sens (au debut ça fait même peur)

En laissant une marge de calcul et de lissage, il a des mouvements plus amples et doux.

Cela est benefique surtout pour le FPV/prise de vue, les mouvements lents ne sont presque pas perceptible à la camera.

-Ensuite j'ai bricoler la version 2.1 en ajoutant des boucle de codes, qui permettent de regler les PID depuis le GUI et chagent completement les réaction des PID (ratio de calculs different)

Pour l'instant c'est pas encore super au point, je retrouve les sensation comme expliquées avant.

Ca verouille la position mais la machine bouge trop en vol.

Les parties de codes que je parle sont en cours de devellopement, ils seront sur la 2.2 d'ici septembre/octobre.

Cela fonctionne assez bien mais c'est bien compliqué en l'air.

Contrairement au PID de vol, ici il faut prendre en compte d'autre paramètres.

J'explique par un exemple simple:

Imaginer l'helico à 100 metres de vous au bout d'un stade, vous enclenchez le return to home:

-L'helico regarde sa position et la position "home" fait une estimation de la distance à parcourir.

-100 metres ce qui correspond à 10000 cm

-il vas diviser ceci par la valeur "speed navigation" par exemple 400 pour moi

-ce qui donne 25 longueurs à faire

-Les PID vont definir :

-la prise d'angle maximale de la machine peu prendre pour commencer son approche

-la distance que la machine vas faire à grande vitesse (speed nav max)

-la distance de freinage et l'angle de freinage maxi

-la distance à faire à basse vitesse (speed nav min)

-la precision d'arret

La machine vas donc dans un premier temps s'inclinée pour prendre de la vitesse

Ensuite se remettre à plat jusqu'a 2/3 de la distance a parcourir

Elle vas s'incliner pour contrer la vitesse de deplacement

puis progresser doucement par petites correction jusqu'au point à ateindre.

Si on touche au pid les phenomenes suivants peuvent survenir:

-trop d'angle au depart, la machine par trop vite et "loupe" le point de depart, repart dans l'autre sens et fait le yoyo en passant et repassant au dessus du point

-Trop d'angle d'arret...elle repart dans l'autre sens et reviens, repart

-Trop de distance entre le point d'arret et le point à ateindre, elle fini le vol en faisant le marsouin et corrigeant en permanence...très désagréable à la video

-mauvaise precision sur le point à ateindre, la machine cherche trop à aller au point parfait et au final se balance

La cinetique de maintien de position ou de navigation automatique s'apparente à une spirale.

La machine part de loin avec de la vitesse, et au fur et à mesure qu'elle se rapproche du point ,ralenti et corrige la trajectoire.

Mais les contraintes technologique (gps volontairement bridés par les constructeurs, les puces limitées en vitesse de calcul) et les contraintes physique (moteur, frotement de l'air, pertubations ect...) font que ce procéder reste le meilleur

En touchant à un parametre de PID cela demande automatiquemnet de toucher aux autre parametre et entraine une LONGUE procedure de réglage

Nous travaillons donc sur un autre approche des reglages de PID, limitant ainsi les interactions entre les parametres.

Le but etant de rendre le systeme GPS plus ou moins Plug-N-Play...avec les PID calculés par EosBandit ça fonctionne deja très bien, c'est largement suffisant.

Pour ma part j'ai juste un return to home un peu trop rapide, la machine semble faire des apontages plutot qu'un posé automatique, mais je crois que c'est lié à l'interaction entre l'altitude du GPS et celle du barometre.

Le barometre est sensible à l'effet de sol, pas le GPS.

je cherche donc à rajouter dans le code un systeme qui désactive l'un des deux capteur lors de l'approche du sol...actuellement il faut rajouter un sonar i2c pour faire cela...

Bref ça fonctionne bien d'origine, pour l'instant le soft ne permet pas trop d'afiner les valeurs simplement et rapidement.Mais ça vas venir

olivier

[wareck 9]

Petite mise à jour, la nouvelle version du soft GPS-i2c viens de sortir.

je tape l'article qui explique comment le configurer et s'en servir...

Olivier