Aller au contenu


sky99

Inscrit(e) (le) 05 avril 2013
Déconnecté Dernière activité août 19 2018 12:18
-----

#57471 Mini robot très compact et autonomie très importante

Posté par sky99 - 14 août 2013 - 08:03

Salut!
Désolé du délai de réponse ^^
Ma méthode repose sur deux points : les spécifications constructeur/documentations/recherches et des mesures.
En pratique, quand je parle de la conso du Atmega par exemple, c'est que je connais sa conso pour certaines tensions données,
à certaines fréquences.

Dans d'autres cas, je me base sur les données constructeur, qui indiquent par exemple x mA à 5V au max, donc je sais que j'aurai
cette conso au maximum. Du coup je surévalue parfois la conso, mais je pars justement toujours sur des valeur surévaluées si
je ne peux pas être précis pour avoir au final plus d'autonomie que prévu plutôt que le contraire :)

Par exemple pour mes moteurs, je sais que le courant de charge maximale est de 360mA, quand les moteurs sont bloqués.
Du coup, si le robot se déplace, c'est qu'il est en dessous du courant max de blocage, donc je sais que chaque moteur
consommera en réalité moins de 360mA.

Partant des données du couple, par exemple 1kg-cm, si j'ai des roues de 2cm, ça fait un couple de 500g. On peut donc
faire une estimation un peu à la louche, en disant que le moteur peut pousser une charge de 500g. En pratique, il peut pousser davantage,
car le poids s'exerce à la verticale, perpendiculairement, donc du coup il faut moins que 500g force pour déplacer 500g si on a une platforme roulante
(bien sur le frottement n'est pas non plus trop important).

Bref, si j'ai 2 moteurs, on dira donc 1kg de poussée, pour une masse de 200g, donc 1/5 de la charge max. Du coup je m'attends à avoir au plus
360*2/5=144mA, en sachant que c'est probablement surévalué pour un terrain plat.

Jusqu'à il y a peu, j'ai procédé ainsi, avec les imprécisions que ça apporte, car je n'avais pas d'ampèremetre. J'en ai maintenant un précis
jusqu'aux µA, donc du coup je peux mesurer la consommation typique attendue. Ce que je fais dans ce cas, c'est:

-mesurer la conso globale de la plateforme lors de l'activation de tous ou un sous ensemble des systèmes du robot
-et surtout mesurer la conso en charge de chaque sous système dans des conditions précises.

Par exemple, pour mon module radio 433mHz, j'ai fait un programme qui balance en continu des données, et je mesure la conso. Bien sur, ça fluctue, mais
on a pas des variations du genre 1mA puis 2mA. En général les variations sont plutôt du genre passer de 29 a 31mA, bref quelques pour cents. Dans ce cas,
je mesure le courant pendant un temps, et je garde la valeur la plus importante mesurée.

Pour cela je place mon ampèremètre en série, mais sur le +vcc du composant, ce qui me permet d'avoir sa conso exacte.
Selon les mesures, ça me donne des "classes" de conso. Si tous mes composants sont de l'ordre de quelques mA, et que j'ai un composant qui consomme des µA, alors celui ci sera dans la classe "négligeable". A moins que les autres composants tournent de façon sporadique, alors que celui la tourne en continu.

Maintenant, il faut savoir que la conso des composants dépend de la tension d'alimentation. La plupart du temps, un composant consommera moins à 3.3V qu'a 5V. Du coup avec une alimentation variable, je pars de la tension max. Par exemple pour une batterie LiIon non régulée, je mesure quand elle est chargée au max, donc a 4.2V. Cependant, la tension typique sera 3.7V, donc j'aurai en réalité une conso plus basse.
Pour le ATmega, j'ai des infos très précises provenant d'un super article de nick gammon que j'ai déja linké (et j'ai fait une version FR dans l'un des blogs sur ce site) qui donne plein de valeurs précises.

Pour les raisons, l'idée c'est aussi de pouvoir avoir une conso maîtrisée pour obtenir une autonomie réellement utile. Je trouve qu'un robot qui a 30 minutes d'autonomie, c'est bien pour un concours, ou des situations bien précises. Mais moi je suis intéressé par l'idée d'employer des robots pour faire des tâches en continu.
Donc déjà deux points :
-si j'ai un robot qui a une conso moyenne de 1Ah, avec une batterie liIon de 6Ah, j'ai bien sur 6h d'autonomie théorique, mais surtout je sais que je passe moins de temps en charge qu'en fonction. Si je charge a 2A, 1h de charge me donne 2h d'autonomie. Du coup je suis content, car je trouve insupportable de charger 12h pour avoir 30 minutes d'autonomie.
-Plus l'autonomie entre les charges est importante, moins il faut de robots pour avoir un service permanent. Si j'ai 8h d'autonomie, il me faut 3 charges pour faire 24h. Donc à moins de pouvoir s'assurer de recharger plus vite que je ne décharge, il me faudra 3 robots. Si je charge en moins de 8h, alors il me suffit d'en avoir 2.

Maintenant, si j'ai une conso négligeable devant la capacité de ma batterie, je peux me débrouiller pour avoir une charge très courte fournissant une grosse autonomie.
Ce robot par exemple, je peux le charger à 1A. Du coup, s'il consomme 100mA, j'ai 10h d'autonomie pour 1h de charge, et comme il consomme moins, ça veut dire qu'avec une courte charge je peux me débrouiller pour tenir facilement une journée.

Autre point, sur les très basses conso : si la conso est assez faible, je peux me débrouiller pour avoir une charge par panneau solaire PENDANT l'utilisation du robot. Du coup si le robot a un panneau solaire suffisant, il peut avec une journée de charge emmagasiner assez d'énergie pour un ou plusieurs jours sans soleil. Du coup, je me retrouve avec un robot toujours chargé, pouvant travailler sans interruption.

Enfin, il y a des aspects économiques et donc logiquement écologiques. Plus la conso est faible, plus la batterie dure longtemps, on est bien d'accord. Maintenant
ça implique que je fais moins de cycles de charge-décharge. Si ma batterie est donnée pour 300 cycles, si j'ai 8h d'autonomie, ça veut dire que la batterie sera
morte en seulement 100j. Si je passe à 24h, ça passe à 1an. 48h, 2ans. Changer une batterie au lithium tous les deux ans, c'est pas excessif, et je parle d'un robot qui fait une tache 24h/24, 7j/7, 365j/an.

Du coup si c'est plus économique, je dépense moins pour acheter des batteries, certes, mais mieux encore, je produis moins de déchets.
Donc si on parle du cout écologique, j'ai consommé moins d'énergie, donc moins d'émissions de co2, de rejets nucléaires ou autres, si on a pas d'énergie renouvelables,
mais surtout je coute moins à l'environnement, car je ne cause pas la production d'une batterie lithium. Ce n'est pas tout à fait vrai, mais si on fait tous ça, la demande baisse, donc la production aussi, et on pollue moins en production. Mais surtout je jette moins de batteries. Et quelle que soit la qualité du circuit de recyclage, je parie qu'il y a de la pollution avec ces produits chimique qui passe entre les mailles. Et si pas de recyclage, ça évite de mettre du lithium dans une décharge. Même en cas de recyclage complet, ça a un coût en transport, énergie de retraitement, etc...

Bref, sur le plan écologique, il y a souvent des conséquences indirectes plus importantes que les conséquences directes. Ainsi le cout de retraitement des déchets sera sans doute inférieur au cout de l'énergie gaspillée par un design gourmand :)

Enfin, moins de conso, ça veut dire plus d'autonomie, certes, mais aussi, si je consomme moins, j'ai plus d'énergie dispo pour intégrer tel ou tel module si besoin est :)


#56021 Mon projet

Posté par sky99 - 09 mai 2013 - 02:11

Salut sky99 :crigon_03:/>/>/> ;j'ai une question,tu m'avais dit:"en prennant un couple émmeteur-récepteur ;
(
-un émetteur : 3,50 euros.
http://snootlab.com/147-emetteur-rf-434-mhz.html
-un récepteur:3,50 euros.
http://snootlab.com/composants/145-recepteur-rf-434-mhz.html
.)il ne te manquera plus qu'à prendre un microprocesseur de ton choix et autant de bouton que de fonction."Mes questions;


[1]est-ce qu'il faut que je prenne un mprocesseur pour l'emmeteur et un autre pour le récepteur ?(je pense que oui)Est-ce qu'il faut que ce soit les mêmes ?

Oui, il faut un micro-contrôleur de chaque coté, et non, ça n'a pas besoin d'être le même. Après si tu as deux puces de la même famille, ce sera plus
simple, car les deux se programmeront de la même façon. Maintenant, si tu trouves un récepteur adapté à une télécommande du comerce (donc capable
de lire/décoder les fréquences envoyées par ce type de télécommandes), tu peux te contenter d'une télécomande avec plein de boutons, et d'un récepteur connecté
à un micro-contrôleur.


[2]Et donc l'arduino sert juste à faire en sorte à ce que le mprocessur puisse être connecté à l'ordinateur,tu confirme ?

Non, l'Arduino sert à ce que tu veux en faire. Dans ce cas précis, un Arduino pourrait servir de "cerveau" à ta télécommande, pour émettre des signaux selon tes appuis, et un autre
de "cerveau" au robot. L'intérêt d'un Arduino, c'est que c'est programmable, tu peux en faire à peu près ce que tu veux. Et si ça ne te plait pas, tu peux le reprogrammer à volonté.

[3]à part que l'arduino uno est utilisé pour l'émmeteur et l'arduino pour le récepteur ,qu'est-ce qui les différencie ? On est obligé de prendre les deux ?Peut-on les inverser ?

Arduino, c'est une marque. Donc le Arduino uno EST un Arduino. Dans les Arduino, tu as le Arduino Uno, Mega, Duemillanove, etc... Le Arduino Uno est une carte qui vaut 15-20€, qui embarque
un micro-contrôleur Atmel , avec divers composants qui permettent d'accéder facilement aux entrées sorties de la puce centrale. En pratique, ça se programme avec le logiciel Arduino (oui,
le logiciel qui permet de programmer à aussi le même nom :)/> ), et le code est écrit de la même façon d'un modèle à l'autre. Il y a de petites différences entre les divers modèles,
mais tous pourront faire ce que tu veux. En pratique, le Arduino Uno ira très bien :)/> (c'est un peu le modèle "standard").

[4]Tu te souviens de ma théorie :close_tema:/>/>/> :king:/>/>/> :close_tema:/>/>/> sur mon émmeteur-récepteur suite à la vidéo de incroyable expérience ;penses-tu que si je mets un micro processeur sur l'emmeteur et sur le récepteur ça fonctionnera,sans rien rajouter ?Ensuit il faut savoir où relier les bornes du mprocesseur .Merci à toi et à tous les autres de me répondre :help:/>/>/> et de m'avoir répondu jusque là,vous êtes géniales les gars !

Je ne connais pas la vidéo dont tu parles. Mais si tu as un micro-contrôleur de chaque coté, et un système d'émission/reception commandé par ces puces, tu peux faire à peu près ce que tu veux, tant qu'il n'y a pas d'intérférences (d'autres personnes utilisant la même fréquence au même moment).


#55950 Projet robot

Posté par sky99 - 05 mai 2013 - 11:13

Bonjour!
Jettes un oeil a mon tuto sur un robot Raspberry Pi, il te fournira une base capable par la suite assez facilement d'ajouter une webcam USB (donc super simple à brancher), et de la synthèse vocale par quelques logiciels.

La base est un robot simple, à évitement d'obstacles, et j'ai prévu le tutoriel pour qu'en partant de rien, sans aucune compétence, il soit possible de faire fonctionner
le robot; tous les composants sont présentés, détaillés, et leur utilité expliquée, et tous les branchements sont expliqués.

C'est mon premier robot Raspberry Pi, et peut être mon second ou troisième robot au total, donc je l'ai réalisé à une époque ou j'étais quasi débutant.
Bref, si je l'ai fait, tu peux le faire :)

Sinon, un point sur la peur de se lancer : n'hésites pas, j'ai longtemps hésité, et je me suis rendu compte que c'est loin d'être aussi complexe que ce qu'on imagine.
Si bien sur tu te lances dans un projet d'hexapode avec auto stabilisation par accélérometres et gyroscopes, ou d'autres trucs du genre, ce sera plus ardu.
Mais un robot à roues, qui évite les obstacles, c'est très facile à faire, je dirais qu'en ayant le matériel, et en ayant préparé ce qu'il faut, c'est l'affaire
d'une ou deux après-midi.

Pour ma part ça a été plus long, car j'ai d'abord exploré chaque composant, et fait un tutoriel dessus, du coup je n'ai pas avancé super vite. Mais par la suite j'ai fait un robot en à peine 2h, sur le même modèle.

Bref, je te dirais : lances toi! Depuis que je l'ai fait, ça m'a ouvert de nouvelles portes, et plein de choses me paraissent bien plus simples; sans compter que c'est une grande joie de fabriquer des bidules qui interagissent avec le monde réel ;)


#55916 Mon projet

Posté par sky99 - 05 mai 2013 - 12:56

oO !

Tu ne veux pas passer par la programmation en fonction des signaux d'un émetteur/récepteur (ce qui est a priori la solution la plus connue et la plus simple), mais tu nous sors un système de transmission par induction ? C'est le monde à l'envers ...

Reprenons du début. Tu as une voiture télécommandée, avec une manette qui comporte N boutons. L'appui sur ces boutons permet de faire avancer/reculer/aller à droite/aller à gauche la voiture. Jusque là, pas de souci.
Le "Hack" que tu fais jusqu'à présent, c'est, sur la voiture, d'enlever les actionneurs (les éléments qui font l'action, les moteurs pour la voiture) pour les remplacer par les actionneurs que tu veux (LED, moteur ou autre). Du coup, quand tu appuies sur avancer, les câbles qui correspondent aux moteurs commandés pour faire avancer la voiture sont passants. Effectivement, c'est malin et ça peut marcher, à condition de faire attention à ce que tu connectes à la place des moteurs : il y a de fortes chances que la propulsion de la voiture soit reliée sur un circuit de puissance, qui envoie un ampérage fort au travers d'un transistor ou un pont en H. Si tu remplaces ton moteur par une simple LED ou un composant qui fonctionne à bas ampérage, tu risques de le cramer. Inversement, si tu branches un composant gourmand en courant (moteur) sur une sortie du circuit de la voiture qui est prévue pour envoyer un signal de commande (à un servomoteur par exemple), il est probable que ton moteur n'arrive pas à bouger.
Maintenant, ce qu'il se passe vraiment entre ta télécommande et ta voiture, c'est que la télécommande envoie un code (par infrarouge, par radio, etc.) qui dépend du bouton ou de la combinaison de boutons sur laquelle tu appuies. Ce code est reçu par le récepteur de la voiture, qui sait comment les interpréter. En conséquence, la carte de contrôle de la voiture pilote les actionneurs de la voiture pour lui faire faire ce qui est prévu.
Par exemple, tu appuies sur le bouton "Haut" de ta télécommande, qui est programmée pour envoyer le code hexadécimal "0xA7" par infrarouge lorsque son bouton "Haut" est pressé. La voiture réceptionne un signal infrarouge et lit ce qu'il y a dedans : "0xA7" (et peut-être d'autres données nécessaires au bon fonctionnement du système, comme des identifiants pour ne répondre qu'à une seule manette). Le microprocesseur dans la voiture a été programmé pour que s'il reçoit "0xA7" de la part d'une télécommande, il actionne ses deux moteurs de propulsion pour avancer tout droit. Il se trouve que c'est le plus logique pour nous, êtres humains : appuyer sur la touche "haut" d'une manette à 4 boutons en croix correspond à l'idée "avancer" quand il s'agit de piloter une voiture. Mais en fait, on pourrait très bien imaginer les choses différemment : la réception par la voiture du code qui correspond à l'appui sur le bouton "Haut" sur la manette pourrait très bien la faire tourner à droite. Ou l'arrêter. Ou allumer les phares. Ca revient à faire ce que tu veux faire en changeant les actionneurs de ta voiture ...

... sauf que pour ajouter des fonctionnalités, tu dois ajouter une télécommande et le circuit de réception correspondant. Alors qu'en reprogrammant les microprocesseurs de la manette et de la voiture (ou en mettant ton propre micro), tu peux définir toi-même autant de codes à envoyer que tu veux, avec les actions que tu veux. Il faut bien évidemment relier le microprocesseur de la voiture aux actionneurs que tu veux piloter au travers des bons composants, et connecter les boutons supplémentaires sur le microprocesseur de la manette. Les deux manières ont a priori le même but, et demandent autant de travail, mais la méthode "programmation" est à mon avis plus propre, plus flexible et plus robuste. Admettons que tu aies une manette où toutes les entrées du microP sont prises par des boutons, mais que tu veuilles rajouter encore des fonctionnalités : en ayant accès au code du microP, tu peux gérer des combinaisons de boutons sans avoir besoin de rajouter du matériel. Alors qu'agglutiner une troisième manette sera peu pratique et demande de rajouter encore un circuit complet de réception et commande. Pour éventuellement piloter les mêmes actionneurs, ce qui peut être problématique en termes de gestions des courants.

Si j'insiste sur cette méthode, ça n'est pas (que) pour en faire l'apologie (:)/>), c'est juste que ça me semble beaucoup plus intéressant et source d'apprentissage pour ton projet de comprendre VRAIMENT ce qui se passe que de rester sur un hack qui reste limité. Tu as été capable de faire ce hack, tu es probablement capable de passer à l'étape d'après. Après, tu es libre de faire ce que tu veux.

C'est ce que j'essayais de dire, sans y parvenir clairement depuis le début :)

