320 réponses à ce sujet

[Mike118]

Alors attention le pâté !
(Je voulais concevoir mon robot l'Explorateur de manière totalement modulaire, donc j'ai déjà pas mal d'idée )



Dropbox, c'est bien pour partager des documents quelconque.
Google Doc, c'est bien mieux pour bosser ensemble sur des fichiers textes/tableurs (en plus ça fait gestionnaire de révisions)

Dois je en conclure qu'il faut utiliser les deux ? x) Car on ne va pas mettre que des fichiers textes/tableurs !
Bon du coup je vais créer un dossier pour drop box. Envoyez moi vos mail en Mp et je vous invite pour le dossier ! =)

J'utilise MPLab X pour programmer les pics.

Tant mieux

Et KiCad pour les schémas et PCB, mais comme je ne vais surement pas faire de pcb, je vous laisse choisir ce que vous voulez.
(Attention tout de même : altium, c'est DXP ? Dans ce cas, c'est payant non ?)

Ah mais si ça impacte un peu ^^ Tu ne vas pas faire quelques schémas ? Et dans ce cas autant les faire sur le logiciel qui permet de faire le pcb derrière !
Pour dxp il me semble qu'il y a des versions gratuite ! Je mettrais ça sur la drop box !

Si on analyse un peu cette carte asservissement X moteurs :

• Pour un moteur, on a une sortie PWM "Commande" et une sortie "Sens de rotation" plus deux entrées (sur interruptions ?) pour les codeuses.
• Pour commander le(s) moteur(s), la carte asservissement est connecté à une autre carte (RPi ou autre) par exemple avec de l'UART. Il suffit de définir un protocole ou une structure de message

Rien qu'avec ça, on a une carte générique ! Si on conçoit la carte d'asservissement pour brancher 1 à 4 moteurs par exemple. il suiffera de brancher les 2 sorties à n'importe quelle carte de puissance qui prend en entrée PWM/Sens et de connecter les codeuse sur le connecteur associé.
Pour commander ce moteur, il suffira d'envoyer un message à partir de n'importe quelle carte connecté à l'UART de type "id_du_moteur;vitesse" sur 5 octets par exemple (plus si on rajoute des sécurités).
La carte pourra ainsi être branché à n'importe quoi et pourra gérer jusqu'à 4 moteurs CC quelque soit la puissance du moteur.


Donc, ça peut être utilisé sur un robot à 4 routes motrice ou sur un bras à moteur CC (même si je doute que ça se fasse ^^). Niveau généricité, c'est donc top.
En plus par l'UART, tu peux configurer la carte asservissement pour mémoriser des constantes utiles (coef PID des moteurs, nombre tic codeuse par tour de roue, etc.)



Plus technique maintenant : Si on prend un vieux PIC tout pourris (16F84 par exemple) à 4MHz d'horloge. ça nous fait 1 million d'instructions à la seconde.
Si on asservi à 50Hz chacun des moteurs, ça nous laisse 5000 cycles pour un moteur. Ce qui est plus que suffisant ! (Et comme on va mettre au minimum un quartz de 20MHz, on aura 25000 cycles pour asservir un moteur )



De toute manière en robotique, c'est comme ça qu'on procède en général.
Ta carte d'asservissement ne te sert qu'a asservir un moteur en vitesse. C'est la carte qui t'assure que si tu demandes à un moteur d'aller à 7km/h, alors le moteur ira effectivement à cette vitesse qu'il pleuvent ou qu'il neige.
Le calcul de la trajectoire ne se fait pas sur cette carte, mais à plus haut niveau.



Pas besoin d'envoyer la consigne en temps réel.
En gros :

