En voyant le sujet, je me dis que ça risque d'être difficile d'atteindre la barre des 100€ avec tout ce que vous avez prévu.
Je propose deux idées :

-Soit on l'augmente dans un premier temps, par exemple 150-200€;
-Soit on ne s'occupe pas de ça pour l'instant, en gardant à l'esprit de pas non plus prendre des composants trop chers tout le temps;

L'idée étant que c'est difficile de résoudre des solutions techniques sans plein de domaines différents, tout en ayant une contrainte
d'optimisation financière à l'esprit. Donc peut être qu'une stratégie serait de partir un peu plus large, pour arriver à une base,
un prototype en version 1.0, fonctionnel, plus cher que l'objectif, mais complet, et par la suite quand on aurait atteint l'objectif
fonctionnel, de réfléchir à une optimisation sur les coûts, en cherchant des équivalents moins chers, etc.

De même réussir à faire le robot pourra nous donner une idée du prix minimal possible à atteindre, car j'imagine bien que si on fait
un robot pour 150€, on peut peut être imaginer de baisser son coût d'un tiers, mais probablement pas de baisser le coût de 75% sans
avoir une usine dédiée.

Qu'en pensez vous?

...

Je réagis par rapport aux posts sur le forum
Le choix entre la tourelle ultrasonique et la ceinture de capteurs, ce n'est pas à mon sens, un élément important pour le moment. L'idée étant d'avoir une base, le/les capteurs d'évitement d'obstacles ne sont pas "primordiaux", et dans tous les cas il s'agit de brancher 3 fils! Le tout c'est que pour moi, on aie des emplacements prévus
pour pouvoir facilement fixer ce genre de capteurs, des broches accessibles pour le faire, et des capacités de programmation sur le robot pour accéder à ce genre de capteur.
Le "brainstorming" dont tu parles, c'est à mon sens la conversation qui a lieu sur ce forum en ce moment
Pour ma part, je commence à avoir une vision précise du projet, je crois que Mike partage la même, et du coup on a déjà avancé. Maintenant, en effet, nous comprenons nous tous?
Pour ce qui est des modules, ce n'est pas à mon sens un problème pour le moment, car si on part sur une base centrale, à savoir :

• chassis;
• alimentation électrique/batteries;
• fixation du raspberry pi/connection au(x) divers organes du robot;
• motorisation;
• circuit de commande des moteurs/roues et contrôle de trajectoire;

A ce moment on peut déjà définir une base de travail, pour déterminer les dimensions, la charge transportable, l'autonomie, le poids, la puissance motrice, la puissance électrique consommée et disponible pour des sous systèmes supplémentaires, etc...
ça fait déjà pas mal de variables à définir, de choses à mettre au point.
Une fois cette étape faite, on pourra alors décider qu'un module, ça doit consommer au plus X mA, se fixer de telle façon sur le reste, peser tant, etc etc.

Ce que je veux dire, c'est qu'on a un "coeur", qui doit être défini en premier à mon sens, car si on commence à penser à toutes les applications possibles de suite, on se retrouve avec une étude extrêmement large et complexe, qui prendra des mois. Je suis plus pour une approche incrémentale, en gardant en tête l'évolutivité bien sur, mais
en se focalisant d'abord sur les systèmes les plus critiques. Une fois qu'on a fait cette base, on pourra réfléchir à l'interface entre le robot et les modules, et se pencher par exemple sur différentes classes de modules (par exemple des modules de types A,B,C, avec un module A etant le quart d'un module B, un module B le quart d'un module C, de sorte que dans l'emplacement d'un module B on puisse installer 4 modules de types A...
Et la on aurait une sorte de "grille", qui nous permettrait de fixer des "petits bidules", ou des plus gros, en prenant plus ou moins de place, etc etc.)

Mais on pourrait se préoccuper du système de modules une fois qu'on aurait designé la base, et une fois le système de modules pensé, on pourrait alors réfléchir à la conception de modules (par exemple, commencer par un module "senseur ultrasons", puis ensuite faire un module "tourelle pouvant emporter un autre module", et ainsi de suite, de sorte qu'il soit possible de faire toutes sortes de trucs et de bidules).

...

Je crois qu'on se comprend bien
Pour le chassis, je suis d'avis de partir sur une forme simple, genre rectangle, pour la facilité de conception. On peut ensuite envisager des "modules passifs", qui viendraient se fixer sur les bords pour changer la forme du robot! Ou alors différentes tailles/formes de chassis, compatibles avec notre système de modules.

Justement, je regardais le cahier des charges dans la drop box et je me suis dit un truc :

"Etre évolutif", c'est bien mais c'est pas précis. ^^
Personnellement, j'aurais ajouté quelques détails sur la nature de cette évolutivité :
vu que (si j'ai bien tout suivi ^^ ), il y a déjà un bus I²C prévu pour communiquer avec le PIC, il pourrait être redirigé vers un connecteur externe (j'en profite pour dire que je ne crois pas que l'I²C soit implémenté sur les premiers RPi.. ).
de même, va-t on ajouter (rendre accessible) un port GPIO ?
edit : et quel type de connecteurs choisir ?

Pour le I2C, c'est supporté par les premiers pi, c'est juste que c'est le bus 0 dans les premières révisions, et le bus 1 dans les rev 2 et plus

Pour les connecteurs, je propose les connecteurs classiques comme ceux des GPIO, en mâle, avec l'espacement "breadboard", pour que ce soit facile à utiliser
et compatible avec le plus de "bidules" possibles. Et comme ça tout serait relié en jumper wire female-female.


Sinon globalement, je ne peux pas trop bosser dessus ces jours ci, car je pars à bruges lundi, jusqu'à samedi en symposium pour présenter un papier. A mon retour je bosserai un peu dessus

Salut,

Tu pourrais t'étendre un peut plus sur la partie programmation, le langage que tu envisage ? les outils de développement... parce que d'après ce que j'ai compris la partie électronique à bien avancé !

Je suis encore loin d'être un pro avec la raspberry pi />/>/> Je ne fais que commencer />/>/> Pour l'instant je lis juste des tuto et je contrôle les GPIO. J'ai mis tout ce que j'ai sur la raspberry pi dans la drop box dans programmation . J'aimerais bien programmer en C la bête mais pour l'instant j'ai fais un script avec la librairie GPIO c'est suffisant pour faire avancer le robot de manière un peu aléatoire mais pas suffisant pour tout le reste x)

Mais je sais pas si je vais avoir le temps de faire ce que je veux ce week end x)