Et au passage, j'ajouterais qu'avec deux trois composants et un arduino on s'en sort pour pas cher en pièces!


#55880 robot de combat

Posté par sky99 - 02 mai 2013 - 08:49

Voilà un plan simplifié de mon robot.Les 2 batteries (les mêmes) sont de 6v et 6 Ah.
Et merci pour ton site sky99;je suis entrain d'y jeter un coup d'oeil.

Certes, c'est un plan, mais je ne vois pas le circuit de commande de tout ça!
Tu utilises quoi comme circuit pour faire fonctionner les moteurs?
La scie c'est simple, puisqu'elle n'a besoin de tourner que dans un sens.

Mais pour les moteurs, il faut un double pont en H! Sauf si tu récupères le circuit qui va avec le moteur dans un jouet...
Mais il faut quand même pouvoir envoyer diverses commandes aux circuit de commande, dans tous les cas.


#55874 robot de combat

Posté par sky99 - 02 mai 2013 - 06:36

A mon avis, ça sera bien plus compliqué de modifier le circuit que d'en refaire un.
ça voudrait dire que tu sois capable de reprogrammer le µC de la radiocommande, et du récepteur,
pour qu'ils soient capable d'emettre/comprendre de nouveaux signaux.

Quand au matériel de récupération, soit, mais il faudra quand même pouvoir reprogrammer le µC pour ajouter des boutons, etc...