• Tu as un programme haut niveau (RPi) qui planifie une trajectoire (c'est à dire des points de passages avec une orientation de ton robot)
• Un programme bas-niveau qui se charge d'assurer qu'un moteur tourne bien à une vitesse précise (la carte asservissement)
• Un programme intermédiaire (ton autre µC ?) qui se charge de faire ce que l'on appelle du suivi de trajectoire pour assurer que le robot suit bien la trajectoire calculé (qui fait donc le lien entre planif et asservissement)

L'étape de suivi est très importante, même si je ne l'ai jamais implémenté dans un de mes robots. (souvent, ma planif de trajectoire génère des vitesses roues que j'envoie à l'asservissement et je replanifie souvent ma trajectoire (avant d'avoir envoyé toutes les commandes vitesse), mais c'est une mauvaise façon de faire)

Un peu de doc sur le suivi de trajectoire : Thèse de Michael Defoort (thèse très bien écrite !)
Donc asservissement et suivi peuvent être des cartes génériques. La planif, c'est adhoc à l'application par contre.

Ok tout est parfaitement claire Donc oui le pensais ajouter un µC entre le raspberry et la carte d'asservissemnt pour faire le lien entre la planif des trajectoire et les commande en vitesse de l'asservissement ! =)

Par contre il faut gerder la possibilité d'asservir aussi en position ! Il me semble que c'est important pour avoir de vrai trajectoire fixe ! Il me semble même que l'asservissement en position est plus important que l'asservissement en vitesse lui même !

?? Je ne comprend pas ?? Les roues codeuses tu les met où tu veux, ça n'impacte pas le design de la carte d'asservissement
Le mieux, c'est de mettre les codeuses sur l'arbre moteur pour avoir une meilleur résolution.

non aucun impacte on est d'accord ^^ c'est juste que c'est un point qu'il fallait dicuter et qui impacte uniquement sur la vision de la chose ^^ Et puis voilà qu'est ce qui est le plus important ? la super résolution ? Ou bien de corriger un patinage ? Pour moi il est important de pouvoir commander au moteur de faire X tours* et pas un de plus ! Après si on veut que cela soit x tours non patiné ou juste effectué ... c'est autre chose ...

Pas obligé non plus si on conçoit bien tout générique
Ta carte d'alim devra disposé de plusieurs sorties à différents niveaux : 3.3V, 5V, 9V (plusieurs sortie de chaque niveau)
Ensuite à nous de concevoir les cartes pour permettre d'interfacer des cartes 3.3V avec des cartes gérés en 5V

Pour limiter les frais il me semble judicieux de faire du générique 3.3V ... après au pire si besoin par ci par là on pourra utiliser genre de capteur fonctionnant à 5V ou autre mais il faut limiter les interaction logique 3.3V 5V ...

Du coup autant partir sur des pic en 3.3V !

Pour moi, n'importe quel moteur fera l'affaire
La carte de puissance sera par contre designer en fonction du moteur !
Mais on peut s'arranger pour garder le même design et ne changer que quelques composants critiques (transistors de puissances par exemple). ça sera certainement la partie la plus difficile à concevoir "générique" !

La carte asservissement et suivi sont génériques et ne dépendent pas du moteur. On peut donc les concevoir séparément.


Pour rentrer dans notre budget de 100€, on peut proposer un robot basique avec deux tout petit moteurs (on n'utilise que 2 des 4 emplacement asservissement). Et la personne voulant faire évoluer son robot pourra choisir ensuite des moteurs plus puissants.


/>

Ok moi ça me va

Du coup je propose de commencer avec un L298 ! Grande plage d'alimentation possible en entré en plus il peut donner du 2,5A par sortie et contient de pont en H ... J'aurais bien proposé le LMD18200 mais il est trop cher pour nous x)

Ensuite pour le moteur, un point intérressant du moteur que je propose est le fait qu'on a à la fois accès aux engrenages ( on peut ajouter un codeur dedans ) Il a une fixation aisée qui aide à la standardisation ! Par contre que le codeur soit sur l'arbre ou pas ça se discute mais ce qui ne se discute pas c'est sa présence =)

Pour la batterie je propose pas forcément la même ... Peut être que le choix d'une 2S serait plus judicieux ... qu'en pensez vous ?

Pour les côté capteur je pense que pour la V1 on va se limiter au stricte minimum ... mais on aura peut être le module en rab qui intégrera caméra micro haut parleur ! Mais bon commençons déjà par la base roulante !

[sky99]

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 .

[sky99]

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!

[Black Templar]

Dois je en conclure qu'il faut utiliser les deux ? x) Car on ne va pas mettre que des fichiers textes/tableurs !
Bon du coup je vais créer un dossier pour drop box. Envoyez moi vos mail en Mp et je vous invite pour le dossier ! =)

ça pourrait-être bien.
Après le problème, c'est qu'on multiplie les endroits où se trouvent l'information.
Peut-être mettre en plus tous ces outils au début, voir lesquels on se sert le plus et virer les autres par la suite.

