Si c'est uniquement le manque de puissance de tes driver pour moteur qui te dérange sache que tu as le L298 qui est pas mal pouvant conduire 2A en continu et 3A ampère en pointe ! Sinon tu as aussi le LMD18200 mais là c'est plus exactement le même joujou et le prix n'est plus le même non plus ^^

alors que le L298 me coute 4 euros le LMD18200 me coute 8 euros et il ne contient qu'un pont en H alors que le L298 en contient deux ...

Faudrait que je me procure quelques L298
Mais 2100mA ça fait beaucoup, donc peu d'autonomie potentielle!
AU passage, les moteurs du bidule Tamiya sont prévus pour du 3V, ce qui ne m'arrange pas des masses
Mais en effet, faudrait que je m'équipe d'autres drivers ^^

J'ai fouillé la doc plus en détail, et le moteur est le F130RA-18100, dont les caractéristiques sont visibles sur cette page. Malheureusement, c'est le pire des cas : le courant nécessaire peut monter à 2.1A pour chaque moteur. Donc pour chaque canal, on est à plus du triple des capacités du L293D. Et même si on prend le courant en pointe du L293D, 1.2A par canal, ça ne suffit pas!

Pour ma part, je vais continuer à ne pas me servir de ce système jusqu'à ce que je puisse mettre des moteurs plus raisonnables. C'est dommage, car le design des chenilles me plaisait bien, avec la forme trapezoidale parfaite pour franchir des obstacles! (par contre les chenilles me semblent fragiles).

Je viens de faire le test en rajoutant "delay ( 1000); " apré la commande avancer et sa marche !

Après faudra peut être que je trouve le moyen de faire comme tu dit, appuyer pour commancer et pour finir l'action mais je n'ai aucune idée de comment faire sa x) parce que si tout les mouvement sont prédéfini sa perd un peut du plaisir du pilotage />

En tout cas merci beaucoup />

certes, mais je ne dis pas de faire des programmes prédéfinis, mais plutot que chaque bouton servirait soit:
-a exécuter une commande en boucle, jusqu'à ce qu'on change
-a exécuter une commande durant un certain temps.

La première solution ferait que du coup si on clique sur "avancer", le robot avance en ligne droite jusqu'à ce qu'il reçoive une autre commande. Donc plutot que de maintenir avant, on appuie une fois. Une solution serait de devoir réappuyer pour arrêter d'avancer. Ou chaque appui sur avant augmente la vitesse vers l'avant, chaque appui sur arrière réduit la vitesse, voire inverse la marche du robot.