Je dirais qu'il doit être possible de de récupérer les circuits radio d'une radiocommande et de la voiture qui va avec, mais il faudra bien les brancher sur un µC.
Après il faudra trouver les specifications des composants, et vu qu'on peut trouver un couple emetteur-recepteur pour quelques euros, je pense que c'est plus simple de s'en prendre un...

Par exemple
http://snootlab.com/composants/147-emetteur-rf-434-mhz.html
http://snootlab.com/composants/145-recepteur-rf-434-mhz.html

ça fait 7€, et avec un µC de ton choix, c'est facile à utiliser, et tu peux mettre autant de commandes que souhaité, au prix d'un bouton poussoir et d'une résistance à chaque fois... Avec la possibilité d'avoir des joysticks analogiques, potentiometres, encodeurs rotatifs, etc...


#55867 robot de combat

Posté par sky99 - 02 mai 2013 - 05:26

Je pense qu'il faut que tu sois plus précis sur ta question!
De quel emetteur parles tu?
radio? IR? tu veux un bidule tout fait, ou faire toi même le système?
Qu'entends tu par "fonctions"? un signal suplémentaire?


#55309 Commander mon robot via une telecommande et un recepteur infrarouge

Posté par sky99 - 10 avril 2013 - 08:01

Ne serait-ce pas un problème de "refresh"? je veux dire, la commande IR dure un certain temps, et peut être que cette impulsion ne suffit pas
à faire bouger significativement les moteurs.