Trop de projets et je n'ai du temps que en dehors des heures 9H 12H30 et 14H 18H ... Heureusement que je dors peut pour que tout avance un peu ^^

Salut!
Déjà désolé de ne pas avoir beaucoup parcipé, et je crais d'avoir peu de temps libre pour faire quelquechose de serieux!
Toutefois, j'ai des Raspberry Pi (6 ou 7 modèles B, et 2 modèles A), un module caméra, et tout plein de petits composants annexes.
Donc si vous avez des tests à faire sur du matos que vous n'avez pas, faites le moi savoi />/>

Pour la programmation, ça se programme en C/C++, mais aussi en python, java, en fait ce que vous voulez, car les GPIO sont en fait des fichiers.
Il suffit alors d'y accéder pour modifier/lire la valeur, donc à priori tout langage de programmation gérant les fichiers est utilisables.
Sur mon robot Raspberry Pi, j'ai fait l'essentiel du code en python, mais j'ai des bouts de C, et j'ai une interface PHP qui permet
de faire avancer, reculer, ou tourner le robot. On peut aussi lancer le mode exploration automatique. Le robot streame un flux vidéo webcam
(c'est possible avec le module camera égamement, mais comme le module camera est de qualité très supérieure, 5Mpixels en photo et full HD 30FPS
en video, je le garde pour des applications d'imagerie. J'en ai un seul pour le moment et il n'est pas facile à trouver).


Au passage, avec un système à jour, la carte SD d'un modèle B est interchangeable avec la carte SD d'un modèle A.
Le modèle A n'a que 256 de ram au lieu de 512, un seul USB, et pas de port réseau, mais du coup il consomme presque moitié moins.
J'ai upgradé mon robot (R.cerda) avec le modèle A sans le moindre souci, et du coup j'ai pu utiliser une batterie LiIon avec un
régulateur step up plutôt que de devoir faire du step down, ce qui aurait requis deux batteries LiIon en série, ou une 2S.

En bref, on peut réellement faire les développements pour un pi modèle B, et le remplacer par un modèle A à la dernière minute,
ça rentre parfaitement. Le contraire n'est pas forcément vrai, car il y a le port ethernet en plus sur le modèle B, et la conso plus élevée.

Je rappelle les specs : 700mA pour le B, 400mA pour le A.
PS : ce que j'ai dit pour "transferer la carte SD d'un modèle B à un modèle A" est sans doute valable pour la plupart des OS adaptés
au pi, mais moi je n'ai testé qu'avec Raspbian!

Bon courage pour la suite, et bravo pour tout le travail abattu, je vois plein de beaux circuits, et surtout les détails sont réellement peaufinés!

Au passage, je suis tombé sur ce LCD, qui est réellement minuscule, non rétro-éclairé, mais consommant très peu (2mA), ne coute pas cher (je l'ai eu pour environ 5€). ça peut servir de module d'affichage de diagnostic/affichage de certaines infos. Je dis ça, parceque avec un pi "headless", par le réseau, parfois on galère à trouver l'IP de la machine, ou on a envie de savoir une info
sans pour autant vouloir se loguer en SSH (bon, vous me direz sur le mien j'ai mis une interface web. Mais ça requiert quand même un ordinateur pour y acceder) On peut aussi afficher l'état de la batterie, les capteurs pour le debug, enfin tout un tas de trucs utiles...En fin de compte ça consomme moins qu'une LED, tout en étant plus précis...

Bref, un petit LCD de ce genre peut être pratique; d'autant plus si on ajoute une puce derrière (moi j'aurais mis un attiny2313, mais mike118 pourra sans doute faire la même chose avec un pic minimal moins cher!
Du coup ça permettrait d'avoir un composant fonctionnant en I²C, pourquoi pas avec une adresse réglable par jumpers, consommant peu, et qu'on pourrait couper, qui afficherait des trucs. Et éventuellement, avec 2-3 boutons, on pourrait même faire une petite interface, qui permettrait de lancer tel ou tel programme, configurer l'IP, activer/désactiver le wifi, etc...

Dernier point, je vais essayer de nettoyer/commenter le code dont je dispose pour le mettre dans un coin de la dropbox, si ça peut servir. La plupart du temps, le code est disponible sur des depots github de toutes façons.
Je mettrai :
-le code du robot
-un code de gestion de LCD
-le code du service qui permet de lancer un truc automatiquement au boot (ou de le lancer avec nomService start, de l'arrêter avec nomService stop). C'est pas encore parfait, mais ça fonctionne, et ça permet de lancer une commande sans acceder au shell, mais également de lancer une commande qui continue même si on quitte le shell.
Pour l'instant, je dois aujourd'hui avancer sur un article, alors j'y retourne

Bon courage les gars!

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 .

WAOW ... un grand merci.
Ont vas étudier tout cela.
Tiens nous au courant si ont fait des bêtises ou si ce que l'ont fait t'aide. />

C'est sur que je vais bien profiter du travail réalisé sur ce projet, car dans mon cas, je suis limité pour l'instant
à moins de 1A par moteur (voire 2 en doublant la puce, mais pas beaucoup plus). Du coup le circuit L298 m'intéresse beaucoup, de
même que la carte d'alim, les roues codeuses pour le contrôle de trajectoire, et tout plein d’éléments du même acabit...

J'ai hâte de voir les premières implémentations de chacun, qu'on puisse comparer nos constructions ^^

Salut!
Juste pour dire que j'ai mis les codes sources comme demandé.
Il y a du code pour un LCD, affichage de données de capteurs, du système, etc sur un LCD,
avec le code du daemon unix associé, et aussi du code pour un robot raspberry pi (R Cerda)
utilisant un driver de moteurs (donc compatible avec le L298 choisi, suffit de changer les broches),
et utilisant un capteur de distance ultrasons, et un détecteur de contact à base de microswitches.

Dans tous les cas, le code est facilement adaptable. Les lectures analogiques sont faites via un MCP3008 en SPI.
Il y a aussi du code pour afficher un flux webcam dans un browser web, et commander le robot depuis
la même page, en vue intérieure du robot.
Il y a des readme detaillés pour chaque ensemble.

Au passage, je vous rappelle que j'ai mis un gros paquet de tutoriels couvrant divers trucs sur le raspberry pi
à l'adresse suivante :
http://forum.pcinpact.com/topic/165594-raspberry-pi-fabriquons-des-trucs/

Et du coup il y a les codes associés (par exemple pour le LCD, câblage et création du daemon, l'interfaçage des puces,
du LCD, l'utilisation du pi sur batterie, lecture de divers capteurs, streaming d'un flux webcam, et encore d'autres trucs.
A chaque tuto, j'ai mis le câblage, les explications et les codes sources. A l'avenir je ferai les schemas avec fritzing et je
fournirai le fichier fritzing egalement pour que tout un chacun puisse le modifier à sa guise.

J'espère que ça pourra servir!

Hello!
Je reviens sur le but précis de ce robot, à mon sens. Je comprends les approches "ingé", mais je ne suis pas d'accord avec ces visions.
l'idée ne serait pas à mon sens de faire un robot capable de faire ceci, cela, et trucmuche, mais au contraire une "base robotique", comme dit par d'autres, à
savoir un robot de base, emportant les fonctions vitales, à savoir une alimentation pour le Raspberry pi, un moyen de se déplacer, des systèmes de commandes
pour les moteurs, de quoi lire des capteurs, et des entrées-sorties programmables disponibles, protégées, et accessibles.

Les spécifications plus précises concerneraient la puissance motrice, les dimensions, et un système de châssis qui permette l'extensibilité du robot.

Pourquoi? parceque si on décide de faire un robot capable de faire un certain nombre de tâches précises, alors ça sera juste un autre robot. Ici pour moi l'idée, ce
serait d'avoir une espece de "framework", un peu comme Arduino peut l'être, ou on a une base capable de faire plein de trucs, mais qui en elle même ne fait pas forcément grand chose.

A partir de là on pourrait proposer une configuration type assez simple, genre "robot éviteur d'obstacle", ou "robot suiveur de lignes", histoire que quelqu'un qui achete le KIT se retrouve avec un robot qui fait déjà quelquechose. Un peu comme le programme blink par défaut des arduinos.

Mais l'idée ne serait pas d'avoir une liste de fonctionnalités prévues au départ, mais une base capable de se déplacer, lire des capteurs, et utiliser des E-S programmables, et ce de façon autonome.

A partir de là, l'intérêt, c'est que si on a réussi a standardiser un système de châssis, de modules, etc, on pourra prendre cette base a 100€ qui fait deux trois trucs de base, mais les fait bien, et proposer à l'utilisateur d'ajouter tel ou tel capteur, un bras robotique de tel modèle, bref des modules, un peu au sens des "shields arduino", mais pas forcément aussi "plug and play", qui permettent à chacun de partir d'un robot générique pour arriver à un robot qui fait un truc bien précis. Par exemple, en ajoutant une webcam, faire de la navigation vidéo, reconnaissance de terrain, etc.

En ajoutant une tourelle "lance bidules", transformer le robot en un robot de combat qui embête les gens en leur balançant des bidules dans les cheveux, etc...

Et si c'est bien conçu, le tout serait combinable, de sorte que tant qu'on ajoute pas plus de X kg de modules, pour une consommation maximale de Y mA, avec des contraintes spatiales à définir, eh bien on puisse ajouter autant de modules qu'on veut.


Pourquoi cette approche? parceque ainsi, avec une bonne base, on pourrait tous partir de ça, débutants comme confirmés, et chacun pourrait tenter des expériences/idées à son niveau, mais en outre, de par la standardisation, les trouvailles de chacun seraient facilement exploitables par les autres. Et comme on aurait standardisé, il serait possible à plusieurs membres travaillant sur une base commune d'envisager un projet super ambitieux, chacun développant une partie avec son robot, et on combinerait le tout à la fin...

Par exemple transformer le robot de base en un robot qui gère sa charge automatiquement, se balade dans un environnement qu'il cartographie, et en utilisant des capteurs vidéo, serait capable de faire de la reconnaissance d'objets avec openCV pour reconnaître certains objets, avant de les saisir avec son(ses) bras articulé(s) pour les ranger à une place de référence...

Sur ça on pourrait avoir quelqu'un sur la reco avec openCV, quelqu'un sur la manipulation , quelqu'un sur la cartographie de la zone, et tous travaillant sur une base commune...

Et dans tout ça, celui qui est juste intéressé par un bras robotique pour un robot simple, qu'il télécommanderait, pourrait prendre les bidules développés pour la manipulation pour l'adapter à son projet...

Enfin c'est comme ça que je le vois moi.
Générique, extensible, abordable, modulaire et standardisé.

Et au passage, si on s'est bien débrouillés sur la standardisation, rien n’empêche d'envisager des versions différentes du châssis, par exemple une version plus grosse, plus puissante, ou une version "marcheur", mais compatible avec les modules...

"I have a dream. In my dream, every user, advanced or beginner, would be able to build a robot complying his needs using our base."

Merci a toi pour tes commentaires. J'adore te lire />
Reste bien avec nous sur le fofo et aides nous un jour si tu peux.
Tes tutos m'ont beaucoup aider dans mes recherche. Pour le moment je travail la partie électronique et après je bosserais sur la partie prog.
En tous cas ça fait plaisir de te voir dans ce topic.
Bonne chance pour tes recherches />

Merci
Je n'abandonne bien sur pas les robots, je pense même pour le long terme m'en servir pour les enseignements à la fac (je pense que
ce serait plus "concret" pour apprendre certains concepts de programmation que de simplement faire coder un programme qui calcule
des moyennes par les étudiants de première année!).

Moi aussi je dis merci />

Pour le moment je reconnais que j'ai pas pu bosser à fond sur ce projet non plus ... J'avais un truc sur le feu pour avant la fin du mois et ça m'a pris pas mal de temps ! x) ( cube RGB 8*8*8 pour un amis =) )
Mais bon là je touche au but et je mettrais quelque photo avant la fin du moi. Le cube est complètement soudé. la moitié des cartes sont faites je vais finir à temps />
Pour l'écran LCD Je suis d'accord avec l'idée ^^ Il me semble que j'en avais parlé dans les premier posts =) Après il faut juste savoir si on préfère l'érgonomie ( écran plus grand ) la consommation ou le prix ... Par contre rien ne nous empêche de prévoir le code pour un écran et à charge ensuite à qui veut de mettre l'écran qu'il souhaite />
Pour le reste je vous dis à bientôt pour de nouvelles aventures ! =)

Cube RGB led ,8*8*8, ça fait donc 512 leds RGB, donc 2048 soudures
J'ai hâte de voir ça ^^

Pour le LCD, j'ai mis des LCD sur mes raspberry pi, et j'en ai toute une collection (deux 4*20 RGB, je ne sais pas combien de 2*16, et le 2*8). Et tant qu'ils utilisent le driver HD 4000 quelquechose qu'il y a sur la majorité des LCD, c'est très facile de passer de l'un à l'autre. De plus, l'interface se fait avec 14 broches (8 de signal, mais on peut en utiliser 4), deux trois broches de commande, le VCC et la masse. Les modèles rétro-éclairés rajoutent 2 broches, et encore 2 de plus pour ceux avec un rétro-eclairage RGB. Dans tous les cas, les 14 premières broches sont les mêmes, puis il y a le câblage du rétro-éclairage qui peut changer.
La seule différence c'est que certains ont 2*7 broches plutot qu'une rangée de 14 (par exemple mon LCD 8*2). Mais ça reste pareil , on continue sur la rangée suivante avec le même ordre.

Bref, en résumé, j'ai du code de LCD qui passe par un MCP23017 ou MCP23008 qui est compatible avec tous ces LCD, sans avoir de programmation particulière. Simplement, dans le code, on mettra lcd(8,2) , lcd(16,2), lcd(20,2) ou lcd(20,4) par exemple!
Du coup, on peut facilement prévoir une rangée de connecteurs, ou même un connecteur spécial pour brancher le LCD! L'autre solution serait de penser un petit module qui embarquerait le MCP23008/23017, trois jumpers pour définir l'adresse I2C, et du coup il suffirait de connecter le module "affichage" sur le I2C, le +5v et la masse

Je mettrai tous ces codes sur la dropbox.
A bientôt, et encore bravo pour tout le boulot abattu!

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!

Je pense que cette méthode pourrait être envisagée pour connaitre la distance parcourue, par contre ça ne permettrait pas au robot de se représenter son orientation dans l'espace (ou il en faudrait deux). De plus, le coût risque d'être plus élevé qu'avec de simples fourches optiques (une fourche optique coûte moins de 2€).

La fourchette, c'est bien les capteurs avec d'un coté une LED IR et de l'autre le récepteur?
SI oui, il indique le mouvement de la roue, mais pas le patinage!

Maintenant, il est certain qu'avec un budget serré, il faut faire des concessions
Après c'était juste une idée, les capteurs type souris, car je ne connais pas leur prix (mais ça doit pas être si cher, vu qu'on peut acheter des souris optiques à 5€).
Par contre la question est de savoir à quelle distance ce genre de capteurs peut fonctionner, car cela les rend peut être inutilisables dans notre contexte.
Mais je me dis que ce serait un truc à tester, avec une (ou plutot deux) souris optique, et sur un robot raspberry pi, en les mettant près du sol...
Si ça fonctionne, ça pourrait être un hack intéressant

Au pire, on peut imaginer avoir les capteurs qui surveillent les roues, et le capteur d'une souris bidouillée, branchée en USB, qui indique si le robot bouge ou pas, et en combinaison
de la rotation des roues on pourrait détecter le patinage et tout (et même la vitesse réelle du robot, etc)

C'est exactement cela ! Le tout en restant dans une " base poussée " mais en dessous des 100 euros !
exemple concret : proposé une batterie avec un chargeur usb pour 5 euros ça peut faite partie de ce côté "poussée" cependant comme le robot reste modulable ce bloc pourrait être remplacé par une autre batterie !
Par contre en effet si on embarque la raspberry pi c'est pas pour rien !
Le but améliorer le niveau de chacun de manière concrète en travaillant sur une même base que l'on pourra ensuite chacun faire évoluer dans les sens qu'il nous plaira le plus ... Un peu comme la raspberry : c'est un beau bijou autour duquel il y a une belle communauté mais on peut aussi bien en faire un serveur que le cerveau d'un robot !
On est limité certes mais profitons de tous les avantages que l'on peut mettre en oeuvre pour réussir à faire ce que l'on peut faire de mieux ! à nous de définir notre standart !
Parfaitement d'accord ! la carte de puissance sera générique ! tu pourrais directement la bracher au PI... Par contre plus délicat serait de faire des trajectoire " propre" ...
ensuite le boutloader intégré, on met un micro usb femel sur la carte qu'on fait et il suffit de prendre le cable qu'on a pour recharger notre téléphone ! Et en même temps on recharge notre robot ! En plus autant faire en sorte de pouvoir le reprogrammer par le Rpi qui à ce qu'un programme fasse reprogrammer le pic esclave si nécessaire en reliant le pic au Rpi par usb ...

En tous cas, j'aime bien cette idée du composant USB multifonctions
Et puisque tu sais designer des circuits, c'est chouette, pour ma part, je me limite à soit des circuits simples, soit des modules dédiés pour le moment ^^

entre 2.7 et 11.8V ! c'est pas mal ! Par contre 1A c'est pas un peu limité non ? si on branche un petit truc en usb ... ça risque d'être un peu limite non ? Peux tu faire différents essais ?
Au pire c'est le genre de truc qu'on achète pas tel quel mais qu'on implante directement sur notre carte ! Pour moi pas de problème pour implanter cela !
Il faut se dire qu'on est pas limité au traversant ! Et qu'on ne doit pas forcément tout acheter tout fait ... En l'intégrant sur une carte qu'on doit faire de tout façon on va gagner la différence entre le prix affiché et le coût des composants !

En fait le 1A en sortie est très suffisant pour un pi modèle B. Le modèle B consomme 700mA. En pratique, j'ai déja fait des tests :
Sur ce post je démontre un montage d'un Raspberry Pi, avec une webcam USB, une clé Wifi, streamant un flux webcam, et avec des tests d'autonomie.
En pratique, avec 5 piles AA sur le modèle B, streamant un flux webcam en wifi, je tiens à peu près 3h (un peu moins).
De toutes façons j'ai lu que quand on tire trop sur l'USB du Pi, on peut avoir des tensions USB basses; il vaut donc mieux à priori ne pas alimenter des périphériques trop lourds en conso avec le PI.
Cependant, on a 1A disponible sur le régulateur; et le pi modèle B prend 700mA, donc ça nous laisse 300mA, ce qui est largement suffisant. Dans mon cas, la clé wifi était un modèle wifi n 300mbits/s, mais connecté en wifi G (mon routeur wifi est en 802.11G, je l'ai passé sous openWRT, du coup j'ai viré mon point d'accès wifi draft N qui lui a un firmware propriétaire).
Bref, en pratique, ce composant suffit largement pour un PI, une webcam HD, une clé wifi classique, sans compter tout ce qui est alimenté par le pi (un MCP3008, un MCP23017 et divers petits capteurs).
Partant du fait qu'on parle d'un robot, on ne devrait pas de toutes façons ajouter de périphériques consommant trop sous peine de grêver l'autonomie... le Pi modèle B consomme déja beaucoup!

pour la raspberry modèle A ça pourrait être une bonne idée pour limité les coûts ! On fera peut être un robot B et un robot A ! />
En tout cas pour le moment je suggère de commencer avec le modèle B car c'est pour l'instant le plus répandu du moins il me semble ( j'ai un raspberry pi modèle B depuis peu ^^ )

Bah la différence de prix existe, mais n'est pas énorme, entre les deux. Mais pour moi l'intérêt du modèle A, c'est surtout sa conso de 400mA au lieu de 700... ça permet de simplifier le design si on utilise mon régulateur, en prenant 4 piles AA ou moins, des batteries lithium, etc, et en faisant du step-up...
Par contre, il y a un point sur lequel je ne te suis pas, c'est quand tu dis "partons sur le modèle B". En fait je suis d'accord pour bosser avec des modèles B en prototypage, mais comme les deux modèles sont TRES proches (normalement, ils sont interchangeables dans un montage qui n'utilise pas l'ethernet), on pas besoin d'optimiser le robot pour un modèle ou pour un autre, on peut faire une conception embarquant simplement un Raspberry pi, au choix de l'utilisateur Moi aussi, je n'ai que des modèles B pour le moment, donc c'est ce que j'utiliserai ^^ Mais à mon sens on devrait faire en sorte que l'utilisateur puisse indifféremment utiliser un modèle B ou un modèle A!

Au passage, le module caméra devrait être bientôt dispo, donc ça rajoutera une option vidéo de haute qualité, faible encombrement,avec un bus rapide, pour pas cher ^^

Bon pour moi le code c'est encore loin mais il me semble important de commencer à créer des fichiers excels référençant les références énoncés etc ...
J'ai donc créer un dossier drop box. J'invite tous ceux qui le souhaitent à m'envoyer leur mail pour partager le dossier .
Concernant le versionning, je pense qu'en s'organisant bien ( en reprennant le modèle de l'entreprise dans laquelle je travaille ) juste drop box ça peut largement le faire :
Il suffit à chaque nouvelle version noter : faire le dossier à coté avec le numéro de version implémanté et faire un " release note " signé par la personne qui fait la modif ...

Je t'envoie un MP ^^
Mais pour l'instant du coup je ne sais pas bien ce qu'on doit faire, si tu as des tests préliminaires que je peux faire avec mon matos, fais le moi savoir. Par contre il faudrait que
je me procure un équipement pour mesurer précisément la consommation des composants, car je m'appuie sur les specifications officielles, sans plus de précision que min-max.

En tout cas les 100 euros sont bien toujours dans l'optique du projet ! Mais le robot ne s'arrêtera pas à ces 100 euros ! 100 euros c'est "la base ", ce qu'on va considérer comme " notre standard " et qu'on doit créer tous ensemble .

Je vois; c'est dans cette optique que j'avais pensé mon robot Cerda. Je ne lui ai presque rien ajouté pour le moment, car je souhaitais voir le maximum que je pouvais tirer d'un robot doté uniquement d'un capteur ultrasonique et de capteurs de contact.


Au passage, ton approche montage de circuits sera très utile, car si on peut faire certains éléments nous même plutôt que d'utiliser un µC ou un composant tout fait, on peut sans doute optimiser le tout pour l'adapter à nos contraintes...

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?

hello!
Juste une précision : il semble qu'il ne faille pas alimenter le RaspberryPi par les GPIO, car du coup ça bypasse les fusibles,
et que le système n'est plus alimenté. De plus il y a deux régulateurs (le 3.3v et le 1.8v) qui prennent leur source près du microUSB,
ce qui pose un certain nombre de problèmes (longueur des pistes, condensateurs mal placés, etc) si on alimente depuis les GPIO.

Je ne saurais pas vous donner toutes les raisons, mais à ce que j'ai lu, le consensus était plutôt que c'etait une mauvaise idée, même si ça fonctionne pour ceux qui ont essayé malgré tout, car il y a risques de "grillade" du Pi en cas de mauvaise manip. Et en cas de court circuit, pas d'extinction du circuit concerné, il va simplement griller.

Pour l'analyse du déplacement du robot, je voudrais proposer une idée :
ne peut on pas avoir un capteur optique dirigé sur le sol, comme ceux des souris, qui indiquerait le mouvement du robot?

Proposition de cahier des charges
Puisque nous sommes sur un cahier des charges de prototype, je vous propose mes idées, et les raisons qui me poussent à proposer ces solutions.

Coeur du robot
un Raspberry Pi, modèle A ou B, car c'est la définition même du projet. De plus, il y a dejà des tonnes de prototypes Arduino, PIC, etc...
Les deux modèles sont interchangeables, sauf pour l'Ethernet. Donc pas besoin d'optimiser pour un modèle ou un autre. Le B a plus de ram, donc potentiellement
la possibilité de faire plus vite certains calculs en optimisant pour plus de ram. Le modèle A consomme 400mA contre 700 pour le modèle B, ce qui peut très grandement
optimiser l'autonomie du robot en veille.

Environnement type cible
Terrains plats pas trop difficiles. Toutefois la base envisagée pourrait facilement être adaptée à un environnement différent, je détaillerai davantage dans la section motorisation.

Dimensions
Pour moi, on devrait partir sur des dimensions relativement compactes, du genre moins grand qu'une feuille A4. Pour moi, moins, ça serait mieux, le format idéal serait environ du A5, car ça ferait un bidule transportable, utilisable en appartement pour expérimenter, capable de se faufiler un peu partout, mais sans pour autant sacrifier l'autonomie, l'évolutivité, etc.
Pour le poids, le mien fait 610g hors batteries, donc environ 750g en incluant tout. Mais j'ai pris du contreplaqué très dur pour faire le châssis, en 12mm d'épaisseur, et c'est simplement un gros rectangle plein. Donc il y a a mon sens une large marge d'optimisation. Mais pour l'échelle, je pense qu'on peut dire sous le kilogramme.

Charge utile
Sur ce paramètre, je n'ai aucune expertise pour estimer la charge utile d'un robot. Je comprends comment calculer des choses par rapport au couple, mais je n'ai pas fait de calculs
du point de vue physique pour voir la masse que peut déplacer un robot en fonction du couple sur un plan horizontal, car je n'ai aucun moyen d'estimer le frottement, ni même l'efficacité
avec laquelle le robot transmet la force mobile à la route. Mais je pense qu'on pourrait parler de robots déplaçant des charges mesurées, car si le robot doit déplacer 10kg, il faudra sans doute des moteurs consequents, incompatibles avec l'optique de faire moins de 100€

Mode de locomotion
Pour ma part j'opterais pour un robot roulant, car les marcheurs sont souvent plus complexes à fabriquer, et coûtent vite cher. Il faudrait un circuit de contrôle pour les servos, et au moins 2 servos par patte, soit 8 pour un quadripède, si on a 4€ par servo, ça monte déjà à 32€ rien que pour les servos, soit le tiers du budget.

Motorisation
Je vote pour les moteurs DC, avec boite de vitesse intégrée. Il en existe des tonnes, on en trouve des pas chers du tout, c'est facile à utiliser, et pour l'évolutivité c'est extrêmement simple, car on peut facilement remplacer un moteur par un autre, tant que le driver peut fournir la puissance nécessaire. D'autre part, avec des steppers, il faudrait un driver plus complexe, ce qui augmenterait les coûts, sans compter que les steppers coûtent un peu plus cher de base, et je n'en ai pas vu des masses avec boite de vitesse intégrée... Pour les servos à rotation continue, ils sont simples et permettent de se passer d'un IC pour les commander, mais le RPI n'est pas très bon en PWM, donc il faudrait quand même une puce pour s'en charger, et en plus ils sont chers, un peu gros si on veut un couple sympa, et comme c'est plus rare et spécifique, moins interchangeable. Mais je pense qu'on pourrait se débrouiller pour envisager un châssis modifiable pour accepter d'autres types de motorisation!

Système de propulsion
Cette question se pose elle réellement? il faudra prévoir des roues/chenilles standard, mais il est facile de trouver des systèmes interchangeables, en laissant à tout un chacun le choix
d'utiliser des roues, des chenilles, ou même d'autres systèmes (roues omnidirectionnelles, ou des "roues-pattes", pourquoi pas?).
De la même manière, on peut facilement faire un système qui permet de passer d'une configuration 2 roues motrices à 4 roues motrices, d'une configuration 2 roues motrices + roulette ou 2 roues motrices + 2 roues libres, traction ou propulsion, etc...
Je reviens donc ici sur l'environnement cible. Si on s'est bien débrouillés, il deivent donc ici facile de passer à des chenilles, ou 4 roues motrices, ce qui nous permet d'envisager une utilisation en terrain moins clément, donc avec des bosses, des creux, une surface irrégulière, etc...

j'ai testé mon robot en extérieur, sur un sol pas si plat, et avec les chenilles il se débrouille plutôt correctement... Je vois pas mal de façons pour lui de se coincer, mais avec une meilleure conception ou tout simplement des chenilles plus grosses, il pourrait franchir déjà beaucoup plus d'obstacles!

bref, on peut envisager une adaptabilité du robot au terrain par une possibilité de modifier facilement l'aspect motorisation et l'aspect propulsion, dans les contraintes de la carte de contrôle des robots... Et même sur ça, comme on aura bien standardisé, on peut envisager la possibilité d'utiliser un modèle plus puissant. Mais bon si on consomme plus, il faut de plus grosses batteries, donc un plus gros chassis, et la ça commence à faire beaucoup de changements

Module de gestion des moteurs
Je reprends les propositions de mike :

• Tension d'alimentation des moteurs comprise entre 3V et 24V;
• Capable de délivrer 2A en continu;
• Protection de sur intensité;
• Commande simple en PWM + direction;

Circuit d'alimentation
Je reprends les suggestions de mike:
accepter entre 3V et 24V -> moi j'aurais vu moins large, genre 3-12v, ou alors même plusieurs modules adaptés à des plages plus étroites à choisir selon les batteries qu'on choisit, pour réduire le cout.
alimenter le rpi en 5V de manière sécurisé -> obligatoire sinon le Pi ne fonctionnera tout simplement pas
intégrer la recharge -> moi je suis complètement pour, mais peut on le faire pour pas cher?
J'ajouterais toutefois ceci : qu'il y aie une/des broches qui pourraient nous permettre de mesurer la tension de la batterie.
Idéalement, si on pouvait avoir des broches ou brancher un circuit de mesure de l'intensité ce serait parfait, ça permettrait d'envisager
des applications du genre "le robot fait des essais pour voir ce que lui coûte en énergie l'activation de chaque organe", et on pourrait envisager
d'avoir un robot qui optimise ses actions en fonction de l’énergie que ça coûte, ou bien du temps, etc, selon les priorités...
A noter que la mesure de la conso peut permettre d'établir quand les moteurs sont coincés... Mais du coup la ce serait plus précis si on a possibilité
de mesurer ce paramètre aux bornes des moteurs.

Organes sensoriels
A mon sens, ici, on doit être le plus générique possible, et prévoir la possibilité d'utiliser divers types de systèmes.
Cependant, pour un modèle type, il serait souhaitable d'avoir un capteur répandu, éprouvé, et je propose les capteurs ultrasons.
Le capteur infrarouge est envisageable, mais il faudrait sans doute un servo avec pour l'orienter et faire un balayage devant le robot, non?

Châssis
Si on pouvait avoir un système modulaire, un peu à la meccano, mais tout en étant pas trop cher et solide ça serait parfait.
Sinon bah je ne sais pas trop, du plexi? avec des trous réguliers pour assembler des trucs dessus? je n'ai pas trop d'idée ici,
dans mon cas je fabrique les châssis avec ce que j'ai, ou alors sur mesure si j'ai envie d'optimiser. Je n'ai pas beaucoup d'expérience
dans le domaine des châssis de robots, et je suis séduit par le tuto que j'ai lu ici sur la fibre de verre/fibre de carbone, mais la encore
c'est du sur mesure, et difficile à proposer comme "bidule standard à acheter à tel ou tel endroit".

Programmation
Idéalement, ce serait parfait si on pouvait programmer le robot dans le langage de notre choix. Du coup si il y a un µC, il faudrait avoir
des codes sources/exemples dans divers langages pour la communication avec ces puces. Pour mon robot, par exemple j'utilise python parce que
j'ai un MCP23017, et que je ne sais pas m'en servir avec du C (établir la communication en I²C, et tripatouiller la puce depuis le C/C++)
Idem pour mon MCP3008.

Composants annexes
SI il faut un ADC, je propose le MCP3008. Mais simplement parceque c'est le seul que je connais, et je sais l'utiliser sur le Raspberry Pi.
Maintenant si vous en avez des mieux (par exemple un modèle I2C, qu'on pourrait chainer pour avoir plus d'entrées analogiques si le souhaite),
ou tant qu'à faire un µC connecté en I2C avec le PI qui s'occuperait de ces questions?

Communications entre modules
Pour l'instant je ne m'y connais pas énormément entre les protocoles de communications. j'aime bien le I2C parce qu’il prend peu de GPIO (juste 2),
qu'on peut chaîner plein de modules tant qu'on met des adresses différentes, et que du coup on garde quand même l’accès aux GPIO dédiés à l'I2C.

Hello
Bon, je n'ai pas beaucoup travaillé sur le projet (je suis un peu overbooké ces jours ci, je pars présenter un papier à Bruges le 22, et je suis blindé d'obligations juste avant )
Mais avant de partir, j'ai complété mon tuto sur un robot Raspberry Pi à environ 100€.

Voici le lien :
http://www.robot-maker.com/forum/tutorials/article/78-rcerda-un-robot-raspberry-pi-pour-100-120/
J'y expose quelques idées, et peut être qu'il y aura quelquechose à récupérer dedans
Après, j'ai procédé très "à l'arrache", donc ce n'est pas forcément super carré.

Par contre, c'est le résultat que je parviens à avoir pour environ 100-120€. Donc ça permet de fixer une référence en matière de fonctionnalités, complexité, etc, car j'ai pris ce que je trouvais de moins cher la plupart du temps!

Maintenant avec des PCB designés pour remplir plusieurs fonctionnalités, on peut certainement faire moins cher sur certaines parties et aller plus loin sur d'autres!

Je viens de regarder, c'est une extrusion de type bowden, ça veut dire que tu as ta buse qui bouge, et le filament qui passe dans le tube  est poussé par un mécanisme déporté (par opposition à une "direct drive", ou le mécanisme d'entraînement est sur la tête d'impression directement). Donc tu devrais avoir vers l'arrière ou au dessous un bloc d'ou le filament sort, c'est à cet endroit qu'il faut regarder.

 

Puisque c'est une bowden, tu auras certainement le moteur pas à pas (un gros bloc noir, carré, avec un axe chromé qui en sort), et un système d'engrenages fixés à la sortie dans lequel passe le filament. Sur les bowden, les engrenages sont généralement gros, donc c'est plus facile qu'une cochonnerie se coince dedans! donc à vérifier.

 

Peut être que ça peut aider de faire tourner le moteur d'extrusion à vide (par exemple dans cura ou un autre soft compatible), pour voir si l'effet se reproduit également.

Hello, c'est pas de bol quand même d'avoir un jamming de l'extrudeuse en si peu de temps!

En deux ans d'impressions, ça ne m'est encore jamais arrivé !

Effectivement, par contre quand ça arrive, il est difficile de dévisser l'ensemble, car le plastique qui a refroidi fait un joint solide.

Certains chauffent la pièce pendant le démontage pour faciliter. Par contre attention à ne pas éloigner la cartouche chauffante de la sonde de température, sinon, l'imprimante pensera que la tête refroidit et essaiera de chauffer, et ira trop loin.

Peux tu nous poster une photo de cette partie, pour voir comment c'est fait?

Bonjour,

toutes les imprimantes 3D utilisent des moteurs pas à pas pour déplacer les axes. Ces moteurs font du bruit en tournant. Ce n'est pas non plus énorme, et ça dépend 

des modèles (certaines arrivent à des niveaux de bruit très faibles), mais toutes les imprimantes 3D normales feront du bruit, sans modification de la part de l'utilisateur.

Maintenant, c'est un bruit comparable à des machines du genre imprimante classique, scanner, etc.

Donc difficile de dormir à côté, dans la même pièce. Par contre derrière UNE porte, ça suffit à stopper le bruit.

 

Les vibrations sont minime, et le bruit n'atteindra jamais les voisins, à moins que les murs soient en papier.

Ce n'est pas une découpeuse numérique, donc le bruit est TOTALEMENT gérable pour un appartement.

 

Et avec un peu de boulot (une "enclosure", je sais pas comment le traduire, bien, en gros une sorte de boite qui va autour) on peut drastiquement baisser le bruit au point de

la rendre très silencieuse. 

 

Sur un bureau ou on travaille, c'est vite chiant par défaut, avec les bruits si on doit faire autre chose à côté; mais encore une fois, en mettant un peu de musique sur des HP de bureau, ou un casque, ça couvre.

 

Encore une fois, je comparerais à une imprimante classique ou un scanner (je dirais entre le deux, mon scanner fait peut être plus de bruit; et mon imprimante laser fait également probablement plus de bruit. Par contre une petite jet d'encre est plus silencieuse).

 

Pour le kit, je confirme, j'ai pris la mienne en kit, et du coup je sais comment et pourquoi elle fonctionne Par contre, un kit, il faut plutôt prévoir le week end pour tout monter, surtout pour une première fois. Et surtout faire le câblage/électronique à tête reposée, car de mauvais branchement peuvent avoir des conséquences néfastes. Vérifier deux trois fois les trucs importants, et après c'est super!

 

Sinon Oracid, généralement, tu peux régler la puissance disponible pour chaque stepper (les moteurs de chaque axe, + l'extrudeuse). Pour ce qui est de mesurer directement, je ne sais pas, mais normalement tu as un petit potentiomètre pour régler ça. Tom Sanladerer à fait une vidéo sur le réglage : 

En gros, l'idée c'est de chercher à réduire le courant autant que possible, et quand ça commence à ne plus suffire, tu remontes le courant un peu. Généralement c'est censé baisser la charge sur les composants, et aussi réduire le bruit.

Sur la mienne, je ne me suis jamais donné la peine de le faire

Hello, voici le bouton dont je parle dans cura :

Pour qu'il apparaisse, il faut charger un modèle 3D, sinon c'est grisé et non cliquable.

Il faut aussi sélectionner "Fichier -> Préférences -> modèle de fenêtre d'impression ->pronterface UI", sinon on a un truc tout basique.

 

Sur la photo ci dessus, le bouton en question est celui de la petite disquette, en haut (j'avais mis le curseur dessus, mais je me rends compte qu'il n'est pas sur la capture). Quand l'imprimante est branchée, ça affiche plutôt "imprimer via USB".

 

Voila une image trouvée sur le net de cette fenêtre

Et là, on peut utiliser les boutons pour extruder et tout.

 

Concernant ton problème d'extrusion, justement, la roue dentée qui entraine le filament est elle visible?

Si oui, il faut regarder si elle glisse sur le filament, ou si au contraire elle bloque.

 

A part une buse bouchée, je ne vois pas bien pourquoi ça bloquerait, par contre si le profil des dents est trop doux, ça peut ne pas "mordre" le filament suffisamment pour l'entrainer...

Ou alors c'est que le ressort qui met la roue en compression contre le filament n'est pas assez serré, dans ce cas, il suffit de le serrer avec la vis de réglage prévue à cet effet!

Hello,

En fait, pour faire ça il faut pourvoir utiliser le cura "normal".

 

Avec le mode d'impression avancé (pronterface UI), tu peux lancer la chauffe de la tête d'extrusion sans lancer d'impression,

et aussi contrôler les axes (déplacement X, Y, Z et avancée du filament).

 

La température est réglable, dans ce cas là.

Au passage, en cherchant j'ai pu retrouver que ta tête d'impression est une E3D V6 (c'est parmi ce qui se fait de mieux sur le marché),

du coup tu peux trouver des infos supplémentaires :

 

http://wiki.e3d-online.com/wiki/E3D-v6_Troubleshooting

 

Ceci dit, la pièce que tu veux insérer, c'est bien le petit cylindre métallique chauffant, si j'ai bien compris?

Du coup lui n'est pas en contact avec le filament directement (je pensais que c'est la buse que tu démontais), donc normalement

la chauffe ne devrait pas changer beaucoup ici en matière de plastique fondu..

 

En théorie, chauffer dilate le métal, donc je sais pas trop ce que ça donne.

Ceci dit, je sais que les mécanos chauffent les vis coincées pour les déloger, donc peut être que ça peut aider au moins à desserrer?

Comme toi alu. J'utilise de la colle Uhu, ça marche bien et c'est pas cher.

Et tu n'as jamais essayé le blue tape?

C'est simple, et il n'y a pas besoin de faire quoi que ce soit d'autre.

Tu recouvres la surface de scotch papier de peintre, et tu imprimes.

Quand le scotch est abimé, tu l'enlèves et le changes. Pas besoin de

nettoyer ou quoi que ce soit, et ça fonctionne à froid

Salut, je ne connais pas cette imprimante, en général pour quelqu'un qui commence, je dirais de regarder si il y a un système de mise à niveau automatique du lit;

s'il y a un lit chauffant (dans le cas contraire, il faut utiliser du PLA, pas d'ABS), et s'il y a de la doc dispo.

La mise à niveau auto n'est pas indispensable, mais c'est chiant à faire manuellement.

 

Edit : 

je lis : 

• La tête d’impression E3D V6 et l’extrudeur prêts pour vous (palpeur inductif inclus)

 

La E3Dv6 c'est le top des extrudeuses, et le palpeur inductif, c'est super cool, ça permet de faire la mise à niveau auto.

Donc ça me parait bien, je vois que les circuits sont dispos, le code source du firmware aussi.

 

ça n'a AUCUNE importance quand on commence, mais plus tard, ça veut dire qu'on peut ajuster des trucs si besoin, et qu'on peut ajouter des mods sur l'imprimante facilement

bref, ça parait bien! et comme c'est open source et que les retours sont bons c'est probablement que le produit est bon

Edit : 

Salut Oracid, tu as craqué ? Je suis sur le point de me l'offrir !!

 

Une question que je me pose : comment se comporte un imprimante à court de fil pendant une impression ? On recharge et elle repart où elle en était ?

Généralement, quand il y a un problème, l'imprimante ne sait pas, et tu t'en rends compte après, du coup il faut recommencer l'impression.

Pour le filament, quand tu arrives à court, l'imprimante bosse, mais dans le vide. Il existe des capteurs d'épaisseur de filament, ça a été intégré

au dernier firmware marlin, donc effectivement on devrait pouvoir ajouter une pause auto en cas de fin de filament.

Imprimer en diagonale à plat, oui. Dans la diagonale du cube, ça sera la méga galère, avec plein de supports, donc une impression

qui prend 3000 ans...

De plus à mon avis si tu as réellement besoin d'une poutre de 34cm de long, il y a d'autres moyens que l'impression 3D, par exemple un profilé alu,

et ce que tu imprimes, c'est la pièce qui tient la poutre de chaque côté par exemple.

 

Il faut bien voir que l'impression 3D, c'est quand même long, et on fait du plastique. Donc dans certains contextes, on risque d'avoir une pièce pas assez solide,

prendre trop de temps à imprimer, avoir des contraintes mécaniques ou thermiques inadaptées au matériau, etc...

 

encore une fois, pour faire un gros châssis par exemple, le mieux serait de couper 4 profilés alus, et d'imprimer 4 pièces qui font la jonction en L sur les profilés.

et les profilés viennent se fixer dessus comme ça :

|

L __

 

Après pour d'autres applications comme les roues, les supports de capteurs, ou tout simplement toutes les pièces complexes difficiles ou impossibles à fabriquer autrement, l'impression 3D est parfaite.
Mais pour faire une jolie grosse boite, c'est moins bien

Pour moi, l'idée ça reste d'être compatible LEGO en fabriquant des pièces qui n'existent pas.
Oui, je sais, c'est pas vraiment la vocation première d'une imprimante 3D, mais on se refait pas...
Dans le monde LEGO, l'impression 3D est très à la mode actuellement.

Dans ce cas, rien ne t'empêche d'imprimer la pièce en plusieurs parties assemblables, ou alors de faire une pièce qui prend les profilés alus ET possède les bitonios légo

 

Une chose à prendre en compte aussi : 

quand on fait une impression 3D d'une grosse pièce, qui prend 10 heures, si ça rate (coupure de courant par ex), c'est très chiant!

Avec plusieurs pièces assemblables, on ne perd qu'une partie du boulot!

De plus, souvent on fait sa pièce, et on oublie un petit truc... Du coup il faut en refaire une, et bam encore plein d'heures à attendre que l'impression finisse ^^

 

Après je dis ça mais j'ai mis des châssis monocoque sur mes nouveaux robots : si ça rate, je suis pas content!

Par contre pour tester, j'imprime des bouts, uniquement la partie qui pose problème...