La seconde solution peut donner un feeling télécommande de voiture téléguidée si on time bien le tout : par exemple si on définit que la commande "avancer" dure 0.05s (delay(50), et que les commandes
de la télécomande se répetent toutes les 50ms également, on peut avoir les sensations normales d'un appui continu qui fait avancer le robot en continu jusqu'a ce qu'on lâche...

oups, je rectifie, la commande avancer marche nickel mais la commande tourner a gauche ne marche pas comme l'autre. Au lieu de fonctionner 0,5 seconde comme le code le dit, les chenilles tourne en continue puis une des deux s’arrête mais l'autre non, même si j'appuis sur une autre touche? De plus je ne peut pas faire tourner mes moteurs trop longtemps car mon L293D chauffe trop.
Je pense que c'est lié a ma batterie qui ma l'air très déchargé que sa ne fonctionne pas correctement.

Si tu as bien un L293D, il est très sous évalué pour ces moteurs. La boite de vitesse Tamiya (j'ai la même, avec les chenilles) est donnée pour 2100mA. Je n'ai pas pu savoir si c'est 2100mA par moteur, ou au total (je penche plus pour le total, en tous cas j'espere sinon c'est un gouffre à énergie, cette boite...)

Le L293D est donné pour 600mA en régime continu, par moteur. Donc si la boite consomme 2100 mA au total, cela donne 1050mA par moteur. ça fait quand même beaucoup plus que les spécifications du L293D.
Et si c'est 2100mA par moteur, alors la, c'est énormément plus ^^
Du coup, dans tous les cas, le L293D ne suffit pas.

Pour info, j'ai fait un rapide test avec un L293D, sans charge pour le robot (les roues tournaient dans le vide), donc les moteurs ne consommaient pas autant
que nécéssaire, et dans ce contexte, le L293D chauffait énormément. j'ai essayé quelques secondes pour voir si ma boite fonctionnait, et je n'ai pas réessayé.
J'ai noté également que les mouvements n'étaient pas ceux attendus (un coté tournait à une vitesse normale, l'autre très lentement), donc je penche pour ça.

Moi je te conseillerais de multiplier les L293D en parallèle, ou trouver une puce plus puissante.

Il aurait juste fallu mettre la planche en bois supportant le capteur du côté de la balle caster au lieu de la mettre du côté opposé !



Le principe ( sans microcontrolleur ) existe déjà =) et ce sont des robot assez intéressant du point de vue de leur relative simplicité mais aussi de la gestion de l'alimentation par contre je les trouve peu évolutif selon moi ...

ici tu as un exemple de " solarbot" mais je les connaissais sous un autre nom plus en rapport avec les insectes il me semble mais impossible de m'en rappeler -____-'

J'ai mis le support du capteur à l'arrière, car ces capteurs IR ont une zone morte assez importante, ainsi je réduis la zone de données bidon. Mais en effet, ça ajoute du poids à l'arrière!
Comme c'est un montage vite fait, je laisse comme ça pour me moment, je corrigerai dans une V2 ^^

Les robots du type dont tu parles, j'en ai vu quelques uns, mais pour ma part ça ne m'intéresse pas réellement, car ils ne peuvent rien faire d'autre que bouger comme ci comme ça... Pour moi il DOIT y avoir un microcontrôleur pour que ce soit programmable, qu'on puisse y mettre un peu d'intelligence, et surtout que le robot obtenu puisse servir à quelque chose en communiquant par ex. L'idée serait d'en mettre un sur mon toit par exemple, avec un module radio, et qu'il mesure des trucs et des machins, en se déplaçant quand c'est nécessaire
J'ai tendance à penser que ces machines sans microcontroleurs sont juste des automates (maintenant quelle est la définition du robot? ou commence le robot?)

Salut! Je trouve ce sujet très intéréssant car plein de liens que je ne connaissais pas
Je propose ceux que j'ai utilisés jusqu'ici:

Adafruit.com (site us, même si vous ne commandez pas chez eux, ça vaut le coup de visiter leur site, car chaque produit est bien détaillé, avec la doc en lien, et la plupart du temps un ou des tutoriels).

Pololu.com, qui a plein de pièces robotique (moteurs avec réducteurs, de 5$ a cher et demi selon vos besoins, roues, etc)

en france, pololu.com et alpha-crucis.com, qui expédient relativement vite, pour pas cher en FDP

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

Moi je propose, avant de choisir le matos de réfléchir quelques temps sur l'architecture globale, pour la concevoir générique. Et de poser tout ça sur papier.
Une fois l'archi validé, alors on pourra réfléchir à notre petit robot et faire des choix techniques.
On a donc deux étapes :

• Conception de l'architecture qui est indépendante de toute application
• Faire de choix techniques pour utiliser l’architecture précédente en fonction de l’application choisie

Je comprends l'idée, mais, du coup faut savoir si on parle d'un robot a 100€ ou pas. Si on parle d'un robot à 100€, il faut tout de suite placer des limites... A un certain prix, on est limités en taille, vitesse, poids transportable, autonomie....

Le soucis avec la conception sans µC, c'est que je ne pense pas que le RPi fasse du temps réel ! Ce qui est gênant pour l'asservissement, la réception capteur, & co.
Rien n'empêche d'avoir une RPi pour le raisonnement haut niveau, et des µC pour une gestion du temps réel et des points critiques du robot (on en revient à notre discussion sur ta présentation /> )

J'entends bien, Linux n'est pas un OS temps réel. Mais est-ce obligatoire? Mon robot Raspberry fonctionne avec son linux "pas temps reel" et évite
plutôt correctement les obstacles. Si je me rappelle bien, les latences qu'on peut attendre sont en millisecondes, approximativement...
Et en pratique, si on enlève l'interface graphique et ce qui ne sert pas au robot, celui ci dédie presque complètement le CPU au robot...

Je comprends parfaitement l'approche µC commandé par le PI, et pour mes projets j'y viens, simplement parce que ce modèle m'intéresse, etc.
Maintenant, est-il nécessaire pour beaucoup d'applications? pas nécessairement. Je trouve justement intéressant de voir ce qu'il est possible de faire en utilisant simplement
le linux non real time. Sinon j'ai une question : pourquoi ne pas utiliser directement le µC et asservir celui ci sans fil à un ordinateur quelconque?
A partir de quand parle t'on de "robot raspberry"?

Je pense que dans tous les cas l'idéal serait d'avoir une couche d'abstraction dans le code, qui permette de balancer des commandes à un module, et selon le choix de design, que ce module soit un µC, ou alors le raspberry pi lui même si la personne fait un choix sans... Ce qui m’embête avec un µC si on parle d'un robot à moins de 100€, c'est qu'il faut un programmateur. Si on peut s'en passer avec un bootloader, il faut quand même de quoi
connecter le PIC à l'ordinateur qui sert à programmer; donc un circuit additionnel. Et du coup, ça rajoute un surcoût ^^
Sauf bien sur si ce circuit peut servir à diverses choses et ainsi baisser les coûts.

Intégré à la carte d'alim par exemple, oui ça complique les choses, mais pourquoi pas.

Par exemple ici ça fait un léger surcoût, mais d'un autre coté en fusionnant des fonctionnalités, ça réduit le coût d'autres parties.

Ah, tu soulèves un point important !
Quel est le but de ce robot ??

• Faire un robot modulaire. Donc simple à concevoir avec les briques de bases que l'on aura créé. Avec une simplicité dans l'ajout/le retrait de capteurs/moteur. Mais où chaque module est difficile à comprendre pour un débutant.
• Faire un robot pour débutant : Donc simple à concevoir avec des composants élec, mais pas modulaire car sinon, ça serait trop compliqué

Moi, j'étais parti sur la première solution : faire un truc très compliqué à concevoir, mais très simple à utiliser. (Un peut comme une arduino : comprendre comment c'est conçu, c'est hard ! mais l'utiliser, c'est simple)

N'hésite surtout pas à exposer le matos perso dont tu disposes ! Cela pourrait nous influencer de manière positive !
Ensuite si il te manque du matos on se débrouillera pour t'en envoyer !

donc moi j'ai :


4 Raspberry modèle B;
Un arduino Uno; avec un shield "programmateur" pour mettre des bootladers dedans;
Des ATmega328p;
Des ATtiny85 et 2113
Des MCP3008 et 23018;
Plein d'autres puces que je n'ai pas utilisées/testées (shift registers, solenoid drivers, etc)
des moteurs "plastic gearmotors" de pololu, avec rapport réducteur 120:1 et 180:1 :

• http://www.pololu.com/catalog/product/1593 ->moteur 180:1
• http://www.pololu.com/catalog/product/1594 ->moteur 180:1
• http://www.pololu.com/catalog/product/1124 ->moteur 120:1

j'en ai 4 ou 5 paires. Leur axe de sortie est un axe en métal, en D, de 3mm. Ils valent environ 5.5$ pièce, et prennent au plus 800mA, alimentés en 3 à 6v
Des servomoteurs à rotation continue futuba

Après, je n'en ai pas, mais il existe des "pololu micro metal gearmotors", avec boite de vitesse, fixation standard vendue chez eux, et des modèles ou on a accès à l'axe, voire un double axe, dont l'un pour la roue, après la boite de vitesse, et l'autre sur le moteur même, de l'autre coté.
Ils font des versions 360, 700 et 1600mA, toujours en 3-6v si je ne m'abuse. En revanche, c'est déja 15$ le moteur.

Pour les roues/chenilles :

• http://www.pololu.com/catalog/product/1090 (sachant que la "jante" de cette roue est la même que la roue d'entrainement des chenilles ci dessous, et qu'on peut, en mettant un pneu dessus passer d'une config à l'autre)
• http://www.pololu.com/catalog/product/1415 (convertible en roue, et il y a les encodeurs pour la position de la roue)
• http://www.pololu.com/catalog/product/1416 (idem)http://www.pololu.com/catalog/product/1420 (assez fines pour un photo-interrupeur)
• http://www.pololu.com/catalog/product/1435

Pour les régulateurs de tension, j'ai le régulateur step-up/step down de pololu (http://www.pololu.com/catalog/product/2119)
et des régulateurs linéaires de base;

Comme capteurs, divers capteurs (température, LDR, pression atmosphérique, pression -les petits bidules ronds qui détectent les niveaux de pression-
humidité, etc), mais pour l'usage robotique, disons surtout :
[

• url="http://www.adafruit.com/products/163"]l’accéléromètre d'adafruit[/url];
• Un capteur de distance IR sharp;
• Un capteur de distance à ultrasons Maxbotix;
• des microswitches avec long levier pour faire capteur de contact;
• Une autre version avec un levier "a roulette", pour un usage similaire;
• Des capteurs IR sur la bande 38Khz, pour faire des balises

Pour les driveurs de moteurs, je n'en ai que 2:
Le L293D;
le TI SN754410.

D'ailleur quel est la ref du composant pour le 5V régulé du RPi que tu propose ?

La référence, c'est le S7V7F5.
j'ignore si c'est un produit spécifiquement pololu, mais en tous cas, voici le lien :http://www.pololu.com/catalog/product/2119

Au passage, j'en profite pour signaler que le Raspberry Pi modèle A est sorti, et disponible. On perd l'ethernet et un USB, et on passe de 512 à 256 de RAM.
EN échange, la conso passe à moins de 400mA. Ce qui veut dire par exemple qu'avec le circuit au dessus, on peut alimenter le Pi avec tout ce qui produit entre 2.7 et 5V. Et également qu'on augmente l'autonomie du robot, bien sur.

ou alors il y a la solution compliquée mais efficace qui consiste à utiliser "Github". ( https://github.com/ )

Cette méthode permet à plusieurs personnes de bosser sur un même projet. J'avoue que c'est un peu compliqué à utiliser mais en contre partie, ça offre beaucoup d'avantages (possibilité de revenir en arrière, création de plusieurs branches pour tester différentes méthodes en //, mémorisation de "qui a fait quoi quand"...) et ça tourne sur à peu près n'importe quoi (Mac, Winwin, Linux...).

Je fini par un lien qui pointe vers un petit tuto vidéo histoire de vous faire une idée de ce à quoi ressemble cet outil.

Je suis parfaitement de cet avis, mais effectivement j'ignore comment github traite les autres fichiers que du texte. Mais pour du code ça me parait essentiel, pour le versioning.

Pour moi, je trouve que ce sont des questions qui ne se posent pas encore />

Etape 1 : concevoir générique quelque soit l'application (faire donc quelques cartes/modules qui pourront être réutilisés dans n'importe quelle circonstance : carte asservissement, carte gestion capteurs, etc.)
Etape 2 : choisir le robot sur lequel on va se baser pour faire les tests (poids, nombre de moteurs, roues intérieur/ext, etc.)
Etape 3 : Concevoir le robot de base

Certes, mais "générique quelque soit l'application", ça veut dire un robot extrêmement complexe et cher, non? si on part sur générique pour un certain nombre d'applications, ça rend plus réaliste le concept des 100€!

Mais encore une fois, mike118 parlait de robot à 100€ au départ, est-ce toujours dans l'optique du projet?

Dans un premier temps, j'ai donc pu vérifier qu'il est possible de se passer de régulateur de tension. J'ai pu faire un robot relativement compact, et j'essaierai plus tard
de faire plus petit avec des composants adaptés. Toutefois, pour le moment je vais me pencher sur la question de l'autonomie.

J'ai donc éliminé tout ce qui n'était pas essentiel : pas de régulateur de tension, pas de circuits suplémentaires de commande, rien qui ne serve directement à faire fonctionner le robot.
La liste complète du matériel est donc:
-Un puce ATMega328p (peut être remplacé par un ATtiny85, plus petit, moins gourmand et moins cher) (http://www.adafruit.com/products/123);
-Deux servomoteurs à rotation continue (http://www.adafruit.com/products/154);
-Deux roues (http://www.adafruit.com/products/167);
-Un capteur de distance infrarouge (http://www.adafruit.com/products/1031);
-Une trappe à piles AA contenant 4 Batteries AA rechargeables de 1.2V (3 suffiront, avec des non rechargeables, mais l'autonomie pourrait en pâtir) (http://www.adafruit.com/products/830)
-du fil type jumper wire (bobine de fil rigide à dénuder, ou câbles mâle-mâle) (http://www.adafruit.com/products/288)
-une mini breadboard (facultative) (http://www.adafruit.com/products/65);
-une ou deux roulettes;
-Des vis;
-Deux petits bouts de bois ou de plastique.

Les sources de consommation électrique sont donc :
1-Les servomoteurs;
2-Le capteur infrarouge;
3-le ATmega328p;


Pour les servomoteurs, je n'ai pas les spécifications sur la consommation en charge maximale. Ils sont donnés pour quelques dizaines de mA pour la charge minimale. En prenant large, on peut imaginer 1A en charge maximale. Au vu du couple des servos et du poids du robot, en prenant large, nous pourrions estimer que le robot utilisera 1/3 de la puissance maximale, soit environ 300mA. Comme on a deux moteurs, le couple disponible est doublé, mais du coup les moteurs prendront chacun moins, ce qui fait qu'on aura en fin de compte probablement une consommation du même ordre. Si les deux servos consomment 300mA au total, cela ferait 9h d'autonomie en mouvement continu. Au repos, les servos sont censés consommer moins de 10mA chacun, soit environ 135h d'autonomie.

Le capteur est donné pour une consommation typique de 30mA, et maximale de 40mA. On peut donc s'attendre à une autonomie maximale pour ce seul capteur de 67h.

Une carte Arduino complète consomme assez peu, mais cela se compte quand même en centaines de mA. Cela est du aux régulateurs de tension, à la puce USB, etc. Ici, nous utilisons la puce nue, à une fréquence plus basse (8Mhz). Les spécifications donnent 0.2mA de consommation dans les meilleures conditions, tablons sur 100 fois plus pour être larges, soit 20mA. Au pire, la puce consommera autant qu'une LED classique.

Si on prend la consommation totale estimée, ça ferait 300+40+20, soit 360.
La batterie fait 2700mAh, donc on peut attendre une autonomie de 7.5h en déplacement continu. Sachant que la consommation des servos est estimée, il faudra attendre des expérimentations pratiques pour savoir.

Concernant le robot hors déplacement, on tomberait à 20+40+20=80mA. On pourrait donc avoir 33h d'autonomie si le robot n'utilise pas ses moteurs. Il est possible d'améliorer ce résultat en désactivant les systèmes inutilisés. Je compte faire cela dans une version ultérieure, ou le micro-contrôleur sera capable de couper l'alimentation électrique des servomoteurs et du capteur quand ils sont inutilisés. Ainsi, on n'aurait plus que la consommation éléctrique du microcontroleur, et on multiplierait AU MOINS par 4 l'autonomie, soit 135h d'autonomie au minimum.

Il est sans doute possible d'aller largement plus loin, et en considérant la consommation réelle du ATmega328p, on peut facilement imaginer d'avoir plus de deux mois d'autonomie en mode immobile; et sachant qu'on peut utiliser des modes de veille, on peut baisser la consommation à quelques micro Ampères, ce qui nous mènerait à une autonomie théorique se comptant en années. Toutefois, à ce niveau, le taux d'auto-décharge des batteries serait supérieur à la consommation du circuit.

Je vais donc explorer cette voie, et voir dans quelle mesure il serait possible de concevoir un robot utilisant le soleil pour se recharger, et gérant ses déplacements pour ne jamais tomber à cours, ou au moins capable de s'économiser quand il n'a plus de quoi se déplacer.

De la même manière, on peut imaginer d'utiliser des condensateurs plutôt que des batteries, avec un condensateur pour le µC, et un autre pour le moteur. Celui du contrôleur serait prévu pour que le robot tienne au moins toute une nuit, et le second serait conçu pour que le robot puisse bouger un peu, après une charge d'une certaine durée. Par exemple, une minute de charge pour 25cm. Ainsi on aurait un robot capable de faire des petits déplacements de proche en proche, et pas de batteries s'usant. Reste à voir les condensateurs qui seraient adaptés, si c'est réaliste, ou non.

Une partie de mon travail consiste à réaliser un système du genre ! D'ailleurs j'utilise un module sigfox pour la radio ...
Par contre du coup il y a pas mal de chose à prendre en compte ! J'utilise un pic extra low consomation fonctionnant en 3.3V avec une batterie lipo une cellule 1250mAh qui coute 2 euros...
Et le système doit tenir 2 ans sans recharges !

Voila un domaine qui m'intéresse fortement
Je ne connaissais pas le protocole sigfox, c'est également très intéréssant!
Par contre je subodore que ce n'est pas forcément fait pour les particuliers...
Enfin, je veux dire, je n'ai pas l'impression que je puisse acheter deux "cartes sigfox" pour faire une communication entre deux appareils non?

Je dis ça comme ça, juste pour le principe, mais:
ON peut créer un réseau wifi avec juste deux machines WIFI. La norme gère ça, pas besoin de routeur.
Avec un portable et un robot embarquant un raspberry pi et du wifi, on peut faire communiquer les deux.

On peut également utiliser des clés wifi avec une antenne externe. ça ne coute pas beaucoup plus cher, et on
peut significativement augmenter la portée.

EN terrain ouvert, on peut largement atteindre la centaine de metres, voir plus de portée efficace en wifi.

On peut enfin aller beaucoup plus loin avec des antennes directionnelles, qu'on peut fabriquer soi même pour pas un rond (et la on parle de portées
en kilometre(s) en terrain dégagé.)

Il y a même un record a 380km, et d'autres sous les 100km, dont certains sans amplification active (donc une clé wifi, une parabole passive, et bingo).

tout ça pour dire qu'en terrain dégagé ça peut aller loin, et avec une antenne conséquente qu'on peut fabriquer soi même, il y a de quoi avoir une grosse portée.

Au passage, je n'ai pas documenté ma position sur le choix des batteries. Je suis parti sur des AA NiMH, car peu chères, standard, facilement changeables, tout le monde en a, etc.
Le second point est qu'en LiION ou LiPo, on a une meilleure densité énergétique, donc c'est mieux à tout point de vue pour la fourniture d'énergie. MAIS:
-c'est plus cher;
-c'est en 3.7V, et on peut pas les mettre en série sauf si les batteries sont pairées, et ça fait des multiples de 3.7V, alors qu'on a des multiples de 1.2V ce qui permet d’être plus précis;
-Il faut des chargeurs spécifiques en JST, que personne n'a sauf les roboticiens/modélistes, donc un achat pour quelqu'un qui commence;
-Les batteries Lithium supportent moins les mauvais traitement, la chaleur, ETC
-enfin SURTOUT, les batteries lithium nécessitent des précautions d'usage plus importantes, et si on parle d'un kit à mettre dans les mains d'un débutant complet, in le faut pas qu'il risque de se brûler, de faire exploser les batteries, etc...

EN gros, avec les NIMH, si on fait n'importe quoi, on grille peut être son circuit, on abîme ses batteries, mais on ne se blesse pas. Ou alors faut l'avoir cherché, en chargeant avec du 220 directement, en les mettant au feu, etc.

Maintenant, c'est une approche, et on peut considérer que la personne qui souhaite faire de la robotique peut comprendre un disclaimer disant "ne faites pas n'importe quoi avec ces batteries, elles sont dangereuses et peuvent exploser". Après tout, on trouve ces batteries dans les téléphones et les ordinateurs. Pourtant il doit y avoir pas mal de personnes qui font des idioties avec, sans pour autant qu'on entende parler d'énormément d'accidents.

L'avantage des batteries au lithium c'est qu'on pourrait intégrer le circuit de charge au robot (surcout suplémentaire , mais bon), de sorte que finalement pour recharger on branche en USB plutôt que de sortir la batterie... Mais bon je complique peut être alors qu'il est déja difficile de rester dans un prix réduit!

Pour les moteurs, je pense qu'il faut un certain couple, donc un rapport réducteur un peu important; mike tu parlais de 15:1, ça me semble peu non? d'autant plus que plus le robot est rapide, plus il est difficile à contrôler (un robot lent aura le temps de faire X mesures pour corriger sa trajectoire), non? sans compter que si après la personne fait de la conduite par webcam, un robot trop rapide dépassera la fréquence de rafraîchissement de la webcam et/ou la fréquence d'analyse de la webcam par OpenCV
Par contre je comprends tes arguments sur la fixation, et l'accès aux engrenages. D'un autre coté n'est-ce pas dangereux, si par exemple on envoie le robot dehors, dans son jardin?


Au passage, je pense que l'idéal serait que le robot soit compatible avec de multiples solutions pour chaque sous système. Pour les motor drivers, il y a les L293D, mais aussi l'autre puce TI que je cite plus haut, avec le même pinout. Le L293 tout court, je n'ai pas eu l'occasion de le tester, car je trouve toujours la version D, limitée à 600mA par canal, malheureusement. Mais c'est sur que ce serait mieux avec cette version, car elle est plus puissante, tout en restant un L293, pour lequel il y a 1 milliard de schémas sur le net

SInon je partage tout à fait ta conception, l'important c'est d'avoir une base solide, extensible, qui permette de tester un robot qui fonctionne rapidement, quitte à ce que le robot soit un peu simple, mais en ayant la possibilité d'étendre ses capacités pour faire un projet ambitieux!

A mon sens, la base qu'il faut, c'est un robot à 2 roues motrices, avec des moteurs DC avec rapports réducteurs, car les autres solutions sont plus chères (servomoteurs; de plus le raspberry pi n'est pas idéal pour commander des servos, du fait qu'il a un seul PWM. La on serait obligés d'intégrés un µC) ou plus complexes (stepper motors, pour quelqu'un qui débute, n'est-ce pas un peu compliqué de commencer de suite par les steppers?)


Ceci dit, je me rends compte en écrivant ça que je projette sur ce projet le projet que j'avais en cours; du coup la cible n'est pas forcément quelqu'un qui débute. Du coup je vais relire le sujet et peut être arrêter de dire des bêtises
(mais en tous cas, je suis partant, motivé et tout. Et j'ai pas mal de matos à la maison (moteurs, roues, chenilles, 4 Raspberry pi, un arduino uno, des atmega, des ATtiny, des régulateurs de tension, des capteurs ultrasons, infrarouge, magnétiques (hall), accéléromètre, bref, j'ai 4 boites de "bidules arduino" et "bidules raspberry pi" pour plein de projets en parallèle), donc je peux faire des tests. D'autre part je peux faire des prototypes en bois, car j'ai une scie sauteuse, une scie à rubans, une scie circulaire, des perceuses, ponceuses, rabot électrique, et je peux faire le bruit que je veux ^^

Donc je peux essayer des idées que vous proposez si j'ai le matos!

Bonjour à tous
Déjà je dirai un truc: Je vous aime
Non sérieusement, je suis excessivement content de voir ce post. Vous pouvez me compter dans la partie!

Mon profil est plus celui d'un informaticien que d'un électronicien, il y a encore beaucoup de choses qui m'échappent dans ce domaine. Pour l'instant, j'en suis arrivé au niveau ou j'arrive à programmer des ATMega, ATTiny, utiliser divers IC, faire des communications I2C et SPI, et utiliser divers dispositifs (servos, moteurs, capteurs, etc). Comme je le disais dans mon sujet de présentation je ne suis pas aussi avancé que je l'aurais pu, car j'ai passé beaucoup de temps à faire des tutos pour documenter ce que j'ai appris. Bref, disons que je ne vois rien qui me pose problème en informatique, ou ma spécialité c'est plutot les réseaux de neurones (plus ou moins), mais j'ai des bases en traitement d'image/traitement du signal, algos évolutionnaires, j'ai un peu utilisé OpenCV, etc... Aussi les connaissances classiques pour un informaticien, en réseau, topologies, etc, qui peuvent servir à concevoir des modules de communications. Mais je m'égare.

Ce que j'ai de particulier, eh bien je suis curieux et très motivé, mais je pense qu'on l'est tous ici, mais également je fais des enseignements dans ma fac, et j'ai monté un petit club de robotique. On est tous débutants, mais du coup on a une petite poule d'étudiants intéréssés, et avec eux on peut envisager des sous projets sur diverses parties. Donc je peux potentiellement rameuter du monde! D'ailleurs si je suis recruté Maitre de Conférences, j'espère proposer des stages orientés IA embarquée dans un robot, computer vision pour des applications robotiques, etc

Sur ce projet, j'ai PLEIN d'idées, et pour cause, l'idée exposée , je suis dessus depuis plusieurs mois. Au début de façon exploratoire, et maintenant de façon bien plus concrète. En pratique, j'ai un prototype, R.Cerda, mon robot Raspberry Pi.
Je vous donne les 4 liens du tutoriel que j'ai fait sur PCInpact jusqu'ici :

• Présentation du robot R.Cerda
• Détail du choix des pièces, et explicationssur les options possibles
• Schéma de principe et schéma électronique du robot
• Instructions de construction/assemblage, création d'un châssis

Il manque le dernier tuto, sur la programmation. Le code est sur un GitHub, et je pensais faire ça ce soir, mais j'ai posté ici plutôt ^^

J'ai fait aussi pas mal de vidéos démontrant les forces et faiblesses de ce robot :

• La dernière version de l'algorithme de déplacement en action
• Une version à roues, avec ses problèmes de franchissement d'obstacles
• Une version à chenilles, avec d'autres problèmes mais un meilleur franchissement
• Une étude comparative sur l'impact de la taille des roues et des chenilles sur la vitesse du robot

J'espère ne pas trop vous assommer de liens, mais je pense que ceux ci contiennent quelques informations intéressantes. Mais je résume ici le robot :

En gros, pas de microcontroleur. Pourquoi? parceque le Raspberry pi a des GPIO et on peut donc s'en passer, le PI servant de µC. L'intérêt est que la programmation est directe, en python, C, java, etc... Le mien est équipé d'une clé wifi, ce qui fait que je le programme à la volée à distance, par SSH. Les µC permettent de faire de nombreuses choses, mais pas des traitements lourds, genre traitement d'image. Or, avec le PI, on peut mettre OpenCV, et faire de la navigation vidéo, avec une webcam, par exemple... Bref, de nombreuses possibilités.

j'ai mis un MCP23017 pour ajouter 16 GPIO et protéger ceux du raspberry pi. La puce s'interface en I2C, et on peut en avoir jusqu'à 7 en même temps pour un sacré paquet de GPIO. Cette puce est toutefois facultative, mais comme elle est peu chère et protège le PI, je l'ai intégrée.

Pour lire des entrées analogiques, j'utilise un MCP3008, qui fournit 8 entrées analogiques par le biais du bus SPI, en 10 bits.

Les moteurs DC sont commandés par 2 puces L293D en parallèle, car chaque puce accepte 600mA en continu par canal, alors que les moteurs peuvent monter à 800mA en stall. Cependant, après discussion avec pololu, ils m'ont confirmé que le SN754410 supportait bien 1A par canal, donc on peut simplifier le montage à deux puces en prenant celle là. De puce, la disposition des broches est identique au L293D, ce qui veut dire qu'on peut mettre une SN754410 à la place d'une L293D sans changer le câblage, la programmation, ou quoi que ce soit d'autre. J'en ai 3, je testerai en pratique

Pour le capteur de distance, j'ai choisi un capteur à ultrasons, car il est fiable, précis, et détecte plus "large" que le capteur IR. Le capteur IR peut tomber juste entre deux barreaux de balustrade, ou un trou et ne pas détecter le meuble autour. Avec le capteur ultrasons, on a moins ce problème. Selon le capteur on peut détecter plus ou moins "large". Chez maxbotix il y a une gamme précise à 1 pouce près, de 6 pouces à 6 mètres (j'ai le plus étroit), et une gamme précise à 1mm près, de quelques cm à 5m. J'ai le LV-EZ4, et je dois dire que ses mesures sont hyper stables, et très précises. Le souci c'est qu'il coûte 20€ contre 12 pour un capteur IR. En revanche pas besoin de servomoteur pour l'orienter. La fréquence de rafraichissement est également plus faible, avec 20Hz, contre 400Hz pour les IR. mais ça se compense en partie par le fait qu'en IR on doit faire la moyenne de 10 mesures pour avoir un truc stable.
Dans les deux cas, n'importe quel capteur ultrasonique peut remplacer le capteur que j'ai mentionné, et n'importe quel capteur de distance infrarouge également, sans modifications du reste du circuit (sauf si le capteur demande des tensions inhabituelles).
Bref, n'importe quel capteur de distance analogique pouvant fonctionner en +3.3V ira.

On peut aussi utiliser des capteurs de contact (j'en ai rajouté, les références sont dans les liens) pour pas cher, et on a pas besoin du ADC pour ces capteurs.

Pour la motorisation, j'ai choisi les "plastic gearmotors" de pololu, car :
Ils sont économiques (environ 5$ pièce);
Leur consommation est modérée (800mA max);
On peut avoir divers rapports réducteurs (120:1 ou 180:1);
La boite de vitesse est intégrée, donc pas de risque de blocage, comme avec les boites tamiya;
Ils sont compatibles avec une pléthore de roues, chenilles et accessoires peu chers chez pololu.
Dans l'une des vidéos, vous noterez que j'utilise le même robot avec deux tailles de roues différentes, et des chenilles. Les roues s’enlèvent facilement à la main, et restent bien en place.

J'ai privilégié les moteurs avec un axe métallique, car je me suis dit que ce serait plus résistant. Par contre je n'ai pas d'avis sur les versions droites ou coudées.

Pour les roues, bah y a pléthore, de 3 à 9cm, des chenilles, des roues étroites, des roues larges, des roues avec encodeurs intégrés, etc... A noter que les chenilles utilisent des roues dentées, pour lesquelles on peut avoir des pneus, ce qui veut dire qu'on peut sans changer les roues passer d'une configuration "roues" à une configuration chenilles simplement en enlevant les pneus et en mettant les chenilles ou vice-versa.

Sur l'aspect des encodeurs rotatifs, j'ai une solution économique à proposer, pour les roues "a rayons".
Celles ci possèdent 5 ou 6 rayons. On pourrait mettre un photo-interrupteur de sorte que les rayons interrompent le faisceau et détectent les rotations de la roue. La résolution est plus faible qu'avec les encodeurs intégrés à certaines roues, mais c'est une solution utilisable pour d'autres roues. D'autre part, je n'ai jamais utilisé les capteurs de réflectance, donc je ne m'avance pas dessus, car je ne connais pas leur efficacité, précision, etc... Mais il existe des solutions, et on peut s'en sortir pour pas cher!

Au passage, j'ai en projet des idées de cartographie par guidage inertiel, en analysant le mouvement théorique par la durée de mouvement commandé pour chaque roue, mais également en utilisant un accéléromètre. Mais je m'égare.

Pour l'alimentation, je me suis appuyé sur des batteries AA, car elles sont économiques. La tension est régulée par ce composant de chez pololu, qui ne vaut même pas 5$ et est un régulateur à la hausse ou à la baisse entre 2.7 et 11.8V, avec une efficacité de 90% ou plus. Quand il augmente la tension il fournit 500mA, quand il baisse la tension il fournit 1A.
Il chauffe assez peu dans mon cas, suffit à alimenter le pi de façon stable, en l'isolant des variations de tension provoquées par les moteurs. et il est MINUSCULE (moins d'un cm²).

Quand snootlab référencera ce composant j'en prendrai sans doute 10 à 20, je m'en sers partout
A propos de snootlab, je parlais de 100€, car je travaille justement sur ce projet en espérant pouvoir leur donner une liste de matos qu'ils vendraient en "pack". Ils m'ont dit qu'ils sont prets à faire des package, pour moins cher que la somme des pièces.

Pour l'instant, j'en suis donc à ce niveau, le seul problème c'est que je ne peux pas fournir une référence vers un chassis standardisé. j'ai fait le mien en bois; et pour les moteurs je n'ai pas trouvé de fixation "standard". Donc difficile de parler d'un kit complet "sans bricolage". Moi je peux découper, mais pour les personnes en ville, la scie sauteuse/scie circulaire n'est pas forcément une solution possible! Et je dois dire que j'aimerais bien pouvoir me servir de ça pour parler robotique aux plus jeunes. Pour moi c'est un super projet pour un enfant qui voudrait apprendre à programmer, et faire de la robotique.

Pour l'instant j'en suis plus aux alentours de 110-120€ en tout compris (en fait 72.5€ de matos hors raspberry pi., donc +35€ le Raspberry pi, +5€ la carte SD, donc 112€ en version ultrasons, environ 102€ en infrarouge, et 92€ avec juste des capteurs de contact.)

Le problème c'est que je n'ai sans doute pas compté certains petits trucs, comme la breadboard, les "jumper wire", et je n'ai pas inclus le châssis. Maintenant si il y a possibilité de faire un circuit à souder, on peut enlever le prix des câbles et de la breadboard, avec un "shield" pour raspberry à pas trop cher.

Sur ce point je n'ai aucune expertise; et je n'ai pas encore d'imprimante 3D pour envisager des tests de design de châssis.


Pour le code, je propose un GitHub, car c'est une solution pour les projets collaboratifs, avec gestion des versions, donc en cas de problème possibilité de revenir sur la précédente version; gestion de la différence entre deux fichiers si A et B uploadent une MAJ en même temps, ça fournit un site avec un dépot et des commandes standard pour récupérer les trucs, c'est pas compliqué à utiliser, y'a un client linux, windows,et mac, et on a un historique de toutes les actions. Je crois qu'on a 4Go par projet, et c'est gratuit pour l'open source. J'ai essayé google projets, mais j'ai moins aimé le design, et github m'a semblé plus intuitif, pratique et rapide à prendre en main (en gros je n'ai fait aucun effort pour apprendre l'un ou l'autre, j'ai utilisé celui que j'ai fait marcher en cliquant la ou ça me semblait logique, sans lire la doc ou quoi que ce soit...)

bref, j'ai trop écrit déjà; vous m'excuserez du chaos de mon post, mais il est 1h22 ici, et puis j'étais un peu surexcité en lisant le thread ^^

Au passage, je porterai les tutos robotique que j'ai faits sur PCInpact ici. Par contre pas tous les tutos Raspberry Pi, je n'en aurai pas le courage !
En revanche, si du monde veut reprendre les tutos pour les poster ici, faites le, tout ce que j'ai posté (sky99) est sous licence creative commons CC-BY-SA (et cela inclut les médias, d'ailleurs vous verrez que la plupart des vidéos de ma chaine youtube sont en creative commons), tant qu'ils n'incluent pas le visage de personnes, ou de contenus liés à des droits d'auteur que je ne possède pas. Dans ce cas, n'hésitez pas à enlver les contenus potentiellement litigieux .

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 :


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):


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 :



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 :


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.

Justement, le principe, c'est de ne pas relier Aref à Vcc, sinon ça n'a pas vraiment d'intérêt.
Tu peux pas contre créer une référence de tension (avec des diodes/zener & co.) qui ne changera pas même avec la variation de la tension d'alim.
Ainsi, plus de soucis côté ADC. Peut-être encore des problèmes côté capteurs, et encore, je ne suis pas sûr (j'ai utilisé un capteur température il n'y a pas longtemps que j'ai alimenté en 3.3V et en 5V (c'est dans la plage de spécification) La sortie ne variait pas beaucoup en fonction de l'alimentation choisi /> )

Je ne suis pas sur de bien te suivre, ici. Si je relie Aref à VCC, ça veut dire que la tension maximale retournée correspondra à la valeur numérique maximale (par exemple 1024) quelle que soit la tension d'alimentation non? Si VCC=5V et que Aref=5V, le capteur étant également alimenté par VCC, alors il retournera des valeurs entre 0 et 1024, et retournera les mêmes valeurs pour VCC=Aref=Vcapteur=4V non?

ce qui me poserait problème, ce serait que le capteur de distance retourne 300 pour une distance quelconque, puis 200 pour la même distance; mais avec une tension plus basse.
Maintenant je me rends compte que je ne peux pas, par ce biais, mesurer la tension des batteries, puisque ma référence varie avec elle. Mais si je fixe Aref à une valeur stable alors que VCC ne l'est pas, n'aurai-je pas une variation de la valeur retournée par le ADC pour une même mesure?

Je ne suis toutefois pas bien sur d'avoir compris parfaitement le role de Aref. Pour moi c'est la tension de référence à laquelle sera comparée la tension mesurée par le ADC. Comme la tension de sortie du capteur pour une valeur dépendra de la tension d'alimentation de celui ci, si Aref est stable, et VCC variable, une même distance ne va elle pas retourner diverses valeurs?

Dans tous les cas, j'ai monté le robot, et il fonctionne sans soucis visibles pour le moment sur l'électronique. En revanche, du point de vue mécanique, il est déséquilibré, et il bascule vers l'arrière quand il tourne. J'ai donc rajouté une roulette à l'arrière, et ça fonctionne ^^
Il est très réactif,et la navigation est assez précise sans que je fasse de réglages. Par contre il ne voit pas trop les obstacles en dessous du niveau de ses yeux.

Je vais poster un sujet dessus, dans la bonne section, ce qui sera l'occasion de discuter d'idées sur l'autonomie atteignable

Au passage, quelqu'un saurait ou trouver la consommation maximale des servos? j'ai beau fouiller la doc, je vois la conso mini, le câblage, le couple, mais pas le courant consommé! C'est quand même pas sérieux de pas fournir cette donnée, je trouve!

Il faut voir dans la datasheet si ton µC reset automatiquement s'il détecte une trop forte perturbation de la tension d'alim et voir si tu peux désactiver l'option (comme chez les PIC)


C'est un peu plus tordu que ça.
Tes capteurs peuvent êtres perturbés, mais surtout ton convertisseur A/N te filera une donnée numérique PAR RAPPORT à ta tension d'alim !
Donc si tu obtiens par exemple 443 avec la pile chargé à 5V, ça n'aura pas la même signification que 443 avec une pile chargé à 4V :/
Après, peut-être que ton µC te permet de fournir une référence de tension externe pour l'ADC




Super idée
Là il va falloir tout optimiser.
Utiliser des transistors pour customiser ra consommation plutôt que des CI tout fait, etc.

En effet, sur les ATMega, il y a le "brown-out detector", qui sert à détecter les baisses de tensions, qui peut être désactivé. J'y ai aussi pensé.
Pour le ADC, justement, avec le ATmega3289P, on définit également la tension de référence du convertisseur via la broche Aref. Du coup en la reliant au VCC, ma tension de référence devrait varier
dans le temps avec celle de la batterie!
Pour la conso minimale, bah pour l'instant dans le robot il n'y a aucun CI si ce n'est le microcontroleur. Apres peut être qu'il y a un IC dans le servo, voire dans le capteur IR. Mais dans ce cas, une solution serait de commander l'alimentation de chaque servo et du capteur IR via un transistor. Du coup les systèmes tomberaient à 0mA de conso quand je ne m'en sers pas. Sachant que le ATmega peut tomber très bas en conso si on s'en sert hors de la carte Arduino, et encore plus bas en changeant quelques détails, je pense qu'on peut tenir longtemps
Sinon avec les ATtiny, on peut tomber à quelques µA de conso. Je peux faire le robot avec le ATTiny85, le seul souci c'est qu'il n'a que 8 pattes, dont 6 E/S (2PWM, pour les servos, 2analogiques, et 2 "normales"), juste ce qu'il faut. ça suffit, mais du coup c'est pas super extensible, si je veux ajouter des petits trucs en plus.
Avec le ATiny85, je pense utiliser le second ADC pour un capteur IR courte portée pour détecter les vides (Comme ça j'en ferais un robot "de bureau"), et les deux entrées analogiques pourraient servir à des détecteurs de contact. Dans ce cas, ce serait le robot maximal sur cette puce

J'ai des ATtiny2313 avec plein d'entrées sorties, mais toutes numériques. Et sinon le ATMega, plus complet, avec 6 ADC, 6PWM et encore des sorties numériques.

Enfin je verrai bien

C'est intéréssant!
Du coup la seule chose que je risque c'est un comportement erratique par moment.
Si j'ai des baisses de tension quand les servo prennent du courant, mon signal logique
pourrait ne pas être aussi haut que je le voudrais. Toutefois, beaucoup de composants qui fonctionnent
en 5V comprennent le +3.3V haut comme un signal logique haut également, et j'ai pu tester cela
entre l'arduino et le pi (le pi envoie des signaux +3.3V, et l'arduino a bien interprété ces signaux)

Du coup au pire j'ai le capteur IR qui renverra des données faussées si il n'aime pas le signal plus bas, et le servo
qui risque de ne pas obéir si le signal est trop bas.

Le robot pèse 219g, hors batteries (dont une bonne partie -90g au total- provient des servos).
Les 4 Batteries AA de 2700mAh pesent au total 121g.

Cela fait donc une masse totale de 340g.
Les servos, c'est ce modèle :
http://www.adafruit.com/products/154
Le couple est annoncé à 3400g-cm.
Les roues font 65mm de diamètre.
L'ensemble possède donc une force de propulsion très largement supérieure
à la puissance nécessaire, donc on peut s'attendre à une consommation faible des
servos (sans charge, ils sont annoncés à quelques dizaines de mA).

Du coup, les risques de baisses de tension significatives sont d'autant plus réduits. (et du coup il faudrait que je trouve des logements pour batteries AAA, ça me permettra de réduire les dimensions et le poids).

Je vais donc le programmer, et voir comment il s'en sort

Du coup, vu tout ça, je me dis qu'il serait également intéressant de tenter le robot le plus économe possible, pour voir combien de temps il peut fonctionner... Et s'il était capable de rester en veille toute une nuit, je pourrais envisager un robot solaire qui chargerait ses batteries la journée, et fonctionnerait "en permanence", par exemple sur le toit de chez moi

En restant simple, on peut imaginer quantité d'expérimentations, avec les robots!

En tous cas, merci pour les réponses

Au passage, même si ça ne fonctionne pas avec le robot, c'est quand une bonne nouvelle, car je souhaite aussi faire des montages à ultra basse conso, qui serviraient uniquement
à collecter des données. Par ex un petit module alimenté par une ou deux piles AAA, un micro-contrôleur, un/quelques capteur(s), et un module radio.
L'idée étant que ce soit aussi économe en énergie que possible, et peu cher. Ainsi on peut imaginer une application ou le système serait à usage unique :
je fais le montage, je le coule dans de la résine, et je le mets quelque part. S'il dure quelques années, ça vaut le coup!
(la résine c'est pour un modèle devant aller dehors bien sur. En intérieur, bah une petite boite et c'est réglé).

Bonjour à tous! J'ai fait divers petits robots, et la j'en fais un que je veux le plus simple possible. Donc je m'appuie sur une puce Atmega328P, et plus tard
un ATtiny85. Il s'agit d'un robot simple, avec deux servo à rotation continue, un capteur de distance infrarouge, et l'algo de base : si je vois un obstacle trop près je tourne, si je suis en dessous d'une certaine distance je recule, sinon j'avance. Bref, rien de très nouveau. Mon problème vient du fait que j'ai deux objectifs sur ce petit robot :
-Faire le plus petit robot possible avec le matériel dont je dispose en ce moment;
-Faire le robot le plus simple possible.

Pour la simplicité, donc, j'aimerais me passer de régulateurs de tension. J'ai de très bons régulateurs de tension, mais je souhaite m'en passer, pour les garder
pour d'autres projets. J'ai déjà fait tourner un ATmega directement sur des batteries AA, pour faire clignoter une LED.
Je sais qu'en cas de variation subite de la tension je peux avoir des résultats inattendus. Toutefois,avec 4 batteries AA, j'ai 4.8V en pleine charge, et 4V quand elles sont déchargées.
Normalement, la tension devrait progressivement varier entre ces deux valeurs. Logiquement on ne devrait pas avoir de variations rapides, simplement celle due au vidage de la batterie.

Je souhaite donc alimenter le ATmega ainsi, sans régulateur. Je sais que ça fonctionne, mais j'ignore s'il y a un risque. Avez vous des infos là dessus?
D'autre part, puisque les servos sont aussi alimentés par les batteries, je peux m'attendre à des variations de tension quand les moteurs "tirent", non?
Mais dans quelle mesure cela peut il poser problème? Sachant que les seuls systèmes connectés sont le capteur IR, et les deux servomoteurs. Éventuellement je peux me débarrasser du capteur IR, pour utiliser des
switches pour détecter le contact.

Donc pensez vous qu'il y aie un danger pour le microcontrôleur? (il est donné pour une plage de 1.8 à 5V je crois bien.)

Si jamais le µC reboote de temps en temps, ce n'est pas bien grave pour moi, tant que ça n’abîme rien.

Qu'en pensez vous?

Tu veux dire combiner des systèmes experts (comme des systèmes flous) avec un algo évolutionniste pour modifier par exemple les fonctions d'appartenances afin d'affiner l'expertise humaine ?

Ou tout simplement mettre des à prioris humains pour certains sous problèmes (je sais que ceci et cela en fonction de X,Y,Z, donc je fais une sous fonction "basique" pour generer des informations
de plus haut niveau à partir d'une réflexion humaine sur certains points, et laisser ensuite le système apprenant faire des déductions en utilisant ces données). Par exemple, si j'ai un robot doté d'un accéléromètre,
et que l'accélération ne change pas, alors que la consommation des moteurs est importante, je peux dire que le robot est coincé sur un obstacle, mais ses roues peuvent toujours entrainer un mouvement; alors
que si je détecte que le robot ne subit aucune accélération, alors que les roues tournent, mais que les moteurs ne consomment presque rien, je peux dire que le robot ne touche pas le sol. Ce sont des diagnostics
intermédiaires, qui ne me permettent pas de faire du pathfinding, mais à partir de ce genre de données et d'autres, on peut imaginer un algo apprenant qui va plus loin que sur la base des seules données des capteurs.

Ce que je veux dire, c'est qu'on peut combiner des bouts de réflexion humaine et de l'IA conventionnelle pour le robot, et aller plus loin qu'avec l'un ou l'autre seul...
Mon exemple est schématique, mais je pense qu'il permet de voir mon idée

Peut-être parce que c'est encore au stade de recherche
Je bosse dans les SMA et j'essaye de faire le pont entre les SMA cognitif que l'on trouve en recherche pur et les systèmes à base "d'Acteurs" (donc souvent uniquement réactifs) qui connaissent actuellement un véritable engouement au niveau du génie logiciel.

Les SMA réactifs, c'est déja un bon modèle, pour pas mal d'applications, ça peut être intéréssant Maintenant si en plus les acteurs sont dotés de fonctions apprenantes, par rapport à la perception de l'environnement, je pense que c'est encore plus fun, c'est sur!
Mais la raison pour laquelle je n'ai pas plus poussé les SMA, c'est que je travaille davantage sur les RN, dans ma thèse, et d'autre part, les SMA n'auraient probablement pas été adaptés.

J'ai également réfléchi à ce genre d'application, et mon superviseur de thèse aime aussi beaucoup ce concept.
Néanmoins, je ne suis pas convaincu par cette approche. Comme je fais par ailleurs de la robotique et de l'élec, je sais que la gestion du temps est souvent un point critique dans la conception de robots. Si on commence à mettre des SMA au niveau des fonctions primaires du robots, on a des risques que ces agents ne répondent pas forcement comme on le souhaite, qu'ils ne traitent pas les informations des autres agents dans le temps escompté.
Pour rappel, un agent doit être autonome ! Donc les autres agents ne peuvent pas prédire le comportement d'un agent en particulier. Si cet agent n'a pas envie de répondre à une requête, et bien il a la possibilité de ne pas répondre...

Je comprends ce que tu dis, et certes, il y a des latences de communication. Mais si l'on considère des modèles "naturels", cette approche existe et fonctionne pour les êtres vivants. De ce fait, certes on a une latence, du fait de la communication inter-puces. Mais si on actualise le comportement d'un robot 100 fois par seconde au lieu de 1000 fois, est-ce réellement délétère pour son fonctionnement? Ne peux on pas mettre en balance l'efficacité gagnée (je fais moins de mouvements, mais ils correspondent mieux au résultat nécessaire) et la plus faible fréquence de rafraîchissement? Bien sur dans certains cas il faut une réponse à la microseconde près, voire moins. Mais dans une optique "hobby", je pense que souvent c'est suffisant! Dans certains cas, on peut même envisager des problèmes insolubles par une approche centralisée, mais facilement solubles en décentralisé. (Bon ici j'ai peut être une déformation due à mon gout du parallélisme).

D'autre part, une conception de ce genre pourrait éventuellement permettre de pallier à la défaillance d'un sous système, et rien n'interdit une approche adaptative permettant de modifier le comportement général en fonction des performances des sous-systèmes. A mon sens l'intérêt serait que chaque sous-système s'auto-régulerait pour s'adapter aux attentes du système global. En gros, une sorte d'intelligence distribuée, collaborative, pour réaliser la tâche principale. Maintenant c'est peut être plus compliqué que l'approche centralisée dans beaucoup de cas, mais les possibilités me paraissent intéressantes />/>

Sans compter qu'en recherche, ce qui est chouette, c'est les problèmes, les "ça va pas marcher comme ça", qui nous poussent à aller plus loin et trouver des solutions />/>

Bonjour et bienvenue, Audrey

Il existe aussi une section Tutoriels ici :
http://www.robot-maker.com/forum/tutorials/

Si le coeur vous en dit, n'hésitez pas à venir l'enrichir.

Merci! Je n'y manquerai pas! Pas forcément ces jours ci, mais j'ai bien l'intention de faire des tutos />/> Quand j'aurai fini le tuto sur mon robot, je le porterai sur ce forum dans un format adapté.

Je suis parfaitement d'accord Et c'est d'ailleurs ce que je fais sur mon robot pour la coupe de france ! ( Bon je n'ai pas encore la raspberry Pi dessus mais pour l'année prochaine pourquoi pas ! )
Tout ça pour dire que j'utilise un pic principale gérant 2 moteurs pas et qui donne des ordres à plein d'esclaves qui eux gèrent : les autres actionneurs et différents capteurs ! Par contre je n'en suis pas au point d'appeler cela un système multi-agent mais uniquement un système modulaire ^^
j'ai par exemple un pic de type 10f qui commande un servo suivant un cycle à chaque fois qu'un pic "maitre" le lui demande... j'ai pas moins de 7 pics sur le robots =) ( bon il me reste encore à tout câbler car le robot n'est pas encore fini ^^ mais ça avance ! )

En tous cas, c'est une approche "cybernétique", avec des sous systèmes auto-régulés, et c'est une conception que je trouve passionante. De cette manière on peut cacher une partie de la complexité dans des sous tâches; sans compter que pour optimiser tel ou tel aspect, il suffit de se concentrer sur le sous système. Et si plusieurs sous systèmes identiques existent, l'ensemble sera amélioré!
Bonne chance pour la coupe de france en tous cas J'aime aussi beaucoup cette approche pour les servomoteurs, car je trouve qu'il y a beaucoup de choses à faire (bon pas réellement des tonnes, mais quand même) pour utiliser
un servo, alors que souvent ce qu'on veut c'est "tourne à droite" et "tourne à gauche", ou "va à l'angle X". Du coup mon idée est d'utiliser un ATtiny85 comme contrôleur pour 1 ou 2 servos, de sorte qu'il reçoive des commandes simples sans que le maître aie à se soucier de timings, des broches, etc...
En plus avec un système d'adresses, rien n’empêche d'envisager une communication de type BUS pour pouvoir chaîner le tout et utiliser les mêmes broches pour X sous systèmes...

La seule chose qui m'embête avec les microcontrôleurs, c'est que du fait de la puissance disponible, je ne puisse pas trop utiliser du XML pour les commandes />/> J'imagine que c'est possible, mais bon, je ne me sens pas de faire un parseur XML pour microcontroleur />

En fait, je parlais de la conception davantage au sens mecanique que logiciel. Mais je comprends également ton propos.
Toutefois, j'apporterais également un bémol : la programmation spécifique d'un robot s'appuie souvent sur des a-prioris,
qui viennent certes d'une expertise humaine, mais également d'une perception particulière du problème. Or, l'algorithme
évolutionnaire ne prend aucun à-priori, ni aucune analyse consciente de l'évolution, de sorte qu'elle n'est en théorie
orientée que par l'efficacité. Du coup on peut faire émerger des solutions etonnantes, parfois plus efficaces que la
conception orientée. Mais il est vrai qu'en général, le cerveau humain mettra dans la conception outre des connaissances,
une analyse poussée et consciente, une reflexion, mais également une sorte "d'intuition" qui orientera ses choix due
à l'expérience, et l'entrainement du "réseaux de neurones naturel" qu'est le cerveau à reconnaitre certains modèles.
Bref, hors de la réflexion consciente et posée, l'humain a également parfois cette sorte d'inspiration, qui est probablement
due à une forme de raisonnement inconscient s'appuyant sur des processus cognitifs inférieurs, qui lui permettra de trouver
une excellente solution.


Sur ton second point, par rapport au fait que l'algo G ne peut pas trouver LA solution, et peut être coincé dans un optimum local :
certes, mais c'est également la raison pour laquelle on fait varier le taux de mutations de l'algo G. Maintenant sur le fait
que les systèmes apprenants proposent des bonnes solutions mais ne fournissent pas LA solution optimale (pas nécéssairement,
et si c'est le cas, on n'a aucun moyen de le prouver, sauf problèmes spcécifiques), je suis bien sur d'accord, c'est même
inhérent aux algos évolutionnaires. Toutefois, la convergence vers une solution n'est pas nécéssairement moins efficace
que la solution humaine, car nous aussi fournissons des solutions efficaces, mais sont-ce les solutions optimales?

A mon sens, ici l'approche la plus pertinente pourrait être de combiner des forts à-prioris humains et des systèmes apprenants.
En tant qu'humain, en voyant une situation, je peux extraire des connaissances, des savoirs, d'une valeur élevée, qui échaperont
à la machine. En revanche, celle ci pourra sans doute faire émerger des connaissance d'ordre inférieur, qui m'échaperont probablement.
Du coup il peut être intéréssant de combiner les forces des deux systèmes.

Concernant les systèmes multi-agents, c'est une approche que je trouve fantastique, mais malheureusement j'ai eu peu d'occasions de m'en servir.
Mais je conserve toujours le concept dans un coin de ma tête, et d'ailleurs, si on prend la définition formelle de la cybernétique, qui décrit les systemes, on pourrait se dire qu'une machine peut être modélisée comme un SMA. C'est une approche que j'affectionne beaucoup, car elle permet
de fractionner la complexité et de générer des problèmes d'ordre inférieur. Dans l'autre sens, une somme d'agents simples peuvent se retrouver
capables de répondre à des problématiques de plusieurs degrés de magnitude supérieurs à la complexité individuelle de chaque agent.
En gros, la valeur de l'ensemble est supérieure à la somme des valeurs de chaque partie

Cette approche SMA fait partie de mes objectifs sur le long terme, puisque j'espere concevoir des robots fonctionnant justement comme des SMA.

AU niveau du robot même, j'ai également pensé à une telle conception pour un robot un peu plus complexe, par exemple un marcheur.
Plutôt que d'avoir un système nerveux central (un microcontroleur) qui gère tout, j'avais pensé à un systeme nerveux décentralisé,
par exemple un Attiny85 pour gérer une patte, ou une paire de pattes (donc 4 à 6 servos), et chaque sous ensemble géré par un autre controleur.
Enfin, j'aurais rajouté un Raspberry Pi par dessus, pour ajouter des fonctions d'ordre supérieur, comme de la computer vision et autre.
Mais on aurait eu un systeme avec des agents chargés de la gestion de bas niveau des actions musculaires, un système central chargé des
décisions de haut niveau, mais ignorant les détails des mouvements des pates, etc...

De manière générale, je pense donc que les SMA sont une solution magnifique pour résoudre de nombreux problèmes complexes!

Sur l'adaptation évolutionnaire, j'ai suivi un séminaire ou un chercheur parlait d'un robot qui simulait des méthodes de déplacement et finissait par choisir la meilleure. Je trouve que c'est un niveau encore super intéréssant, car plutôt que d'essayer physiquement et donc d'etre limité dans le nombre de tests, ici on passe un cap supérieur. Toutefois le problème est la modélisation, qui en devient assez complexe.

Mais du coup, c'est sur que si chaque robot est un agent du SMA 'pathfinding', on multiplie les expériences
Faudrait que j'aie mon labo privé pour pouvoir étudier ce genre de problématiques ^^

Merci à vous
Justement ce qui m'intéresse le plus c'est de pouvoir échanger des idées, et même des discussions ouvertes sur des sujets
aussi bien pratiques qu'abstraits (quand peut on considérer qu'un système devient conscient? je sais, c'est de la SF
pour le moment, mais c'est une problématique passionnante).

D'autre part, je suis super intéressé par le fait de travailler avec d'autres personnes sur des solutions inter-opérables,
j'espere pouvoir développer en guadeloupe des compètes entre robots ayant des protocoles compatibles,
pour voir dans quelle mesure on peut obtenir des résultats différents avec une même base (et un protocole similaire),
ou des résultats similaires avec du matériel différent...

Mais si je parle de faire ça localement, c'est parceque c'est plus facile de confronter les robots en "physique", mais
rien n'empeche d'imaginer des sortes de tests standardisés pour mesurer l'efficacité d'une solution, de sorte qu'on
puisse comparer nos solutions...

Par exemple, il y a un fort courant "naturo-morphique", qui consiste à imiter la nature pour certains problèmes.
Pour ma part, je suis plus convaincu par une approche robot-centrique, s'appuyant sur les forces du robot, et
atténuant ses faiblesses de telle ou telle façon, reposant sur un design mécanique, cybernétique, une conception
nouvelle, plutot que reproduire la nature.
Sur ce point, c'est que si la nature reste presque systématiquement plus éfficace que la technologie pour beaucoup
de choses, le problème est que les matériaux et systèmes dont nous disposons ne sont pas assez performants la plupart
du temps pour reproduire efficacement les comportements naturels, et je pense donc qu'il est généralement préférable
de prendre l'approche technologique plutôt que bio-mimétique.
Par exemple : pour du sol plat, quoi de mieux que la roue? les robots marcheurs n'égalent pas les perfs des robots rouleurs.
Les chenilles pour le franchissement d'obstacle : une solution extrêmement simple et économique pour un problème complexe,
et qui est dur à résoudre avec un robot marcheur.

Toutefois, je trouve l'approche bio-mimétique passionnante, et je rêverai de comparer mon paradigme aux machines
bio-mimétiques!
(sur le point du bio-mimétisme, il y a une tendance géniale aussi : c'est de ne pas imiter des formes de vie qui existent,
mais de s'appuyer sur des concepts du vivant pour générer un système sans rapport avec une quelconque bestiole
du monde réel, mais qui a quand même une inspiration "monde du vivant". Par exemple ces robots un peu en forme de serpent,
mais qui n'utilisent pas la reptation mais des sortes de contorsions bizares... Ou ces robots à "roues-pattes", avec des roues,
mais non rondes, et dotées d'un certain nombre de "pieds", qui imitent un peu les mécaniques de ces petits lézards qui parviennent
à courir sur l'eau)

ENfin bref, je parle trop, et je divague sans doute

Bonjour à tous. Je suis Audrey, dans le monde réel. Je finis ma thèse en intelligence artificielle, en Guadeloupe.
J'ai donc un background en informatique, mais pas en robotique, ni en électronique, même si j'ai toujours rêvé
de faire des robots. Avec quelques étudiants, nous avons monté un hackerlab dans notre fac (mon but est de pousser
les étudiants à aller plus loin que le programme, et pourquoi pas se découvrir une passion?) Bref, l'idée, c'était
de faire des bidouilles diverses, et pour leur parler du projet, je leur avais parlé du Raspberry Pi.
Et quand l'un des étudiants m'a parlé d'en faire un robot, je me suis replongé dedans... Et voila comment, un peu
après la fin du monde (fin 2012, vous vous rappelez, les mayas, tout ça ), j'ai commencé à faire des petits montages,
et je suis également parti dans l'idée de faire des robots

Ces 5 mois furent bien chargés, et je pense avoir bien progressé. J'ai encore énormément à apprendre, pour l'instant je n'ai
fait que deux ou trois robots "stables" (cad non cannibalisés tout de suite pour en faire autre chose ) et quelques prototypes.

Bref, j'ai enfin réalisé un rêve, et il n'y a pas à dire, c'est totalement une passion Je regrette seulement de ne pas m’être
lancé plus tôt

Je n'avance pas nécessairement très vite, car dans le même temps, je fais plein d'expériences en automatismes, domotique,
et tout simplement électronique avec le Raspberry Pi, des arduinos, et maintenant des microcontrôleur (ATmega et ATtiny, ces
bidules sont géniaux!), et j'ai décidé de documenter ce que je fais. Le but de cette démarche est pédagogique, car c'est
l'un des aspects qui m'attire dans le boulot d'enseignant-chercheur à la fac : retransmettre des connaissances (en plus
de chercher des trucs ^^).

Bref du coup, j'ai passé pas mal de temps à faire des tutoriels sur divers sujets et on a un gros sujet dédié sur le forum
de PCInpact

C'est d'ailleurs par ce biais que j'ai découvert votre forum, par un autre membre!

J'ai un peu parcouru le forum et j'y ai lu plein de sujets intéressants, et je vois plein de choses à apprendre

En pratique, mes intérêts sont pour la construction de robots "from scratch". Les jouets robots ne m'intéressent pas plus que ça,
hormis éventuellement s'ils sont peu chers pour les démonter et récupérer les capteurs, les servomoteurs, etc ^^
Je m'intéresse également aux automatismes, à la domotique, et de façon plus générale aux systèmes autonomes.

Comme je travaille sur de l'IA, j'aimerais bien justement faire de l'IA dans le monde réel, et utiliser ce types d'algorithmes
pour des systèmes robotiques/automatisés. Probablement principalement des réseaux de neurones (car c'est mon domaine principal
de compétence), des algorithmes génétiques et de systèmes multi-agents (car ces deux solutions me semblent bien adaptées
à des robots simples).

J'ai énormément de projets, des idées sur le pathfinding de robots, des groupes de robots effectuant un travail collaboratif
(par exemple X robots doivent cartographier une zone, faire en sorte qu'ils puissent se répartir le travail, ou analyser
un même objet avec différents "points de vue", et minimiser la dépense énergétique de chacun pour le même résultat),
un système de communications maillé entre robots pour qu'ils fassent un réseau à connectivité redondante, des robots
"permanants", qui feraient une tâche en gérant leur autonomie et en allant se recharger quand nécessaire; des robots
"permanants" en extérieur qui seraient également capable de gérer leurs batteries, mais en s'appuyant sur des énergies
renouvelables (soleil principalement, pourquoi pas le vent?) comme apport d'énergie (le but serait d'avoir un robot
sur le toit de la maison, qui se mettrait parfois en veille, mais qui serait toujours "conscient" pendant une longue durée
pour réaliser une tâche, donc avec des algos d'évaluation du coût énergétique des actions, et de prioritisation des
actions à effectuer : faut il réellement se déplacer la bas, au prix de X joules, alors que j'en ai tant, ou alors
rester ici et avoir une moins bonne mesure, mais que je peux reproduire demain pour un coût négligeable?)

Bref, j'ai tout plein d'idées, mais forcément tout autant de questions. Je suis encore loin de mes objectifs, pour l'instant
je ne fais que de simples robots basés sur des L293D pour piloter des moteurs, commandés par un Raspberry pi ou un Arduino,
avec juste un capteur ultrasonique ou infrarouge et/ou de contact.

J'essaie de conserver une conception simple également dans l'objectif de tutoriels que je me suis fixé, car outre la simplicité
de montage, mon objectif est de proposer des templates de robots (avec le/les tutos) conçus pour ne pas coûter trop cher, en
essayant de rester sous la barre des 100€ par exemple, Raspberry pi compris. La raison est que pour un complet débutant, s'il
faut mettre 250€, il sera réticent, surtout s'il ignore si il continuera ou même si il finira son robot
Mon but c'est que des gens se disent "ça a l'air simple, c'est pas trop cher, je me lance", et je pense qu'une fois qu'on
est passé par la, plus de retour en arrière, c'est trop passionnant pour ne pas continuer

Bon, enfin bref, je parle trop, alors je m'arrête là
J’espère pouvoir participer aux passionnantes discussions que j'ai entrevues sur ce forum!

Salutations à tous!