18 réponses à ce sujet

[NooTe]

Bonjour à tous,

Je vous présente mon projet en cours de réalisation (je suis novice dans la robotique, un peu moins en informatique).
Il s'agit d'un robot d'exploration qui a vocation de devenir autonome (comme une grande partie des robots ).

Le projet s'articule sur 3 composants : une base mobile, un "cerveau" et un "observateur de résultat" (je les détaille un peu plus bas).
Cela se fera a base Arduino et d'Android.

La base mobile est un DFRobot 4WD (plateforme a 4 roues motrices... mais seulement deux dans la realité), celle-ci se voit équipé d'une carte micro-contrôleur DFRobot Roméo v1.0, associé à un module DFRobot Bluetooth v3, 4 switchs de distance, une tourelle tilt/pan ou est logé le "cerveau" (avec deux servos moteurs).

Le cerveau est un téléphone mobile HTC Désire qui communiquera avec la plateforme via Bluetooth. Celui-ci est solidaire de la plateforme mobile (en haut de la tourelle mobile).
Sa camera servira à la reconnaissance et l'analyse du territoire (soft en cours de développement, basé sur la détection de lignes et de reconstruction 3d en temps-réel si c'est possible), il sera aussi le transmetteur des informations à l'"observateur" (streaming audio/video, prise de photos) via Wi-Fi.
Pour info, HTC a supprimé le profil SPP (Serial Port Protocol) du firmware officiel (froyo 2.2), le téléphone a donc été rooté et une version de Cyanogen 7.1.0 R1 a été installée (Gingerbread 2.3.4).

L'observateur est, dans le cas présent, une tablette Acer A500 (Honeycomb 3.2, mais pourrait etre tout autre appareil mobile sous Android avec un écran large) qui sera connectable via Wi-Fi au cerveau. Il recevra les informations (positions, capteurs, flux video) mais pourra, bien sur, prendre le pas sur le commandement du robot.

Ou en suis-je actuellement sur le projet ?
La plateforme mobile est assemblé, les switches réglés, la communication avec le cerveau est établie ainsi que la communication entre le cerveau et l'observateur. Le cerveau ne sert pour le moment que de relai de commande depuis l'observateur. en parallèle, je continu mon travail sur la détection des lignes (algorithme choisi est une simplification de l'algo "RANSAC"... une autre voie est la transformée de Hough).
Qui reste encore a faire : le streaming audio/video et l'envoi des photos du cerveau vers (qui sont stocké sur le portable pour le moment).
Matériellement, je prévois encore une amélioration majeur : l'ajout d'un capteur de distance a ultrason (type DFRobot URM04) qui serait solidaire et orienté dans le sens de la camera (pour la reconstruction 3d).
Et bien sur, l'IA reste entièrement a faire
Maintenant, je ne suis pas sur que le HTC Désire soit assez puissant pour tout faire à la fois... c'est donc aussi un défi a ce niveau là

Dans un premier temps, je finalise le "remote control" entre le cerveau et l'observateur (streaming video en priorité).
Puis je reprends le dev sur la reconnaissance de territoire.
Et ensuite l'IA...

Voila, ca reste assez ambitieux pour une première tentative dans le domaine de la robotique. Mais, j'ai le temps et l'ambition pour le finir ^^
Je prevois de mettre tout en opensource quand ca sera plus stable (finalisation du remote controle).

[Leon]

Sa camera servira à la reconnaissance et l'analyse du territoire (soft en cours de développement, basé sur la détection de lignes et de reconstruction 3d en temps-réel si c'est possible),

Tu peux nous en dire un peu plus, stp? Car ça doit intéresser beaucoup d'entre nous. Cartographier un environnement 3D avec une unique caméra, c'est quelque chose d'ambitieux.

Quels types d'algos comptes-tu utiliser? Tu as déjà défini ça? Est-ce que tu vas reprendre du code existant? Si oui, lequel? Ou alors tout coder toi même? Et dans ce cas, quel algo, quelle théorie utilises-tu derrière?

Autre question: tu n'as pas d'autre capteur dans ton robot? Pas d'odométrie, de gyro? Comment comptes-tu déterminer le placement de ton robot par rapport à son environnement? Par la caméra uniquement?