Petite question ? Dropbox fait gestionnaire de révision ? Parce que sinon ça va être la merde. On sera beaucoup à travailler sur le projet et si quelqu'un modifie/efface par mégarde un doc, c'est perdu... :/ :/

Ah mais si ça impacte un peu ^^ Tu ne vas pas faire quelques schémas ? Et dans ce cas autant les faire sur le logiciel qui permet de faire le pcb derrière !

Des schémas oui, des PCB peut-être pas non. Je n'ai pas assez de connaissance pour créer des cartes fiables et je n'ai pas de matos pour les tirer.

Par contre il faut gerder la possibilité d'asservir aussi en position ! Il me semble que c'est important pour avoir de vrai trajectoire fixe ! Il me semble même que l'asservissement en position est plus important que l'asservissement en vitesse lui même !

La trajectoire fixe, tu l'obtiens grâce au module de suivi, pas grâce au module d'asservissement
Par contre, pour l'asservissement, j'étais parti sur le vitesse, mais c'est vrai que dans certaines applications, il est préférable d'asservir en position (bras articulé par exemple).
Après, est-ce que l'asservissement position ne serait pas mieux gérer avec des servo-moteurs (et donc une carte dédié aux servos) et garder un asservissement vitesse pour les les moteurs cc ?

Il faut aussi réfléchir sur les avantages et les inconvénients de ces deux types d'asservissements (au niveau mathématique). J'avais fait toute une démarche il y a quelques années pour savoir ce qui était le mieux pour une application donnée. Je vais essayer de retrouver quelques docs ce WE !

non aucun impacte on est d'accord ^^ c'est juste que c'est un point qu'il fallait dicuter et qui impacte uniquement sur la vision de la chose ^^ Et puis voilà qu'est ce qui est le plus important ? la super résolution ? Ou bien de corriger un patinage ? Pour moi il est important de pouvoir commander au moteur de faire X tours* et pas un de plus ! Après si on veut que cela soit x tours non patiné ou juste effectué ... c'est autre chose ...

Que tu mettes tes codeuses sur l'arbre moteur ou sur la roue, tu ne régleras pas le problème du patinage du tout.
Et demande à hmnrobot ce qui est mieux. Je suis sur qu'il a déjà bien réfléchi à cette question

Du coup je propose de commencer avec un L298 ! Grande plage d'alimentation possible en entré en plus il peut donner du 2,5A par sortie et contient de pont en H ... J'aurais bien proposé le LMD18200 mais il est trop cher pour nous x)

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

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.

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 )

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!

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

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.

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)

[Mike118]

ça pourrait-être bien.
Après le problème, c'est qu'on multiplie les endroits où se trouvent l'information.
Peut-être mettre en plus tous ces outils au début, voir lesquels on se sert le plus et virer les autres par la suite.

Petite question ? Dropbox fait gestionnaire de révision ? Parce que sinon ça va être la merde. On sera beaucoup à travailler sur le projet et si quelqu'un modifie/efface par mégarde un doc, c'est perdu... :/ :/

Non pas de problème de ce côté là =) il y a le gestionnaire des modifications et on peut revenir à une version précédente ! Du coup je pense qu'on peut se contenter de la drop box...

Comme ça on évite de multiplier les zones où se trouvent l'info !

La trajectoire fixe, tu l'obtiens grâce au module de suivi, pas grâce au module d'asservissement />/>
Par contre, pour l'asservissement, j'étais parti sur le vitesse, mais c'est vrai que dans certaines applications, il est préférable d'asservir en position (bras articulé par exemple).
Après, est-ce que l'asservissement position ne serait pas mieux gérer avec des servo-moteurs (et donc une carte dédié aux servos) et garder un asservissement vitesse pour les les moteurs cc ?

Il faut aussi réfléchir sur les avantages et les inconvénients de ces deux types d'asservissements (au niveau mathématique). J'avais fait toute une démarche il y a quelques années pour savoir ce qui était le mieux pour une application donnée. Je vais essayer de retrouver quelques docs ce WE !

Au pire la même carte peut faire l'un ou l'autre c'est que du soft à changer par la suite ! En fait ça serait même bien de développer les deux soft et de pouvoir y avoir accès par choix de la planif de trajectoire !

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