Je veux dire, si j'ai bien compris, tu veux qu'en maintenant la touche avant, le robot avance, jusqu'à ce que tu lâches?
Mais la nature de la télécommande envoie des signaux IR discrets, et non continus, donc des impulsions "avance". Du coup,
peut être qu'avec un algo du genre "cliquer sur avancer pour que le robot commence à avancer", puis sur une autre touche pour l'arrêter, ça marcherait?

Une autre solution peut être serait de faire en sorte que chaque appui sur avancer déclenche un mouvement pour une durée suffisante (par exemple 0.1s).

Enfin bonne chance :)


#55273 R.Damil, un mini robot ultra simple, à très basse consommation

Posté par sky99 - 10 avril 2013 - 05:04

Bonjour à tous! Je souhaiterais vous présenter un petit projet qui a commencé comme un simple test. Au départ, je me suis demandé quel était le robot le plus simple que je pouvais faire avec le matériel à ma disposition. J'ai donc décidé de faire un Robot basé sur une puce Atmel ATmega328p, la puce qui équipe le Arduino Uno R3. Seulement, je n'utilise ici que la puce. Pour la motorisation, je m'appuie sur 2 servomoteurs à rotation continue, car il suffit du coup d'envoyer les signaux adéquats pour les faire tourner dans un sens ou dans l'autre, et je n'ai donc pas besoin de ponts en H, ou d'un quelconque driver de moteurs. Enfin, pour les capteurs, je m'appuie sur un capteur de distance infrarouge, parceque j'en ai un, qu'il ne requiert qu'une entrée analogique pour fonctionner, et que c'est une méthode éprouvée.

