11 réflexions sur « Nipdev 24 – Hard du Copter »

1. On apprend dans cette épisode un gros avantage de l’opensource (hardware et logiciel) qui à permis la bonne réalisation de ce projet 😉

   Une question: je me souviens, dans le domaine de la robotique que Aldebaran permet de vérifier sa programmation avec une application simulant le comportement de ses robots (nao)
   Y a-t-il un équivalent pour les drones permettant de vérifier son code avant de mettre à jour celui du drone physique ?

   Répondre

   1. Bonjour Mikado,
      Oui on l’aborde plus loin dans la conf. Pour les dernières versions d’arducopter, SITL est utilisé. Voici une présentation et un tuto pour l’installer:
      http://dev.ardupilot.com/wiki/setting-up-sitl-on-windows/

      Par contre il ne sera pas possible de tout tester avec SITL, principalement le comportement en l’air mais c’est déjà pas mal étant donné que le risque se trouve une fois en l’air.

      Répondre

      1. De ce que j’en vois sur le lien, on a une vue du dessus ainsi que l’assiette en « temps reel » je suppose.
         Mais pour le cas de notre amis walking codeur, il fallait un peu plus d’information de simulation: on a un personnage à suivre, mais il faut le filmer en « reculant », à moins d’avoir 2 caméras: 1 devant pour éviter les obstacles et une autre derrière pour filmer le codeur.

         Répondre

2. Avec arduino, rasberry pi et maintenant les drones, on a le retour d’une vague de « bricoleur » hardware comme il y avait au début de l’informatique 😉
   J’en profite pour vous recommander une série très intéressante se déroulant à cette époque: Halt and Catch Fire

   Autre question: de base, il y a un algo de pathfinding, ou il faut le développer nous-même ?

   J’ai eu ma réponse pour la simulation, mais n’ayant pas testé on ne sais pas comment ça se passe exactement ? est-ce qu’on a une interface 3d où l’on voit le drone évoluer, peut -on ajouter des « obstacles » , des matières (fummée/brume..)

   Répondre

   1. Effectivement la prochaine étape qui se profile est l’évitement d’objet et le calcul de trajectoires… bien des projets en cours de développement annoncent utiliser ces fonctionnalités mais actuellement rien de tout ça n’est disponible.
      Et de toute façon, chacun peut décider de créer et utiliser/partager son propre script, c’est ça l’open source!
      Personnellement je travaille sur la détection d’objet, le calcul de trajectoire sera l’étape suivante logique.

      Pour le mapping 3D, il existe les techniques de photogrammétrique… un projet qui s’en rapproche
      http://www.gaiddon-software.com
      mais pas de simulateurs 3D qui utiliseraient le code arducopter pour calculer le comportement du drone… seul du 2D en SITL.

      Je pense qu’une bonne partie du code peut être testée au sol sur le drone en utilisant la télémétrie et la console pour afficher des résultats mais qu’à une moment donné, il faudra risquer son appareil… donc appareil robuste de test fortement conseillé!

      Répondre

      1. Personnellement, je serais curieux d’initier un projet de simulateur 3D
         Pour ce genre de projet un peu ambitieux, il faut
         1. Créer un projet github sous licence libre
         2. récupérer un code simple, juste de décolage de l’engin
         3. créer une bibliothéque qui sera utilisée à la place de « l’API » du drone et qui dans un premier temps ne fera que loguer dans un fichier les appels qui lui sont fait:
         Ainsi on peut vérifier que l’on a bien l’exhaustivité des méthodes à coder.
         4. faire un premier POC sur un moteur physique sans obstacle de vision de décollage + déplacement d’un objet « ressemblant » à un drone

         Pourriez-vous m’envoyer l’exemple de code juste pour un décollage ?
         Mon tweeter: @dupot_org

         Répondre

