Projet drone Arduino (Project Guidance)

International Français
1

Bonjour a tous

Alors, avant tout, petite présentation...
Nous sommes deux potes qui débutons dans le monde Arduino. je suis en DUT informatique, et lui en BTS Electrotechnique. donc pour faire simple, je programme, et lui il soude.

Donc notre projet serait de faire un drone contrôler depuis un site internet, j'aborderais tout cela en détail un peu plus tard, tout d'abord, un apperçu du matériel a notre disposition :

Donc, grace a tout ce matériel, le drone serait contrôlable depuis un site internet (grace au shield WiFly). Le site afficherait ce qui entoure le drone grace a la CMUCam, et permetterais de déplacer le drone ...
Nous envisageons également d'investir dans un shield BlueTooth pour offrir les mêmes fonctionnalité aux utilisateurs possesseurs de téléphones portables/Smartphones.

Le petit écran tactile permetterais d'avoir une IHM pour selectionner différent "mode" du drone.
Pour le moment, nous avons penser a un mode "exploration" ... On placerais le drone dans une pièce qui lui est inconnue, le drone avancerais jusqu'a trouver un mur, le longerait, et réaliserais une "map 2D" qu'il afficherais sur l'écran tactile.
(dans ce cas, rajouter un capteur de proximité infra-rouge)
L'utilisateur pourrais, une fois l'exploration de la pièce réalisé entièrement, pointer une zone, et le drone s'y rendrais (de préférence en empruntant le chemin le plus court, et en arrivant a l'endroit indiqué par l'utilisateur ^_^)

Voila grosso-modo ce qu'on compte faire ...

Donc avant de dire

C'est impossible avec un arduino, retourner sur les banc de l'école.

on aurais quelques question techniques.

Tout d'abord, l'écran tactile est afficher comme tel :

  • "Works with any Arduino '328 (Mega not supported yet)"
    Y-a-t'il un moyen, en bidouillant le branchement des pins ou autre, de le rendre compatible avec un Mega 2560 ?