Enfin, comment comptes-tu utililiser le sonar attaché à la caméra? Les sonars ont un cone de détection assez large en général (30°), donc ça n'est pas facile.

Leon.

[NooTe]

Tu peux nous en dire un peu plus, stp? Car ça doit intéresser beaucoup d'entre nous. Cartographier un environnement 3D avec une unique caméra, c'est quelque chose d'ambitieux.

Quels types d'algos comptes-tu utiliser? Tu as déjà défini ça? Est-ce que tu vas reprendre du code existant? Si oui, lequel? Ou alors tout coder toi même? Et dans ce cas, quel algo, quelle théorie utilises-tu derrière?

Autre question: tu n'as pas d'autre capteur dans ton robot? Pas d'odométrie, de gyro? Comment comptes-tu déterminer le placement de ton robot par rapport à son environnement? Par la caméra uniquement?

Enfin, comment comptes-tu utililiser le sonar attaché à la caméra? Les sonars ont un cone de détection assez large en général (30°), donc ça n'est pas facile.

Leon.

Pour la reconstruction 3D, je ne compte pas utiliser de librairie ou de soft déjà existant... c'est clair que certaines librairies existent déjà, et répondrait partiellement a ce que je pense faire (comme OpenCV, qui implémentent la transformée de Hough pour la detection des lignes dans une image ou les SIFT point d'intérêt d'une image).
Mais, le but est de tout faire "a la main" (sinon c'est pas drôle ).

Donc, grosso modo, l'idée est de se baser sur l'omographie entre deux images. On utilise plutôt ce type d'algo dans le sens inverse en réalité augmentée (repéré un modèle 2d dans un image, et ensuite extrapoler sa position 3d), ou dans la creation des panoramas a partir d'images multiples.
Je connais l'angle entre les deux images, grace aux servos de la tourelle et/ou au capteur d'angles et/ou au gyroscope du portable, et je devrais avoir une estimation de la distance grâce a un capteur de distance.
Je m'aide des lignes droites (dans un monde industrialisé comme le notre, les lignes droites abondent) et des croisements de ces lignes comme point de "référence".
A partir de là, faire une estimation de la profondeur devrait ne pas être trop compliqué et donc d'ensuite d'en extraire les volumes (on le fait dans les moteurs 3d, grâce à l'inversement de la perspective).

Bon, par contre, apparemment, l'idée du sonar n'est pas si bonne... donc, je vais me rabattre sur un capteur IR ou laser.
L'idée du capteur de distance est juste d'estimer la distance de certains points détectes par le RANSAC, donc d'orienté la tourelle dans la direction du "point" d'avoir la distance... et ainsi de suite (le robot etant statique a ce moment la). Lorsque l’environnement virtuel de l'endroit ou ce situe le robot a été établi, celui-ci repart vers a un autre endroit et refait le scan autour de lui... tant qu'il n'est pas environnement connu, il est en mode détection.

Pour le stockage de l’environnement, je pense partir sur un monde représenté en voxel.

Les algos de reconstruction 3d existent deja a partir de l'extraction de point d’intérêt (SIFT, SURF) ou la détection de point de fuite...

C'est l'idée générale... reste à la concrétiser ^^

[Leon]

Pour la reconstruction 3D, je ne compte pas utiliser de librairie ou de soft déjà existant...
[...]
Mais, le but est de tout faire "a la main" (sinon c'est pas drôle ).

C'est la philosophie que j'applique également dans mes projets (voir ma signature).

Donc, grosso modo, l'idée est de se baser sur l'omographie entre deux images.

Omographie? Qu'est-ce que c'est? Mon dico ne connait pas, wikipedia non plus.
http://fr.wiktionary.org/wiki/homographie

A partir de là, faire une estimation de la profondeur devrait ne pas être trop compliqué et donc d'ensuite d'en extraire les volumes (on le fait dans les moteurs 3d, grâce à l'inversement de la perspective).

Pareil pour le terme "inversement de la perspective". Ca veut dire quoi?

Je connais l'angle entre les deux images, grace aux servos de la tourelle et/ou au capteur d'angles et/ou au gyroscope du portable, et je devrais avoir une estimation de la distance grâce a un capteur de distance.

Quel type de capteur d'angle, et qui mesure quoi?

Sinon, encore une fois, pourquoi ne pas utiliser d'odométrie pour savoir de combien ton robot s'est déplacé?

En tout cas, c'est un chouète projet. Tiens nous au courant.

Leon.

[NooTe]

C'est la philosophie que j'applique également dans mes projets (voir ma signature).

J'ai regardé surtout la partie "Intelligence Artificielle", très intéressante

Omographie? Qu'est-ce que c'est? Mon dico ne connait pas, wikipedia non plus.
http://fr.wiktionary.org/wiki/homographie

Heu exact, ma francisation du terme n'est pas très judicieuse : le terme est "Homography" que j'ai repris de ce document-là en anglais.

Pareil pour le terme "inversement de la perspective". Ca veut dire quoi?

Pour l'inversement de la perspective, un fois que la camera est calibrée, on obtient une matrice qui permet de transcrire la projection 2d d'un point de l'image en rayon 3d (dans un moteur 3d, on utilise la matrice de projection qui transforme un point 3d en 2d sur la surface de projection... d'où l’inversement de projection ).

Quel type de capteur d'angle, et qui mesure quoi?

Sur le HTC Desire, il y a un capteur d'angle (3 axes), une boussole (1 axe, mais pas dans le "bon sens" : il faut tenir le téléphone à plat et à l'horizontal, ce qui n'est pas ideal pour utiliser la camera ) et un gyromètre (3 axes).
Pour le moment, je récupère les infos brutes des capteurs mais je n'en fait rien.

Sinon, encore une fois, pourquoi ne pas utiliser d'odométrie pour savoir de combien ton robot s'est déplacé?

Et bien, parce que le déplacement du robot lorsqu'il est en rotation n'est pas du tout "précis", il glisse et dérape selon le revêtement, ce qui fausserait la mesure
En fait, la plateforme est "4x4" (4 moteurs indépendants) mais la carte Roméo ne gère que deux moteurs donc, j'ai du les brancher par paire (fonctionnement comme les chenilles d'un char).
Si c'est vraiment handicapant, je verrais pour ajouter un capteur infrarouge sur une des roues (si il me reste de la place au niveau des entrées de la carte, je commence a être un peu juste...).

[NooTe]

Bonjour,

Un petit update pour monter l'avancement du projet.
La première version appelé RemoteControl.
Une application Android qui prends le contrôle a distance de Roby via Bluetooth.
Roby est désormais équipé d'un kit Bluetooth et d'un capteur de distance Infrarouge (malheureusement défectueux ) accroché à la tourelle.



J'attends un nouveau Sharp GP2Y0A02YK (20 à 150cm) de pied ferme pour continuer a travailler sur le "radar" en voxel.
J'ai aussi commandé un sonar Ultrasonique SeeedStudio qui sera lui aussi placer sur la tourelle (3cm a 6m).

Voila un screenshot de l'interface

A gauche : le virtualpad de commande du corps de Roby
Au centre : la distance du capteur IR (en cm)
A droite : le virtualpad de commande de la tourelle

Prochaine étape :
Une application Android tournant sur l'observateur qui reliera en Wifi le smartphone, accroché dans sa magnifique tourelle en carton (bientôt refaite en alu et plexiglas).

Les sources et l'appli Android, ainsi que le sketch Arduino, sont joint dans le fichier joint Roby RemoteControl v0.1.zip.

Fichier(s) joint(s)

•  Roby RemoteControl v0.1.zip   357,32 Ko   239 téléchargement(s)

[Astondb8]

Bonjour,

Un petit update pour monter l'avancement du projet.
La première version appelé RemoteControl.
Une application Android qui prends le contrôle a distance de Roby via Bluetooth.
Roby est désormais équipé d'un kit Bluetooth et d'un capteur de distance Infrarouge (malheureusement défectueux ) accroché à la tourelle.



J'attends un nouveau Sharp GP2Y0A02YK (20 à 150cm) de pied ferme pour continuer a travailler sur le "radar" en voxel.
J'ai aussi commandé un sonar Ultrasonique SeeedStudio qui sera lui aussi placer sur la tourelle (3cm a 6m).

Voila un screenshot de l'interface

A gauche : le virtualpad de commande du corps de Roby
Au centre : la distance du capteur IR (en cm)
A droite : le virtualpad de commande de la tourelle

Prochaine étape :
Une application Android tournant sur l'observateur qui reliera en Wifi le smartphone, accroché dans sa magnifique tourelle en carton (bientôt refaite en alu et plexiglas).

Les sources et l'appli Android, ainsi que le sketch Arduino, sont joint dans le fichier joint Roby RemoteControl v0.1.zip.

Jolie... et merci pour le code

Malheureusement, je n'ai rien sous Androide...;(
Donc impossible de tester cette superbe interface

Mais bon ça va faire des heureux c'est sur...

[NooTe]

Bonjour a tous,

Il y a plusieurs projets sous Android et à base de carte-controleur Arduino dans le forum, j'en profite pour faire un update de l'avancement du module "RemoteRobot" version 0.2 de Roby.

Dans ce qui se voit :
- une interface remanié : plus complète, gestion de la vitesse des moteurs, la tourelle est contrôlée par un "pad analogique"
- le scanning : via deux modes en ligne et en mode radar avec deux options.
Un point de scan est la moyenne de 5 prises de capteur à 5 ms d'intervalle, 25ms au total plus le temps de déplacement de la tourelle.
Le mode en ligne scanne la ligne d'horizon (1 dimension).
Le mode radar scanne un zone (2 dimensions).
Option "1/2" de la surface de fonctionnement : l'amplitude de la tourelle passe de 160° a 70° horizontalement, et de 60° a 35° verticalement;
Option "Qik" qui scanne par pas de 5° à la place de 1°, ce qui permet d’être beaucoup plus rapide en scanner mais moins précis à l'affichage.
Le dégrade de bleu indique la profondeur (de 30 a 150cm, bleu vers noir), le gris indique la limite minimum atteinte par le capteur IR.
- les switches s'affichent lorsqu'ils rencontrent un obstacle à moins de 15cm (une zone rouge aux quatres coins s'affiche selon les switches affectés).

Dans ce qui ne se voit pas :
- la stack protocolaire BlueTooth entièrement revu (plus sur en cas d'interference ou de perte de données partielles)
- amélioration du core arduino (ajout du code de scan et du code de déplacement non utilisé pour le moment)

Je ne release pas les sources pour le moment : il reste encore deux ou trois bugs au niveau de l'interface et dans le core arduino.
Voila deux screenshots pour faire patienter

La même scène vue par :
le mode "scan en ligne" rapide
le mode "radar" rapide :

Pour la suite (version 0.3), je vais ajouté le sonar pour avoir une distance jusqu’à 6 mètres (dès que la mesure de l'IR sera plus grande que 130cm, hop je switche sur le sonar... moins précis et moins rapide).
Et finir l’odomètre basé sur le temps d'activité des moteurs de propulsion (malheureusement pas très précis car dépendant de l’énergie disponible des piles).

Et lorsque que tout sera stabilisé, je passerai enfin au module "Cerveau + Observateur" (avec un peu de chance ^^).

J'en profite pour demander si quelqu'un sait comment faire pour connaitre le niveau des piles a partir de la carte DFRobot Romeo.
Ou si il y a un montage facile a faire pour avoir le status de l’énergie disponible.
J'envisage de passer sur une batterie type "modélisme" ou batterie de téléphone portable à la place des 5 piles de 1.5v.
Est-ce qu'il est préférable de garder les piles pour l'alimentation des moteurs et un batterie pour les servos et la carte contrôleur ? ou trois batteries ?

Et je suis preneur pour un odomètre par cher (il ne me reste que 3 pins analogiques ou le port I2C), si vous avez des idées (soit un truc tout fait, soit à bricoler).

[Black Templar]

Beau résultat !

Et finir l'odomètre basé sur le temps d'activité des moteurs de propulsion (malheureusement pas très précis car dépendant de l'énergie disponible des piles).

Que veux tu dire par là ?? Un odomètre te permet de compter le nombre de tours de roue. Où vient faire le niveau de batterie là dedans ??

J'en profite pour demander si quelqu'un sait comment faire pour connaitre le niveau des piles a partir de la carte DFRobot Romeo.

Au plus simple : un pont diviseur de tension de ta batterie pour avoir au maximum du 5V en sortie. Cette sortie, tu la plug sur une pin analogique de l'arduino et tu mesures la tension.
Si tu as une batterie délivrant 1V chargé au max, tu fais un pont diviseur pour avoir du 5V en sortie. En cours d'utilisation, si tu mesure 4V, ça veut dire que la batterie est à 9.6V par exemple

Ou si il y a un montage facile a faire pour avoir le status de l'énergie disponible.
J'envisage de passer sur une batterie type "modélisme" ou batterie de téléphone portable à la place des 5 piles de 1.5v.
Est-ce qu'il est préférable de garder les piles pour l'alimentation des moteurs et un batterie pour les servos et la carte contrôleur ? ou trois batteries ?

Et je suis preneur pour un odomètre par cher (il ne me reste que 3 pins analogiques ou le port I2C), si vous avez des idées (soit un truc tout fait, soit à bricoler).

Aucune idée,

++
Black Templar

[NooTe]

Beau résultat !

Merci

Que veux tu dire par là ?? Un odomètre te permet de compter le nombre de tours de roue. Où vient faire le niveau de batterie là dedans ??

Je travaille sur un odometre "virtuel" : suivant le temps d'activité d'un moteur, j'estime le nombre de "tour" effectué.
Avec les deux moteurs, ca me permet de savoir dans quelle direction et sur quelle distance va mon tank.
Le problème, c'est qu'avec le temps, les moteurs, les servos (et tout le bazar) consomment l’énergie des piles, et donc leur vitesse diminue avec le manque de "watt". Or je n'ai pas cette information là mais tu m'as donnée la solution dans ta reponse suivant .

Au plus simple : un pont diviseur de tension de ta batterie pour avoir au maximum du 5V en sortie. Cette sortie, tu la plug sur une pin analogique de l'arduino et tu mesures la tension.
Si tu as une batterie délivrant 10V chargé au max, tu fais un pont diviseur pour avoir du 5V en sortie. En cours d'utilisation, si tu mesure 4V, ça veut dire que la batterie est à 9.6V par exemple

Ah pile poil ce qu'il me faut, je n'y ai pas penser
Mais, heu... question bête : la puissance des 5 piles de 1.5v ne risque pas d’endommager les résistances (je n'ai que des 1/4 watts en stock) ?

[Black Templar]

Je travaille sur un odometre "virtuel" : suivant le temps d'activité d'un moteur, j'estime le nombre de "tour" effectué.
Avec les deux moteurs, ca me permet de savoir dans quelle direction et sur quelle distance va mon tank.

Arrrrg... crise cardiaque
En gros, tu travailles en boucle ouverte totale ! Si ton robot est sur une pente ascendante ou descendent, pour la même puissance consomé par le moteur, celui-ci tournera plus ou moins vite :/
Tout ce que tu peux avoir avec cette méthode, c'est une estimation grossière et erroné de la position de ton robot sur du court terme uniquement...

Il vaut mieux mesurer le nombre de tour de roues réellement avec un odomètre fixé sur l'arbre moteur (avant le réducteur pour plus de précision)

Ah pile poil ce qu'il me faut, je n'y ai pas penser
Mais, heu... question bête : la puissance des 5 piles de 1.5v ne risque pas d'endommager les résistances (je n'ai que des 1/4 watts en stock) ?

Et bien il suffit de dimensionner ton pont diviseur de tension pour ne pas que la puissance soit trop élevé !!

P = U.I
I = U/R
R = R1+R2

Le tour est joué

[NooTe]

Arrrrg... crise cardiaque
En gros, tu travailles en boucle ouverte totale ! Si ton robot est sur une pente ascendante ou descendent, pour la même puissance consomé par le moteur, celui-ci tournera plus ou moins vite :/
Tout ce que tu peux avoir avec cette méthode, c'est une estimation grossière et erroné de la position de ton robot sur du court terme uniquement...

Il vaut mieux mesurer le nombre de tour de roues réellement avec un odomètre fixé sur l'arbre moteur (avant le réducteur pour plus de précision)

Heu, en fait, je cherchais une solution "temporaire"... car je comptais me servir de l'accelerometre du telephone mobile pour estimer les distances et directions parcourus... mais dans l'application "RemoteRobot", le mobile n'est pas (encore) solidaire du robot
Et je viens de voir que les moteurs/reducteurs dans le chassis DFRobot 4AWD ne peuvent pas recevoir d'encodeur...
J'ai vu un accelerometre a 15€, est-ce que ca sera plus fiable que la "boucle ouverte totale" ?

[Black Templar]

Salut !

Heu, en fait, je cherchais une solution "temporaire"... car je comptais me servir de l'accelerometre du telephone mobile pour estimer les distances et directions parcourus... mais dans l'application "RemoteRobot", le mobile n'est pas (encore) solidaire du robot
Et je viens de voir que les moteurs/reducteurs dans le chassis DFRobot 4AWD ne peuvent pas recevoir d'encodeur...
J'ai vu un accelerometre a 15€, est-ce que ca sera plus fiable que la "boucle ouverte totale" ?

Le problème de l'accéléromètre, c'est que ça te donne une accélération. Pour obtenir une position, il te faut intégrer 2 fois. Ce qui implique donc une dérive très forte... A mon avis, (je n'ai pas encore testé), ça me semble dur d'obtenir des résultats précis sur le long terme... mais à tester, il se peut que l'on soit surpris par les performances (si tu prend une fréquence d'échantillonnage suffisamment élevé...)

++
Black Templar

[NooTe]

Bonsoir a tous,

Voici les sources de la version 0.2 du module RobotRemote de Roby

Je vous joins aussi un scan de la même scène mais avec toutes les modes différents

Le scan radar angle large détaillé (Le plus "impressionnant" et le plus complet : 8 minutes et 45 secondes de scan)

Le meme scan en rapide (on saut de 5 en 5 pour la prise de captation en hauteur et en largeur : soit x25 moins "précis"... temps 45 secondes)

Le scanline plan large détaille (40 secondes)

Le scanline large rapide (12 secondes)


le scan radar angle court détaille (6 minutes)

le scan radar rapide (30 secondes)

le scanline détaille (9 secondes)

le scanline rapide (4 secondes)

Fichier(s) joint(s)

•  Roby RobotRemote 0.2.zip   278,2 Ko   211 téléchargement(s)

[Black Templar]

Jolies résultats !
Merci d'avoir partagé tes sources

[NooTe]

Une mise a jour rapide sur l’évolution de l'engin.

J'ai fait plusieurs changement sur la base Arduino du robot :
- la première modification, la plus notable pour un oeil averti, "exit la tête en carton, et bonjour la tête en plexy". Le tout est nettement plus rigide et permet de faire des scans radar plus précis.
La tourelle mobile (la tête donc) reçoit en plus un capteur UltraSon SeeedStudio qui permet maintenant d'avoir une estimation de distance jusqu'à 6 mètres. J'ai gardé le capteur IR beaucoup plus précis et rapide pour les distances entre 25cm et 140cm.
- la caisse du robot a été remaniée elle aussi. j'ai supprimé les switchs InfraRouge de devant et remplacer par un capteur IF, j'ai déplace l'un de ces switchs vers l'arriére (qui compte maintenant 3 switchs IR).
- J'ai suivi le conseil de BlackTemplar en ajoutant des encodeurs sur les roues avant (maintenant je connais la distance parcourue par le robot), ainsi qu'en ajoutant une boussole (avec accéléromètre) ce qui me permet de savoir dans quelle direction pointe la caisse du robot.
- j'ai aussi ajouté un LCD 2x20 pour des diagnostiques internes (sans avoir a connecter le téléphone par Bluetooth).
- et le problème d'alimentation a été réglé par l'ajout d'une batterie supplémentaire dédiée aux servos.

Encore quelques évolutions matérielles sont au programme :
- une seconde tête en plexy va être réaliser pour recevoir le téléphone et donc de pouvoir utiliser les images de la camera ainsi que les capteurs (GPS...) de celui-ci.
- le capteur IR frontal devrait etre changer par un capteur à portée plus courte (comme le GP2D120 IR Sharp de 4 à 30 cm ou le GP2Y0A21YK0F de 10 a 80cm... actuellement c'est un GP2Y0A02YK0F de 30 à 150cm qui est utilisé).
- trouver une boussole I2C plus réactive que celle que j'ai prise (Deventech CPMS10, qui est trop lente à mon gout, presque 2 secondes pour avoir un "cap" fiable, peut être dût à un problème d’étalonnage).

A part quelque soudures pour améliorer les liaisons (carte bluetooth) et protéger les encodeurs (le bumper avant de la caisse ne rentre plus, il faut supprimer les pins en soudant directement), je pense que je "tiens", grosso-modo, la base matériel du robot (de toute façon, je suis arriver au bout de toutes les entrées de la carte Roméo ).

Grâce aux encodeurs et à la boussole, j'ai tout ce qu'il faut pour commencer le logiciel de cartographie et de la partie AI qui rendra le robot autonome !

Une photo de la bête

[Mike118]

Franchement un projet super chouette ! Du beau boulot et tout !

Tu en es où maintenant ? Il est fini ?

PS : le précision de la boussole incluse dans Le HTC désire elle suffisait pour répondre à ton besoin ? ( je sais qu'elle était pas dans le bons sens mais comme cette partie là est mobile ... )

[NooTe]

Franchement un projet super chouette ! Du beau boulot et tout !

Merci

Tu en es où maintenant ? Il est fini ?

Il est en standby pour le moment... je suis sur un nouveau projet (Shaky : robot biped que je présenterai un peu plus tard).

Le dernier statut de Roby :
- les encodeurs ne fonctionnent pas correctement (j'imagine que j'ai encore grillé une partie de la carte arduino)
- la partie protocole de donnée entre le bluetooth et le WiFi qui etabli le lien entre le telephone et la tablette Android (ou ordinateur). j'ai encore quelques bugs.

J'ai donc etabli le lien bluetooth entre la carte arduino et le telephone, et le lien wifi entre le telephone et la tablette.
Je transfert le GPS+Camera (MJPEG) du telephone (installé sur la tourelle) en plus des données de la carte arduino.
Je suis encore loin de ce que je voulais obtenir : pas d'IA, pas de cartographie (il faut que je repare les encodeurs pour ca), debit video trop lent, detection des lignes trop lentes.
Je ne suis plus motivé (d'ou le nouveau projet ).

PS : le précision de la boussole incluse dans Le HTC désire elle suffisait pour répondre à ton besoin ? ( je sais qu'elle était pas dans le bons sens mais comme cette partie là est mobile ... )

Je n'ai pas utilisé la boussole du HTC, mais un module arduino avec accéléromètre et boussole compensé... qui malheureusement est beaucoup trop lent (presque qu'une demi-seconde pour avoir la cap).

[Mike118]

Merci


Il est en standby pour le moment... je suis sur un nouveau projet (Shaky : robot biped que je présenterai un peu plus tard).

Le dernier statut de Roby :
- les encodeurs ne fonctionnent pas correctement (j'imagine que j'ai encore grillé une partie de la carte arduino)
- la partie protocole de donnée entre le bluetooth et le WiFi qui etabli le lien entre le telephone et la tablette Android (ou ordinateur). j'ai encore quelques bugs.

J'ai donc etabli le lien bluetooth entre la carte arduino et le telephone, et le lien wifi entre le telephone et la tablette.
Je transfert le GPS+Camera (MJPEG) du telephone (installé sur la tourelle) en plus des données de la carte arduino.
Je suis encore loin de ce que je voulais obtenir : pas d'IA, pas de cartographie (il faut que je repare les encodeurs pour ca), debit video trop lent, detection des lignes trop lentes.
Je ne suis plus motivé (d'ou le nouveau projet ).


Je n'ai pas utilisé la boussole du HTC, mais un module arduino avec accéléromètre et boussole compensé... qui malheureusement est beaucoup trop lent (presque qu'une demi-seconde pour avoir la cap).

Dommage que le robot soit en stand bye il semblait être très intéressant !
Par contre si 0,5s c'est trop lent pour toi ne parlons pas de la solution que j'avais imaginé x) ( utiliser le pan/tilt pour orienter la boussole du HTC dans le bons sens au moment ou tu voulais une mesure du cap x) mais inenvisageable dans ton cas je pense vu que 0,5s c'est déjà trop long x) )

Bref en tout cas bonne continuation quoi que tu sois en train de faire