3. Pour le pathfinding, c’est un peu comme les design pattern: il y a des algorythmes éprouvés, après il faut faire son choix en fonction de la « lourdeur » de calcul nécessaire dans chacun des cas.

   Pour les drones, c’est dès que l’on met de l’intelligence, que l’on se retrouve dans le même cas qu’un batch ou autre code qui tourne « silencieusement »: il nous faut du log, des cas de tests pour éprouver l’algo 😉
   Je pense qu’on doit pouvoir utiliser un moteur « de jeux » actuel qui ont souvent un moteur physique pour tester un algo d’un objet volant: ainsi on pourrait mettre des bots, des obstacles et vérifier l’algo de déplacement, évitement « basique »
   Après, il y aurait une part spécifique pour utiliser les différentes API du drone en question.
   note: je trouverais ça sympa de pouvoir coder des algo d’IA pour des drones virtuels dans un environnement 3D
   Ca rappellera le jeu de la tortue 😉

   Une question toute bête: comment on sait avec un drone qu’il y a un obstacle: il y a des sonars, on utilise une caméra avec détection de pixel ?
   Je suppose que pour la plupart des obstacles il suffit de prendre de l’altitude, mais dans d’autre cas, il faut « contourner » une zone complète: l’altitude maximum du drone étant limitée je suppose.
   D’ailleurs, il y a également une fonction/algo pour déterminer la consommation approximative d’énergie pour un trajet: ce serait dommage de partir sur une élévation si on a finalement pas assez d’énergie pour freiner la descente 🙂

   Répondre

   1. Salut Mikado,

      désolé pour la réponse tardive… en déplacement.
      Pour ta question sur la détection d’objet, il y a en effet plusieurs moyens. Le traitement d’image étant surement le plus perfectionné mais requérant le plus de ressources et de développement.
      Le sonar n’est pas vraiment conseillé du fait de sa faible portée (quelques mètres) et de sa forte sensibilité aux perturbations acoustiques générées par les hélices.
      Pour ma part, je vais utiliser un lidar-lite qui est une mesure laser (ça devrait bientôt sortir). Cela permet des mesures jusqu’à 40m, ce qui est déjà pas mal! Le capteur monté sur une nacelle permettant un scan de l’hémisphère supérieure du drone.
      Par contre je mesure point par point et pour un mapping total, il en faudrait donc un très grand nombre si on souhaite connaitre chaque pixel de la sphère entourant de drone. Plus le rayon de cette sphère augmente, plus il faut de points de mesure… donc la caméra serait finalement un meilleur outil avec un besoin en ressources conséquent mais constant et des performances elles-aussi constantes.

      L’altitude max du drone est relativement pas limitée, mais bien souvent il faudra trouver un trajet alternatif à altitude constante notamment si le code est utilisé en assistance au pilotage fpv… peu intéressant d’aller dans la stratosphère pour éviter tout objet quand le but du vol est de réaliser un film ras du sol ou surveiller l’état d’un réseau électrique ou d’un pont par exemple.

      Quant à la surveillance de la batterie, oui tout cela est déjà géré par le code actuel, des mesures de return-to-launch ou atterrissages peuvent être paramétrées.

      Je serais très intéressé par un outil de simulation 3D. J’ai fait quelques modèle très basiques sous matlab pour tester des bribes de codes mais cela est très loin d’etre complet et exploitable pour une simu globale en 3D. Si quelqu’un a les compétences pour développer une passerelle entre le code arducopter et un logiciel de simu, je suis preneur (et bien d’autres personnes le seront aussi!)

      Répondre

      1. Pas de soucis, l’essentiel c’est de répondre 😉

         Pour la détection d’obstacle pour eviter les collisions, le traitement d’image semble être le meilleur compromis: il est dificile de detecter un fil électrique, une branche d’arbre avec un sonar ou un laser…

         Pour la hauteur maximum c’était juste pour indiquer que s’elever pour éviter un obstacle avait ses limites, et je souhaitais connaitre celle-ci: les moteurs ne sont pas si puissant que cela, et même malgré le poids plume de l’engin, je pense qu’il doit avoir une haltitude maximum, après il faut la connaitre.

         Pour la surveillance de la batterie, vous parlez de return-to-launch, mais ça veut dire que tout les N minutes il calcul l’energie necessaire pour revenir à son point de départ et quand il estime ne pas avoir l’energie de retour il fait demi tour automatiquement ?

         Pour le simulateur 3D, ce qu’il faudrait:
         S’appuyer sur un moteur existant, de préférence opensource et avec si possible gestion de la physique.
         Créer un « wrapper » (pas sur du bon terme) pour executer le code du drone sur l’environnement virtuel.
         Il faut donc connaitre l’ensemble des classes/methodes appelées pour recoder une librairie qui fera agir l’objet volant dans cet univers 3D
         Au départ, je pense qu’il faut faire le strict minimum: créer l’ensemble des appels possible (sans code derrière), enregistrer le code du drone en « modifiant » la librairie du drone autorisé (pas sur que ça se fasse ainsi)
         Juste pour voir si il n’y a pas d’erreur (on peut ajouter du log pour verifier que l’environnement virtuel recoit bien toutes les instructions)

         Et enfin la partie marrante: implémenter chaque action (pivoter, avancer augmenter les gaz…) et voir si l’engin virtuel agit de façon cohérente dans cette sandbox 😉
         Donc rien d’insurmontable, surtout si le projet est initié en opensource et permettrait ainsi de fédérer autour de celui-ci 😉

         Répondre

         1. A voir si le moteur de jeu de Blender3D ne serait pas suffisant. Vu qu’il est couplé à un langage de script qui permet d’utiliser des librairies scientifiques, qu’il gère la physique (peut-être sommaire) et qu’il est open source, ça pourrait peut-être valoir le coup.(en plus, multi-plateforme).

            Répondre

            1. Pourquoi pas, c’est pas les moteurs 3D qui manquent, la première étape est de créer ce « wrapper » qui communiquera avec ce moteur 3D plutot que d’envoyer les instructions aux cerveaux moteurs du drone 😉