Après plusieurs recherche, nous avons compris qu'il est impossible pour l'arduino de transmettre dirèctement un flux vidéo (pas assez performant). Nous avons donc opté pour la CMUCam qui dispose d'un transmetteur intégré.
Seulement ce dernier utilise des réseaux de type "802.15.4" (http://www.ieee802.org/15/pub/TG4.html)

  • Premièrement, devrons nous gérer deux connexions wifi (une pour le shield WiFly, qui transmetterais les ordre de déplacement, et une pour le transmetteur de la CMUCam, qui transmetterais uniquement le flux vidéo) ?
    Ou pouvons nous transmettre le flux vidéo de la CMUCam vers le shield Wifly qui ensuite transmetterais le tout ?
  • Deuxièmement, est-ce que les réseaux de type "802.15.4" sont compatible avec les réseaux wifi plus courant (802.11.a/b/n/g) ? Ou devrons nous créer un réseau 805.15 ? Et dans ce cas, comment procéder ?

De manière plus général, en ce qui concerne la communication entre le site web et le drone, nous avons entendu parler de PROCESSING.
Est-ce un langage adéquat, ou suffit-il simplement d'utiliser un langage interprété, dans ce cas, nous pourrions utiliser Ruby ou Python (Arduino Playground - HomePage ... Arduino Playground - HomePage) ?

Voila, plus ou moins pèle-mêle, les questions qui nous viennent a l'esprit.

Maintenant vous avez le droit de dire que c'est impossible :smiley:

Cordialement a tous ceux qui nous aideront.

2

il faut s engager dans l'armée, ils ont ce genre de jou-jou :wink:

je débute aussi donc je vais pas me prononcer par contre beau projet/idée en espérant qu ils soient réablisables

3

Beau projet en effet ... qui me semble assez pharaonique pour des débutants (enfin dans sa vision complète).

Perso j'ai peur pour la partie "contrôle par internet", il risque d'y avoir pas mal de latence ... enfin si vous voulez le contrôler "en direct" (pour lui envoyer des ordres genre "va ici" ça ira par contre.

Côté soft, tous les langages font l'affaire, processing a l'avantage d'être le support de l'IDE arduino, donc programmer en utilisant processing c'est quasiment pareil que programmer une arduino. Ca évite d'avoir 15 langages à apprendre.

Par contre je suis pas du tout spécialiste sur tout ce qui est wifi et ethernet avec arduino, donc je laisse les autres te répondre plus précisément ...

4

Bonjour,

Mon petit grain de sel :

  • avec la wifly la latence depuis le web sera de plusieurs secondes ! La wifly de sparkfun est encore en version BETA et pour en avoir une moi même je parle en connaissance de cause.
  • la carte arduino mega est pas du tout adapté pour ce genre d'application il faut une puissance de calcul relativement importante pour gérer les paramètres et en plus si vous comptez faire une une AI (algo de découvert du territoire, persistance du terrain, reconnaissance des point repère, ...) il vous faudra une quantité de ram et de flash très grande que la mega ne contient pas ! Il sera plus intéressant de ce tournée vers un µc arm-cortex-m3 (stm32, lpcx, ...).
  • l'idée d'utilisé un écran tactile n'est pas vraiment une chose que j'aurai fait, ce genre d'écran résiste pas longtemps aux vibrations et la nappe flexible va casser en même pas une semaine.
  • l'utilisation d'une cmucam est intéressante après il faut aussi voir jusqu'à quel point l'algo qui tourne derrière peut marcher dans votre projet.

Coté wireless le 802.15.4 n'est pas du tout compatible wifi (ou bluetooth) c'est une porteuse 2.4ghz (de mémoire ) qui est utilisé pour la transmission à faible vitesse (émetteur vidéo à distance pour tv, ...).

Ce genre de drone coute très chère à réaliser (je le sais j'en fait en en ce moment même) pour un projet comme le votre comptez dans les 400 €

A mon avis il serait plus intéressant d'utiliser une cmucam3 (basée sur un lpc21xx) pour la totalité du traitement avec des contrôleurs moteur autonome de pololu de cette manière la cmucam contrôlerait tout les moteurs via une liaison série.
Voila comment je ferais (à prendre comme un conseil ;)):
coté drone:
cmucam3 (pour le contrôle général) , contrôleur pololu (comme le Qik 2s9v1 pour le contrôle des moteurs), Bluetooth Mate de sparkfun (pour la communication)et un encodeur de roue optique (pour l'estimation des distances).

coté ordi:
une clef bluetooth, un récepteur vidéo de lextronic pour la cmucam et surtout un logiciel pc avec un canal de donnée permanent entre le drone et l'ordi qui se chargerait de tout les calculs (en ce basant sur un prog type maze solver pour trouver le chemin le plus rapide et la librairie openCV pour faire la détections de point de repère).

voila voila ^^ sinon c'est un projet très intéressant à suivre.

5

skywodd:

  • l'utilisation d'une cmucam est intéressante après il faut aussi voir jusqu'à quel point l'algo qui tourne derrière peut marcher dans votre projet.

A mon avis il serait plus intéressant d'utiliser une cmucam3 (basée sur un lpc21xx) pour la totalité du traitement avec des contrôleurs moteur autonome de pololu de cette manière la cmucam contrôlerait tout les moteurs via une liaison série.

Méa-culpa j'ai oublié de précisé qu'il s'agissait effectivement d'un module CMUCam 3
Dans un premier temps elle ne servirait qu'a voir ce qui entoure le drone. on utiliserais donc que la fonction vidéo de la CMUCam ...
Plus tard, peut être intégré un mode "tracking" pour suivre un petit ballon au sol (ou un animal de compagnie xD)

Mais qu’entend tu par "la totalité du traitement" ?

skywodd:

  • avec la wifly la latence depuis le web sera de plusieurs secondes ! La wifly de sparkfun est encore en version BETA et pour en avoir une moi même je parle en connaissance de cause.
    Bluetooth Mate de sparkfun (pour la communication)

Nous souhaitons vraiment développer une communication wifi (802.11) en plus d'une communication bluetooth (et pas simplement "tricher" en utilisant du bluetooth sur un ordinateur)
Il me semblait avoir vu des arduino avec un shield ethernet qui pouvais faire ce genre de chose a peu près. Je sais bien qu'en ethernet la vitesse de transfert est plus rapide, mais je pensais que c'était faisable en wifi. Dans ce cas, y aurait-il un autre module Wifi qui fonctionne mieux que celui de Sparkfun ?

skywodd:

  • la carte arduino mega est pas du tout adapté pour ce genre d'application il faut une puissance de calcul relativement importante pour gérer les paramètres et en plus si vous comptez faire une une AI (algo de découvert du territoire, persistance du terrain, reconnaissance des point repère, ...) il vous faudra une quantité de ram et de flash très grande que la mega ne contient pas ! Il sera plus intéressant de ce tournée vers un µc arm-cortex-m3 (stm32, lpcx, ...).

On se doute qu'on ne pourra pas faire une IA directement sur le drone ...
Mais si l'on suppose que la connexion wifi fonctionne (et j'entend par la qu'on pourrais transférer rapidement des données) ... N'y a t'il pas alors moyen de "tricher" en faisant faire tout les calculs à l'ordinateur. Dans ce cas, aucun problème de mémoire etc ... et une fois les calculs effectué, l'ordinateur ne ferait que transmettre des ordres de déplacement au drone

skywodd:
un encodeur de roue optique (pour l'estimation des distances).

Les encodeurs en quadrature sont plus précis il me semble ?... sa permet également une estimation de la vitesse, et vu qu'on en a deux, on pourrais aussi estimer la rotation du drone en plus de la distance parcourue.
(cf : Odométrie )

skywodd:
un récepteur vidéo de lextronic pour la cmucam et surtout un logiciel pc avec un canal de donnée permanent entre le drone et l'ordi qui se chargerait de tout les calculs (en ce basant sur un prog type maze solver pour trouver le chemin le plus rapide et la librairie openCV pour faire la détections de point de repère).

un Récepteur vidéo en plus de la CMUCam ? dans quel but ?
Quand au "logiciel pc avec un canal de donnée permanent" est-ce ce que l'on parlait de la même chose quand a l'envois des données a l'ordinateur qui effectuerais le calcul et transmettrais les résultats au drone ? Cela consisterais a avoir une sorte d'adaptateur 802.15 pour que la CMUCcam puisse communiquer avec l'ordinateur ?

6

oromis:
Mais qu’entend tu par "la totalité du traitement" ?

La cumcam3 peut être reprogrammée comme n'importe quel arm pourquoi brider cette puissance potentielle à un "simple" tracking.
Rien que dans la doc lextronic il est clairement précisé qu'un module cumcam peut contrôler des servo, faire de l'i2c, etc ...
Et en utilisant uniquement la cumcam comme µc la gestion du hardware est grandement simplifié et surtout le poids final réduit (il ne faut pas oublier les moto réducteurs qui vont souffrir si il ont trop de poids à porté ;))

oromis:
Nous souhaitons vraiment développer une communication wifi (802.11) en plus d'une communication bluetooth (et pas simplement "tricher" en utilisant du bluetooth sur un ordinateur)
Il me semblait avoir vu des arduino avec un shield ethernet qui pouvais faire ce genre de chose a peu près. Je sais bien qu'en ethernet la vitesse de transfert est plus rapide, mais je pensais que c'était faisable en wifi. Dans ce cas, y aurait-il un autre module Wifi qui fonctionne mieux que celui de Sparkfun ?

En réalité je suis mauvaise langue la shield wilfy de sparkfun fonctionne très bien (bien que le module wifi utilisé soit mer... bref) le problème c'est que en voulant copier le schéma de base de la libraire de la shield ethernet (officiel) il ont tout simplement pas implanté une partie des fonctions "wifi" telle que puissance du signal, mode AP, ad-hoc, etc ... ce qui freine considérablement les possibilités. Deux possibilité, attendre la version 3 ou faire sa propre surcouche.

oromis:
On se doute qu'on ne pourra pas faire une IA directement sur le drone ...
Mais si l'on suppose que la connexion wifi fonctionne (et j'entend par la qu'on pourrais transférer rapidement des données) ... N'y a t'il pas alors moyen de "tricher" en faisant faire tout les calculs à l'ordinateur. Dans ce cas, aucun problème de mémoire etc ... et une fois les calculs effectué, l'ordinateur ne ferait que transmettre des ordres de déplacement au drone

C'est ce que je proposé en parlant de "canal de donnée permanent" on laisse l'ordi faire le gros du calcul et le drone sert juste t'interface.
La wifly est limité (par software) à 10ko/s maximum (de mémoire histoire de liaison uart/spi 9,6ko/s de base, un fou de sparkfun à "apparemment" réussi à monter a 57ko/s mais j'ai comme un doute ...).

oromis:
Les encodeurs en quadrature sont plus précis il me semble ?... sa permet également une estimation de la vitesse, et vu qu'on en a deux, on pourrais aussi estimer la rotation du drone en plus de la distance parcourue.

Oui j'ai juste oublier de précisé le type ^^".

oromis:
un Récepteur vidéo en plus de la CMUCam ? dans quel but ?
Quand au "logiciel pc avec un canal de donnée permanent" est-ce ce que l'on parlait de la même chose quand a l'envois des données a l'ordinateur qui effectuerais le calcul et transmettrais les résultats au drone ? Cela consisterais a avoir une sorte d'adaptateur 802.15 pour que la CMUCcam puisse communiquer avec l'ordinateur ?

Oups j'ai encore confondu les normes, le 802.xx c'est pour la liaison série de debug (honte à moi confondre avec le wireless ...)
La cumcam n'as pas de sortie vidéo tout passe par le port série et (je vais revérifié tout à l'heure) vu le faible débit en wifi il est fort probable que tout le traitement doivent ce faire sur la cmucam ce qui serait assez gênant mais pas impossible.

7

Posons les choses a plat.

Soit un BIT = 1 ou 0,
Soit un BAUD = une encapsulation de BIT.
Soit un OCTET = 8 BITs
Soit un Kilo-octet = 1024 Octets (banalisation du Kibi-Octet en Kilo-Octet ...)
Soit un Kilo-bit = 1000 Bits
Soit Bps l'abréviation de Bit par seconde, et non Baud ...

D'après la doc' disponible sur le site de sparkfun a propos du WiFly de RovingNetwork ... On trouve page 6 (Reference Guide (RN-131C) )

the default is 9600 baudrate, 8 bits

traduction : vitesse de transfert par défaut 9600 Bauds par seconde, et 1 baud = 1 octet ... (je crois que dans la version 2, la vitesse par défaut est de 38400 Baud/sec)

On peut conclure que la vitesse de transmission (c'elle qu'on connais plus habituellement, le Bit par Seconde) correspond a :

Bit par seconde = Baud par seconde x nombre de bit par baud

soit, par défaut, 76800 bps.
Ce qui donne 76800 bps => 76800/8 = 9600 Octets par seconde => 9600/1024 = 9,375 Ko/sec
d'après le même raisonnement, avec les 38400 Bauds par seconde, on trouve 37,5 Ko/sec

en fouillant sur les forums de sparkfun, on peut trouver ceci (par la)

I think in theory the SPI-UART connection should now be able to support ~900 kilo-bits per second but I've not tested actual throughput. I'm also not sure what overhead the library adds at the moment. I'm also not sure what other factors will limit the throughput.

--Philip;

900 Kb/sec = 900000 Bit/sec => 900000/8 = 112500 Octet/sec = 109 Ko/sec

Donc une vitesse théorique satisfaisante ... Mais quelqu'un a-t'il tester un Baud Rate de 112500 ? Est-ce que les résultat IRL sont en accord avec les résultats théorique ?

Y-a-t'il également possibilité de changer le Baud Size ?... Parce que 8 Bits par défaut, c'est assez faible a mon gout, ou est-ce que c'est "imposé" par le µContrôleur 8 bits ?...

8

oromis:
traduction : vitesse de transfert par défaut 9600 Bauds par seconde, et 1 baud = 1 octet ... (je crois que dans la version 2, la vitesse par défaut est de 38400 Baud/sec)

Inutile de ce casser la tête, bauds -> octet = bauds/1024 en général c'est toujours sur 8 bits.
Et non la vitesse par défaut est toujours de 9600 ! Par "sécurité" vu que leur méthode de transfert byte par byte est pas top.

oromis:
On peut conclure que la vitesse de transmission (c'elle qu'on connais plus habituellement, le Bit par Seconde) correspond a :

Bit par seconde = Baud par seconde x nombre de bit par baud

soit, par défaut, 76800 bps.
Ce qui donne 76800 bps => 76800/8 = 9600 Octets par seconde => 9600/1024 = 9,375 Ko/sec
d'après le même raisonnement, avec les 38400 Bauds par seconde, on trouve 37,5 Ko/sec

Non mais pourquoi s'embêter ? Dans ce cas bauds = octet (c'est sur 8bit faut pas chercher à faire compliquer).

oromis:
en fouillant sur les forums de sparkfun, on peut trouver ceci (par la)

I think in theory the SPI-UART connection should now be able to support ~900 kilo-bits per second but I've not tested actual throughput. I'm also not sure what overhead the library adds at the moment. I'm also not sure what other factors will limit the throughput.

--Philip;

Oui alors pour avoir testé non ^^"" le crash du buffer est instantané si le timming déconne (webserver, download d'un jpeg, baudrate trop haut -> j'ai jamais reçu le jpeg bon v1 à l'époque mais ça a pas trop changé).

oromis:
Donc une vitesse théorique satisfaisante ... Mais quelqu'un a-t'il tester un Baud Rate de 112500 ? Est-ce que les résultat IRL sont en accord avec les résultats théorique ?

oromis:
Y-a-t'il également possibilité de changer le Baud Size ?... Parce que 8 Bits par défaut, c'est assez faible a mon gout, ou est-ce que c'est "imposé" par le µContrôleur 8 bits ?...

Je suis pas sure mais je crois que bien c'est impossible.

Je vais faire mes petit test IRL pour voir si j'arrive à tourner à ~450Ko/s ( avec le transfert bulk, spi avec un prescaler de 2 et port mapping (pas de digitalWrite), 460800 bauds) théoriquement c'est la vitesse typique d'utilisation pour le gateway uart et le module wifly.

9

C est un beau projet qu'y m'a trotté dans la tete un certain temps.
Je suis plutôt du genre à commencer un projet dans sa methode la plus simple en venant greffer les modifications au fur et à mesure.
A mon avis je commencerai par la construction du drone, avec ces moteurs, ces gyro et accelerometres au cas ou, et je commencerai à le faire tenir en l air.
Il vaut mieux "scratcher" 150 euros d'electronique embarqué que 500 Euros avec ces cameras et toutes ces platines.

Il existe des platines ARDUPILOT et ARDUIMU qui permet des vols stabilisés avec un controle GPS et qui permet egalement de voler en immersion ou FPV. Ce vol en immersion est possible grace à une camera à bord et d'une emission sur 2.4Ghz. on peut egalement passer la telemetrie dans cette emission Xbee.

C est un exemple. Regarde recherche documente toi sur ce sujet mais commence a te lancer. Le pilotage d un drone n est pas facile suivant ces reglages et les reactions sont vives. Qui dit reaction vives dit aussi temps de reponse le plus court possible.

Ton projet évoluera au fil des essais et je pense que tu seras surpris du resultat un peu different de ce que tu imaginais.

Courage.

10

Bonjour,

Maintenant que tu en parle caco74 j'ai comme un doute ! C'est un drone volant ou terrestre ?
Vu qu'il y a des encodeurs optique j'ai pensé terrestre mais maintenant j'ai un doute ...

Bon sinon j'ai finit mes test IRL ! Alors voila les résultats :
vitesse bauds | 38400 | 460800 | 614400 | ... | 921600
connexion réussi | oui | oui | non | | non
temps (ms) début | 7132 | 9793 |
temps (ms) fin | 34321 | 15733 |
théorique ko/s | 37.5 | 450 | 600 | | 900
vitesse réel | 3.7 | 17 |
| 18 (essai n2)

test (3 essai) avec 460800 bauds, en théorie 450ko/s
temps début (ms) | 9793 | 7988 | 7090
temps fin (ms) | 15733 | 13931 | 12668
delta (ms) | 5940 | 5943 | 5578
vitesse ko/s | 17.2 | 17.2 | 18.3

Coté hardware:
arduino uno, wifly shield v3, transfert bulk activé, réseau wpa neufbox, ordi win7 avec netcat en serveur.
taille du payload: 100Ko (100 x 1024 octets)
envoie octets par octet (je sens que la différence entre théorie / pratique vient d'ici !)

Coté code:

#include "WiFly.h"

char passphrase[] = "PASSPHRASE";
char ssid[] = "SSID";

byte server[] = { 
  xx, xx, xx, xx }; // netcat server
Client client(server,1234);

void setup() {

  Serial.begin(115200);
  Serial.println("Wifly Speed Test");

  WiFly.begin();

  if (!WiFly.join(ssid, passphrase)) {
    Serial.println("Association failed");
    while (1);
  }
  Serial.println("Wifly Ip");
  Serial.println(WiFly.ip());

  Serial.println("Speed Up Transfert");
  WiFly.configure(WIFLY_BAUD, 460800); //38400

 Serial.println("Connecting to client ...");

}

void loop() {
  if (client.connect()) {
    Serial.println("Connection sucess");
    Serial.println("Transfert start");
    Serial.println(millis());
    for(long i=0;i<102400;i++) // upload 100Ko
      client.print("A");    
    client.stop();
    Serial.println("Transfert done");
    Serial.println(millis());
  }
  delay(5000);
}

Si j'ai fait une erreur je suis tout ouïe ! (c'est même fort probable vu les résultats !)

11

Du coup skywodd tu me mets un doute aussi on va attendre une reponse alors !

Au vue des caracteristiques moteurs il semblerai que se soit terrestre apres seconde lecture.

12

Bonjour,

Je plussoie aussi dans l'idée terrestre.
Avec une telle puissance de propulsion par rapport au poids embarqué des appareils, cela en ferait un engin très "spécial".
Et il y a aussi l'idée de carte 2D : En aéronautique on raisonne plus en 3D.

L'idée reste néanmoins intéressante; c'est un peu comme ces robots de la NASA qui se déplacent "à moitié" tout seul entre deux ordres ^.^

13

J'étais en train de me dire que mon projet d'hexapod va utiliser le même genre de code vu qu'il possède une adaptation au terrain ...
Je vais suivre ce projet d'encore plus prés :*

Ps: personne aurait une shield wifly pour confirmer mes tests ci dessus ?
C'est que ça plomberai bien un de mes projets si les résultats sont confirmer :.

14

Alors oui mon Drone est Terrestre ... bien que le mot drone désigne un engin volant non habité ...

on va rester au sol avant de faire comme Ycare.