Oui et non car le choix de certains composant peu coûteux peut grandement influer sur le choix de l'architecture !
Perso en ce moment je cherhce des codeurs à bon prix ! ^^

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

Parfaitement d'accord !

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

Hum si c'est une batterie lipo une cellule j'ai parfaitement ce qu'il faut sous la main !
Et je peux faire un chargeur intégré avec prise usb sans problème à faible coût !
en plus vu que je voulais intégré un pic avec bootloader intégré pour une reprogrammation facile ça fait double usage =) donc c'est cool !

Après du deux cellules je ne sais malheureusement pas encore faire mais je peux chercher ...

Sinon on peut mettre deux une cellule en série et les charger ensuite séparément avec un switch ...

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)

Parfaitement d'accord ... J'opte aussi pour la première solution ... Le but c'est de faire l'équivalent de la raspberry pi ou de la arduino mais pour faire un robot /> Et faire des tuto pour l'utiliser ... Histoire de pouvoir faire des expérience plus poussé pour des roboticiens amateurs et d'avoir une petite communauté travaillant sur le même robot de base histoire d'assurer une progression générale tout en profitant de ce que chacun peut apporter, matériel, prix, expertise, connaissances, idées , afin de réaliser ce qu'aucun de nous aurait pu réaliser tout seul pour la somme la moins élevé possible ...

[Black Templar]

en plus vu que je voulais intégré un pic avec bootloader intégré pour une reprogrammation facile ça fait double usage =) donc c'est cool !

Tiens, je bosse aussi sur la conception d'un bootloader en assembleur pour PIC 8bits ^^

Après du deux cellules je ne sais malheureusement pas encore faire mais je peux chercher ...

Sinon on peut mettre deux une cellule en série et les charger ensuite séparément avec un switch ...

Je sais faire dans la théorie.
Je pourrais expliquer si besoin quand le moment sera venu.

[dydyouaki]

Woaw ! beaucoup de termes technique que je n'ai jamais entendu et que je n'ai jamais appris malheureusement mais cava j'ai compris dans l'ensemble ce que vous voulais faire.

En tout cas c'est mieux de faire un robot compliquer mais facile a utiliser et a moduler , qu'un robot facile , mais compliquer a moduler.

A part ca , quels sont les points importants que nous devons répondre et résoudre ?

[Mike118]

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!

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 !

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

Que tu mettes tes codeuses sur l'arbre moteur ou sur la roue, tu ne régleras pas le problème du patinage du tout.
Et demande à hmnrobot ce qui est mieux. Je suis sur qu'il a déjà bien réfléchi à cette question />/>

Je pensais plutôt à mettre une roue folle codeuse ! dans le même axe que la roue motrice !



Et je répète; envoyez moi vos mails perso que je vous ajoute au dossier drop box que j'ai créé histoire qu'on commence à faire plus que d'en parler ! =)

Si il y en a qui souhaitent faire des vision d'artiste de notre futur robot, n'hésitez pas ça peut donner des idées ! =)

[dydyouaki]

pour le matos moi j'ai :

arduino mega2560 (j'aimerais bien la garder , mais bon a voir)
des chenilles tamiya
3 L293D
1 mirco servo 9g
1 capteur gp2y0202ykof
des afficheurs 7 segment , 14 segment , 7 digit , des leds , des microswitch , des haut parleur
des minis camera utiliser pour les telephone mobile, phot resistance , petit microphone provenant de telephone mobile
capteur tmp36 (temperature) , quelques transistor , des condensateur et des resistance.
Plein de moteurs DC utiliser et recuperer dans des jouets enfants

[Jan]

Si je peux me permettre un petit avis sur la "méthode".

Au-delà de toutes les communications en direct ("one to one", via MP, email, téléphone, rencontre etc...) qu'un tel projet va nécessiter, la file "forum" ne peut suffire en terme d'efficacité pour valider les différentes étapes, décisions, objectif. Combiner forum et blog officiel sur le projet (c'est pour cela qu'une plateforme de blogs existe aussi sur R-M) doit aider à mieux avancer, et ce blog ne peut être tenu que par le "coordinateur" du projet, le "chef d'orchestre" (il en faut un)). Voilà, c'était juste une modeste contribution sur la "forme" et la "gestion du projet". Sur le fond, nous n'intervenons pas, nous en tenant à la gestion/maintenance de l'outil afin de créer les meilleures conditions possibles pour que les échanges se fassent efficacement entre Robot-Makers :-)