Je vais donc me lancer dans la construction d'un robot à évitement d'obstacles quasi minimal. Il ne sert à priori à rien d'autre qu'à faire des tests et valider des hypothèses. En commençant la construction, je me suis décidé également à le faire le plus petit possible, et devant sa simplicité, je me dis que tant qu'à faire, je peux tenter de lui donner la plus grande autonomie envisageable. Je vais donc maintenant vous décrire ma démarche.

Durant le sujet, les images seront cliquables pour avoir une version haute résolution.

Le robot : R.Damil.
Je vous présente donc R.Damil, mon mini robot. Ses dimensions sont relativement réduites : 70mm de long, 95mm de haut, et 85mm de large. Il est assez léger, puisque sa masse est de 335g, batteries incluses.
La conception est simple: il s'agit d'un robot basique à conduite différentielle, à deux roues motrices, et avec deux roulettes omnidirectionnelles pour la stabilité. Les roues font 65mm de diamètre, et sont entraînées par des servomoteurs à rotation continue basés sur les Futuba S148.
Ce sont d'assez gros servomoteurs, avec 45g pièce. Je les ai assemblés de la façon la plus compacte possible :
Image IPB

Sur la photo, on peut voir que les servomoteurs sont fixés sur des équerres en plastique avec des vis et écrous, et ces équerres sont fixées de la même manière sur une planchette de bois de 5mm d'épaisseur, qui correspond au fond du châssis du robot. Cela suffit à maintenir le tout en place, et le plastique autorise un peu de flexibilité, ce qui permettra plus ou moins d'amortir les vibrations.
Sur la photo, vous pouvez voir un logement à piles AA à coté, pour la référence en taille.
J'ai alors fixé la roulette, une petite d'un demi pouce, en plastique (ce que j'avais sous la main):
Image IPB Image IPB

J'ai fixé une paroi en bois sur l’arrière du robot, qui me servira à installer le logement des batteries et
le capteur à ultrasons. Cette planchette de bois se visse sur le reste du châssis par 3 vis à bois, par en dessous. J'en profite pour visser le logement à batteries dessus. Voici le résultat :
Image IPB Image IPB


Il suffit alors de refermer le logement avec son couvercle, sur laquelle j’accroche la mini breadboard avec de l’adhésif double face.
Je connecte alors les câbles :
  • Le VCC et le Ground, qui proviennent directement de la batterie. L'alimentation des servomoteurs et du capteur sont directement prises ici;
  • L'alimentation du convertisseur analogique-numerique, et la tension de référence sont connectés au VCC;
  • La masse du convertisseur analogique-numerique à la masse générale;
  • Les fils de contrôle des servos sur les broches numériques 5 et 6 car elles sont PWM;
  • Le fil de signal du capteur sur la broche A0 du ATmega.
A ce moment, nous avons fini la construction physique du robot. En effet j'ai choisi de ne pas utiliser de régulateur de tension, justement pour voir si c'était possible. Cela réduit également les sources de consommation électrique. On a donc un robot complet :
Image IPB

Il suffit maintenant de passer à la partie programmation du robot.
Le code est simple : si le robot trouve un obstacle tout près, il recule. Entre tout près et près, il tourne. Plus loin que près, il avance. Je ne donne pas de valeur en cm, car j'utilise la valeur brute du capteur sans me préocuper de la distance réelle. J'ai juste essayé quelques valeurs en mettant ma main devant le capteur, et j'en ai choisi deux qui me plaisaient, 300 et 200. Le capteur IR renvoie une valeur d'autant plus faible que l'objet et loin, et en plus l'échelle n'est pas linéaire. Donc je ne m’embête pas à faire des calculs, la valeur brute suffit à savoir si l'obstacle est proche ou non.

Voici le code complet :
#include <Servo.h>

Servo s1;//gauche
Servo s2;//droite

int s1Pin=5;
int s2Pin=6;
int rangeFinderPin=A0;//broche du capteur d'obstacles à distance

void setup()
{
  s1.attach(s1Pin);
  s2.attach(s2Pin);
}

void s1Forward()
{
  s1.write(180);
}
void s1Backward()
{
  s1.write(0);
}
void s1Stop()
{
  s1.write(90);
}

void s2Forward()
{
  s2.write(0);
}
void s2Backward()
{
  s2.write(180);
}
void s2Stop()
{
  s2.write(90);
}

void moveForward()
{
    s1Forward();
    s2Forward();
}

void moveBackward()
{
    s1Backward();
    s2Backward();
}

void turnLeft()
{
  s1Backward();
  s2Forward();
}

void turnRight()
{
  s1Forward();
  s2Backward();
}

void stopMotors()
{
  s1Stop();
  s2Stop();
}

void motorsTest()
{
    moveForward();
    delay(1000);
    moveBackward();
    delay(1000);
    turnLeft();
    delay(1000);
    turnRight();
    delay(1000);
    stopMotors();
    delay(1000);
}

int readRawDistanceOnce()
{
  return analogRead(rangeFinderPin);
}

int readAvgRawDistance(int count, int delay1)
{
  int i=0;
  int sum=0;
   for(i=0;i<count;i++)
   {
     sum=sum+readRawDistanceOnce();
     delay(delay1);
   }
   return sum/count;
}

void r1()
{
  int dist=readAvgRawDistance(10, 2);
  if(dist>250)
  {
    moveBackward();
  }
  else if (dist >180)
  {
    turnLeft();
  }
  else
  {
    moveForward();
  }
  delay(2);
}


void loop()
{
    r1();
}

A noter que la position neutre du moteur, c'est l'angle 90°. J'ai donc mis les servo à 90 avec le code ci dessus, et j'ai ajusté la petite vis de réglage jusqu'à ce que le servo soit immobile. A ce moment, j'ai pu utiliser la fonction de déplacement r1() dans la boucle principale du robot. Vous noterez que j'ai fait plein de sous-fonctions, car en fait il m'a fallu déterminer quelle valeur correspondait à quel sens. Mais on peut aussi modifier les valeurs saisies pour changer la vitesse du robot dans un sens comme dans l'autre. Cette programmation évite d'avoir à tout modifier si on décide de faire ce genre de modifications.

A partir de là, j'ai pu tester le robot :http://www.youtube.com/watch?v=Y-W6V6ugtqk
Comme vous pouvez le voir, il fonctionne. Ce n'est peut être pas tout à fait parfait, mais ça marche :)
En pratique, j'ai du rajouter une roulette à l'arrière, car quand le robot tournait, il basculait vers l'arrière. Une autre solution serait une tête de brosse à dents, ainsi le robot ne basculerait pas car les poils résisteraient à la compression, mais cela ne générerait pas beaucoup de frottement, car les poils résisteraient assez peu à la flexion.

Dans le prochain post je détaillerai un peu plus l'électronique, et discuterai de l'autonomie.