[thermo_nono]

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.

[Black Templar]

Yep, j'aime bien GitHub ou SVN, (j'utilise surtout svn, mais ça fait quelques temps que j'ai envi de tester github).
Par contre, c'est bien pour bosser sur des fichiers texte (code et autre), mais par pour d'autres types de fichiers :/

[hmnrobots]

Super de voir autant d'enthousiasme dans ce projet, autant de compétences chez les robots-makers mais au risque de faire le rabat-joie (pardonnez moi par avance ou mettez ça sur l'âge) je m'interroge vraiment sur la finalité de ce projet. Pour ma part une étude/réalisation doit répondre à un besoin /une utilisation.
Dans ce cas est ce purement didactique axé vers l'utilisation d'une carte Raspberry Pi ? Si cet objectif est retenu alors il me semble nécessaire de réduire et limiter le hardware à un strict minimum standardisé ( un plateau,2 roues, 2 moteurs,2(3) US, utilisation intérieure voire un kit mais tout de suite une vidéo, liaison wifi,,synthèse vocale,reconnaissance vocale... afin d'essayer d'utiliser un peu plus les possibilités d'une telle carte.Les exemples de robots disposant de capteurs basiques et ne nécessitant qu'un maigre PIC ne manquent pas. Amener une Raspberry Pi à piloter quelques servos est trop réducteur (pauvre bête, elle va déprimer ).
De l'ambition donc!

[thermo_nono]

Pour moi, le but de ce projet est de pouvoir disposer d'une base robotique standard et peu onéreuse, mais qui reste facilement modulable grâce au RPi.
Le principal est selon moi de déjà disposer d'une telle base, en ne perdant pas de vue, bien entendu, les capacités du RPi pour une utilisation future plus complexe.

[hmnrobots]

Pour moi, le but de ce projet est de pouvoir disposer d'une base robotique standard et peu onéreuse, mais qui reste facilement modulable grâce au RPi.
Le principal est selon moi de déjà disposer d'une telle base, en ne perdant pas de vue, bien entendu, les capacités du RPi pour une utilisation future plus complexe.

oui mais c'est quoi le standard ? utilisation intérieure/extérieure; support lisse droit ...? combien de Kg à transporter? pour une plateforme d'apprentissage une comme celle ci pourrait suffire et serait dans le budget.

[Black Templar]

oui mais c'est quoi le standard ? utilisation intérieure/extérieure; support lisse droit ...? combien de Kg à transporter? pour une plateforme d'apprentissage une comme celle ci pourrait suffire et serait dans le budget.

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

[dydyouaki]

j'ai créer un compte dropbox juste pour nous , ceux qui désire voir et tester n ont qu'a me demander par MP les identifiants. Et si vous trouver que ca convient et bien on gardera le même compte.

EDIT: Je suis du meme avis que Black Templar

[Black Templar]

Et je répète; envoyez moi vos mails perso que je vous ajoute au dossier drop box que j'ai créé histoire qu'on commence à faire plus que d'en parler ! =)

j'ai créer un compte dropbox juste pour nous , ceux qui désire voir et tester n ont qu'a me demander par MP les identifiants. Et si vous trouver que ca convient et bien on gardera le même compte.

Je crois que c'était déjà fait par Mike :/

[levend]

Voilà un projet intéressant que je suivrai sans vraiment participer parce que j'ai déjà pas mal de projet en cours.

[hmnrobots]

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

je crains alors que cela ne se complique à moins d'en rester au niveau du breadboard. C'est vrai qu'une biblio de circuits testés sur breadboard et dispos via LTS/CircuitLab (ou autre) et compatible avec une carte de traitement évoluée (par exemple mesure du courant absorbé..) serait intéressante mais je crois que la plateforme de base est forcément limitée.Bien sur je ne peux que soutenir l'envie de réaliser ses propres cartes (c'est ce que je fais) sa propre mécanique (c'est ce que je fais) mais ce n'est pas un peu dépassé quand il s'agit de faire un robot plutôt didactique?

Modifié par hmnrobots, 10 avril 2013 - 04:12 .