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!

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!

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?

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?

...

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

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...

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!

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!
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."

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!

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 ^^

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?

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 .

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)

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!

Pour le bois, je te conseillerais plutôt le contreplaqué que le MDF. Le MDF est joli, donne de très bonnes finitions,
mais c'est un matériau assez flexible, trop à mon gout. En contrplaqué, je pense que tu peux faire plus fin.
Avec quelques poutrelles en alu pour faire la structure, et un peu de contreplaqué 5mm, tu as de quoi faire un chassis solide, à mon sens.

Sinon une solution, c'est de faire un chassis en poutrelles alu creuses , avec un treillis métalique pour la structure, et de la fibre
de verre/carbone/kevlar pour les surfaces. ça donnerait un truc léger et solide ^^

Attention toutefois avec la fibre de carbone, j'ai entendu dire qu'elle bloquait les ondes radio, donc les éventuels élements radio doivent "voir"
le monde extérieur.

Sinon il y a aussi le plexiglass, ou mieux le polycarbonate. Ce dernier est un matériaux au même rendu que le plexi, mais en nettement plus solide.

Quand tu dis que ton robot mesure 1m, il manque les autres dimensions ^^ 1m² de surface au sol? ou alors 1m³ de volume?

Parceque avec 1m de portée sur certains élements, tu aura des problématiques de souplesse avec des éléments légers, et des problématiques
de poids avec des éléments plus rigides.
Si tu as réellement une surface de 1m², je pense qu'il te faudrait une conception des sous éléménts triangulaires (un peu comme le principe des éléments de la tour effeil, des triangles) pour renforcer la rigidité de l'ensemble.

A mon avis, "porteur de microcontrôleur", ça doit être une traduction foireuse ^^

Par contre, un contrôleur de servomoteurs?
Si on a un µC, que peut on bien faire d'un contrôleur suplémentaire pour les servos? vu qu'on a une alimentation pour le servo et une broche de commande?

Peut-être qu'il compte utiliser beaucoup de servos et que l'µC ne suffirait pas.

Dans ce cas, je comprends

Oui mais la il faut utiliser une carte d’asservissement (shield).
Ne serais ce que pour proteger le µC.

Là, je comprends pas. De QUOI faut il progéger le µC? si seuls les câble "signal" des servomoteurs sont connectés, il faut protéger le µC de quoi?
On peut avoir de forts courants qui reviennent dans le câble de commande d'un servomoteur?

Bon bref,
faire une robot a chenille c'est pas donner (même en le bricolant soit même). (sauf pour moi, j'ai le bon filons /> )

Les contrôleurs pour moteurs pour chenilles d'un robot d'un mètre (environ) + (moteurs d’essuie glaces) c'est pas très difficile a faire.

µC => Drivers puissance => moteurs

une petite astuce aussi que j'ai déjà vue: les moteurs de perceuses sans fils. (gros couple)

Les moteurs de perceuses sans fil n'ont ils pas une vitesse trop importante, et une conso trop forte?
J'ai des perceuses/visseuses sans fil, et du coup je me dis que l'idée est intéréssante!

Du coup, ça a fonctionné comme tu voulais?

Bon courage alors

Bonjour,
Je suis en train de réaliser un petit robot qui fonctionne avec une télécommande radio (433Mhz si ma mémoire est bonne).
Les fonctions sont extrêmement simple : avancer, reculer, tourner à droite et gauche.
Le joystick est numérique à 5 interrupteurs.

Si le joystick de la télécommande est:
- "en haut", j'envoi un signal carré de fréquence 1kHz
- "en bas", j'envoi un signal carré de fréquence 2kHz
- "à gauche", j'envoi un signal carré de fréquence 4kHz
- "à droite", j'envoi un signal carré de fréquence 8kHz.

Ceci est imposé.

En revanche je voudrais rajouter une fonction : si j'appuie sur le joystick, j'allume une lumière sur le robot.
Je veux que si l'utilisateur demande d'avancer, relâche rapidement le joystick, appuie dessus et redemande d'avancer une lumière s'allume et le robot continue sa route.

Je me suis donc dit que j'allais ajouter une fréquence 16kHz d'émission. Mais c'est là ou je bloque.

J'avais pensé à :
si f = 16kHz alors lumière = 1 - lumière

Mais comment faire pour que si l'utilisateur reste appuyé, la lumière ne change d'état qu'une seule fois ?

Merci d'avance !!

PS: J'ai pensé aussi à si lumière allumé alors rapport cyclique du signal d'émission égal 50% et si on veut que la lumière soit éteinte alors 25%, mais ca complique un peu tout.

Pour ma part, j'ai eu cette problématique avec une interface utilisateur et des boutons poussoirs. Ma solution est d'utiliser une commande de type "toggle". Je m'explique.
Il y aurait une variable x quelquepart qui sert à reternir l'état précédent de la commande. Une seconde variable y stocke l'état de la commande reçue.
Enfin, une variable etatLampe, qui stockerait l'état de la lampe (allumé ou éteint).

Donc du coup tu fais par exemple:

x=0;
etatLampe=0;//eteint par défaut par exemple

loop()
{
   y=lireRadio()
   if(y==LIGHT)
   {
     if(y!=x)//si la valeur lue n'était pas déjà "LIGHT" à la précédente lecture,
     {
        etatLampe=not(etatLampe);//on inverse l'état. Si c'était allumé, on éteint, et vice versa.
        digitalPinWrite(ledPin,etatLampe);//et la ben on écrit effectivement l'état de la broche de controle de la led.
     }
   }
   //ici on insère les blocs des autres commandes
   x=y;//ne pas oublier de mettre à jour la variable "état précédent" pour le tour suivant!
}

Du coup, la commande de lumière ne prend effet que si l'on avait une autre commande avant. Si l'utilisateur maintient
alors que c'était éteint, la lumière s'allumera et le restera, jusqu'à ce que l'utilisateur lache et réappuie.
Idem pour le cas inverse.

Le système peut toutefois être sensible aux perturbations du signal radio, donc si l'utilisateur appuie en continu,
mais que le contrôleur voit ça comme plusieurs appuis, il pourrait clignoter (par exemple si il y a des perturbations).

Pour régler ce problème, une solution serait de ne changer l'état que si celui ci est similaire depuis au moins 100ms par exemple,
avec un compteur tout simple de tours de boucle, et une variable stockant quand la dernière lecture de la lampe a été faite.

Ainsi on filtrerait les microcoupures, et 100ms, c'est bien assez rapide pour que l'utilisateur ne remarque pas le délai à l'allumage/extinction.
Au pire on peut adapter cette valeur après des tests (utile si on veut envoyer du morse avec le robot ^^)

Suite à mes réflexions précédentes, je crois que je vais faire un "truc" qui va descendre lentement , se balader un peu au fond et remonter aussi gentillement. Donc et du coup je vais voir s'il n'est pas possible d'installer 4 caméras . 1 à l'avant , une en dessous , et 2 sur les côtés/dessus. Du coup le forme prendrait un genre parallélépipède. Dans ce genre déjà fait il y a le F117 furtif américain , ou dans la nature les poissons coffres lisses . On arriverait à un sous-marin avec l'avant un peu bombé, le dessous plat (ou un peu arrondi ) et 2 côtés qui se rejoignent en haut. Ce qui donnerait vite fait ça ; probablement plus allongé. Là il ressemble plus à un cachalot ! />/>/>


Après question caméras si j'arrive à résoudre le pb du stockage des données, les caméras de surveillance me paraissent très adaptés à ma situation. Elles peuvent enregistrer en très faible lumière, certaines sont assez petites et les prix semblent corrects.
Après il va falloir que vous m'aidiez pour que toutes ces idées puissent être robotisés , que les enchaînements se fassent dans le bon ordre quels capteurs pour quels fonctions ? ......
Voila pour mes cogitations, j'attends vos conseils vos remarques et critiques avec intérêt. Merci d'avance

Salut!

Si l'huile sous pression pose problème, alors le même problème se posera avec la pressurisation par gaz (le problème est la diff de pression entre l’intérieur et l’extérieur du composant, semble t'il)

pour le couplage magnétique, le problème c'est que la force magnétique décroit avec le carré de la distance, donc il faut que les aimants soient les plus proches possibles.
Enfin bref, il est compliqué d'avoir un ensemble parfait, donc un rendement parfait! Il y aura toujours un décalage entre ceci et cela, et donc moins d'efficacité.
Pour ma part, ce que je crains avec le couplage magnétique, c'est que l'axe externe "rate" des tours de l'axe interne. L'axe interne a peu de résistance, rien d'autre que les aimants. L'axe externe a la résistance de l'eau à combattre, donc la question est de savoir si les deux ne vont pas se découpler. du coup des pertes.
Enfin bref, c'est pas la question du jour />

Un petit conseil, si tu pars sur les caméras, je te conseille fortement d'éviter les caméras de sécurité. Elles sont chères, souvent avec une faible résolution (à moins d'être très chères), c'est généralement un gros bidule, pas forcémént facile à bidouiller, et pour accéder aux données, c'est en ethernet ou wifi.

Une solution plus adaptée serait un raspberry pi avec le module camera, le raspberry pi coute 25 ou 35€ pour le modèle A ou B/B+, et le module camera 25€. Celui ci existe en normal ou en infrarouge, donc avec un éclairage IR capable de filmer en faible luminosité (c'est la même technique que pour les caméras de sécurité).
EN plus on peut filmer en full HD, et les photos peuvent être jusqu'à 5Mpixels.

Un pi modèle A peut consommer environ 100-200mA en 5V, le module caméra environ 250mA sur le 5V, donc une conso modérée.
Bien sur l'avantage c'est d'avoir un ensemble programmable, avec plein de GPIO pour lier le tout à d'autre matériels, etc.

Mais si tu pars sur 4 caméras, tu vas exploser ton budget />
le pi + module caméra est la solution la moins chère que je connaisse pour ceci. SI on prend un modèle A à 25€ et une picam IR à 25€, ça fait déja 50€, auxquels il faut rajouter une alim (disons 5€), une carte SD (5€), soit environ 60€/camera. Du coup, ça fait déjà 6*4=240€.
Sans compter qu'il faudra des vitres pour chaque camera. Une vitre capable de résister à la pression c'est pas forcément donné. Il faudra du verre bien epais, du polycarbonate épais, ou alors, une chose utilisée dans le domaine, du quartz (je crois que c'était ça, à vérifier, mais ça se vendait cher, et c'était prévu pour ce genre d'usages), et enfin rajouter le joint/fixation...

Pour le dessin de ton sous-marin, c'est chouette comme forme, mais comment tu le fabriques? A moins d'avoir du gros matériel, je ne vois pas comment tu vas fabriquer ça.
D'autre part, la forme est nettement moins résistante à la pression qu'un cylindre...

Les ailes servent à quoi? tu veux exploiter un phénomène de portance? du coup l'aileron vertical, quelle est son utilité? il amène juste de la traînée et donc une perte d’efficacité!
De plus, dans l'ensemble, ou sont tes propulseurs?

Encore une fois, je pense que tu grilles les étapes. C'est bien de faire des esquisses, mais dans ce contexte, il faut penser à la réalisation et l'aspect fonctionnel en premier. Donc : comment fabriquer une coque résistante (trouver un tube d'acier comme base? du PVC de canalisation haute pression?). A partir de là, réfléchir ou mettre les propulseurs, la batterie, l’électronique, etc. A partir de là faire de premiers schémas.
Vérifier les dimensions, l'enveloppe énergétique, etc. Faire un budget, aussi...
Il te faudra 6 propulseurs, pour pouvoir utiliser une conduite différentielle sur 3 axes...

Autre chose, il faut trouver des fournisseurs pour certaines pièces... Pour ma part j'avais trouvé une boite aux USA qui vend du polycarbonate formé (donc du plastique résistant et transparant), en tube, ou demi sphère... mais c'est cher

Enfin, en tous cas, bonne chance!

Bonjour,
je pense ton projet réalisable, mais à mon avis si tu n'as jamais fait de ROV, il est très ambitieux.

Pour l'instant, je pense que tu ne devrais pas te préocuper de la fibre, car ton plus gros problème
sera de maintenir l'étanchéité et le fonctionnement du robot à de telles profondeurs.

J'ai fait vite fait de petites recherches, la pression augmente d'environ 1 bar par 10m de profondeur.
cela correspond à une pression de 1kg par cm².

Donc à 100m, le sous-marin aurait 10 bars de pression qui s'exercent sur sa coque. C'est considérable!
A titre de comparaison, la pression des pneus d'une voiture n'est que d'environ 2 bars...

Donc à mon sens, la première étape d'un tel projet est de se concentrer sur l'enveloppe du sous-marin.
La forme sphérique est optimale pour résister à une pression omnidirectionnelle. Elle n'est cependant
pas forcément facile à mettre en oeuvre. En revanche, les cylindres sont plus faciles à trouver/fabriquer, et
offrent une bonne résistance. La faiblesse est surtout au niveau des "bouts" du cylindre, qu'il faut
bien renforcer.

A titre d'exemple, le OpenROV a été testé ici :


Le résultat obtenu est que l'enveloppe résiste à 40m max, sans l'électronique, et
d'apres le testeur, 20-25m avec, et bien sur ce n'est pas garanti.
Pour aller à 100m, pour ma part, je miserais sur un cylindre en acier de bonne epaisseur, et pour la caméra, une vitre de bien 2cm,
et de faible dimension.

De toutes façons à 100m, il sera difficile de filmer grand chose, la luminosité devient minime, il faut donc un éclairage costaud!


Second problème : la propulsion.
J'avais fait des recherches là dessus, et il y a deux solutions courantes : soit un moteur dans la partie
sèche, avec un arbre passant par des joints pour atteindre le propulseur (l'hélice), ou bien un moteur
immergé, l'électronique étant scellée dans la partie sèche ou coulée dans de l'époxy.

Au passage, couler l'intégralité de l'électronique dans de l'époxy peut être une solution, avec des
systèmes de recharge des batteries sans fil.

Enfin bref, pour la propulsion, les joints constituent une faiblesse, et doivent être d'autant plus
costauds (et donc chers) qu'on va profond. En revanche, on peut du coup prendre n'importe quel moteur,
sans le modifier.

Les moteurs externes en revanche nécessitent une modification pour protéger les bobines, mais du coup une fois
le dispositif opérationnel, on n'a pas à se poser de questions sur les joints.
Les câbles passent de la partie sèche à l’extérieur par des canaux qu'on scelle complètement à l'époxy ou autre
(un conduit dans lequel on fait passer le câble, puis ou on coule un matériau solide, résistant à l'eau après durcissement).

La partie contrôle ne devrait pas être trop problématique, avec assez de moteurs et un accéléromètre/gyro/boussole,
il devrait être assez facile de naviguer/maintenir sa position.

l'important est de bien gérer la flottabilité de l'engin, qui devrait idéalement être très légèrement positive (ainsi, en
cas de panne, il remonte! la contrepartie, c'est qu'il dépense de l'énergie pour descendre), et d'avoir assez de propulseurs
pour pouvoir orienter le sous marin selon les 3 axes (tangage, roulis, assiette - bien que ça doit avoir un autre nom
pour les sous-marins-).

Bref, le système de commande ne devrait pas poser de gros problèmes ^^

Pour ce qui est de la fibre optique, c'est en effet une bonne idée. Toutefois,
il est totalement possible de faire passer des signaux électriques sur
des longueurs importantes, rappelez vous que l'ADSL passe par une paire
torsadée de fils de cuivre, et on a facilement plusieurs MB/s jusqu'à 4km
du DSLAM; en ethernet, on peut avoir en 1000 base T du 1000MB/s, soit 125 mio/s
max sur 100m max, selon la norme.

Bien sur, en fibre, on peut aller plus loin et/ou plus vite. Mais la fibre est plus fragile,
et plus complexe à utiliser. Il faudra de toutes façons la protéger, avec une gaine importante.

Dans tous les cas, ce câble de 100m (au moins) est un élément TRES important à prendre en compte :
la résistance hydrodynamique générée par le câble sera conséquente...
Du coup, quitte à avoir du câble vers la surface, autant faire passer aussi l'alimentation électrique,
et en profiter pour mettre de gros moteurs bien puissants!

Un élément à prendre en compte également est celui du refroidissement. Dans un environnement scéllé,
les composants ne peuvent évacuer leur chaleur vers le milieu ambiant facilement. Il faut donc
soit envisager le watercooling des composants internes (ça tombe bien, on est sous l'eau),
ou bien exploiter la coque pour générer des échanges thermiques. SI la coque est métallique, on peut
fixer dessus les éléments les plus générateurs de chaleur...

Dans tous les cas, il vaut mieux faire des tests avant, pour voir la capacité de dissipation thermique, et
avoir une marge...

En bref, à mon avis, l’approche la plus sage serait d'y aller petit à petit, en testant diverses solutions,
avant de pouvoir faire des plongées de plus en plus profondes au fur et à mesure des prototypes
C'est un gros projet selon moi, il faut bien envisager plusieurs mois voir quelques années pour atteindre
les 100m de façon fiable, ou au moins plusieurs semaines voir mois à si tu es à plein temps!

En tous cas bon courage sur ce projet, c'est à mes yeux quelquechose de très intéressant à étudier;
j'espère avoir un de ces jours le temps de me lancer dans la réalisation concrete d'un sous-marin
(pour l'instant je n'ai pas dépassé le stade des études théoriques et de la bibliographie ^^)

Merci sky99 pour toutes ces infos très riches. Comme je continue à rechercher et à regarder j'en était arrivé un peu à ta conclusion , à savoir commencer simple pour tester . Donc mon idée serait de revenir à un petit robot sou-marin , autonome qui se déplacerait comme les petites voitures sans itinéraire précis. Il descend , touche le fond, remonte de quelques cm se balade d'une façon aléatoire, remonte et émet un signal en surface (genre led qui clignote ou fumigène ou un drapeau qui se déploierait comme un périscope). Le tout dans un premier temps à - 10 ou 20 mètres sur 10 minutes par exemple. Pour ce qui est de l'étanchéité, je pensais à une bouteille sous pression qui "gonflerait" le sous-marin au fur et à mesure de sa descente pour équilibrer la pression que l'on peut imaginer légèrement positive par rapport au milieu ambiant. En remontée l'opération se fait en sens inverse et lâche la pression interne via une petite valve de surpression. La flottaison n'est pas affectée car le volume reste constant. Un petite caméra tourne en continu du début jusqu'à la fin. Pour ce qui est des transmission aux hélices dans un premier temps faire avec des tubes d’étambot, mais après j'avais envie de regarder de plus prés le principe de 2 aimants séparés par un cloison étanche. C'est ce qui se fait couramment dans les pompes des aquariums.
Voila quelque idées jetés pelle-mêle , qu'en pensez vous ? Merci d'avance, et moi j'avance justement. />/>/>

Les tubes d'etambot sont une solution "officielle", à savoir un standard.
Maintenant, le problème c'est de s'en procurer à prix correct!
J'ai trouvé des pièces de bateau télécommandé sur hobbyking (au moins les hélices propulsives), mais pas forcément tout.

La solution de la bouteille sous pression est ingénieuse, cependant, il faudra du coup un moyen de gérer la pression, donc un manomètre,
puis une sonde de pression interne et une sonde externe (ou un profondimètre en fait, puisque pression =f(profondeur) ^^

Le couplage magnétique est une solution intéressante, j'en étais parvenu aux mêmes conclusions, et en plus je pense que ce n'est
pas si dur à faire, en revanche avec un rendement plus faible à cause des pertes, j'imagine. Mais ça permet de garder le moteur
en partie sèche simplement />

Au passage, j'ai fait plein de remarques, mais ça dépend en fait du budget />
Pour ma part, je souhaitais tenir un coût de l'engin faible (moins de 200€, mais il
n'était pas destiné à de telles profondeurs />), mais du coup si tu pars sur
un gros budget, il "suffit" de trouver les bons composants />

au passage, une discussion intéressante sur les openrov : http://openrov.com/forum/topics/crush-depth-of-tubing
Une solution proposée est de baigner l’intérieur du sous-marin dans une huile non conductrice.
A moins d'un changement de phase, celle ci est à priori incompressible et compense donc la pression externe, comme un objet plein en fait

Merci Sky99 pour toutes tes impressions. Elles posent les bonnes questions et c'est comme ça que je vais avancer. Question budget, ça peut s’étaler dans le temps et pour l'instant je n'ai encore rien dépensé />/>
La coque : je pensais la faire sur une base d’aluminium. A paris il y a un fournisseur de matériaux et je je pense que si je le fais en 5 mm d’épaisseur renforcé par des cornières carrés toujours en allu ça devrait être bon . Ne sachant pas souder ce matériaux (compliqué et cher) je pense que je visserai les plaques sur une ossature . L'étanchéité sera faite avec de la résine. Pour les trappes de visite ce sera du silicone.
Les ailerons horizontaux devraient servir à faire "planer" le robot durant la descente. Le but étant de filmer et de se balader tranquille. Je ne sais pas quel doit être le poids au cm2 pour que les ailerons soient assez portants , mais ne créant pas trop de traînée. L’aileron vertical aura 2 fonctions : la première en haut il y a un flotteur qui fera office de quille à l'envers . Elle donnera la stabilité à l'ensemble, mais effectivement va créer elle aussi de la traînée. C'est aussi pour m’affranchir un peu d’électronique qui peut tomber en panne. Son 2 éme rôle est lorsqu'il refera surface de pouvoir le localiser plus facilement (leds clignotantes ou couleur fluo ...) et de le récupérer plus facilement (préhension).
Le couplage magnétique : je te rejoins sur ce point car je pense qu'il va poser plus de pb que d'en résoudre.
La propulsion : Je pensais à un propulseur assez puissant à l'arrière et 2 ou 3 propulseurs d'étraves pour les autres axes .
Il y a la question de la pression compensée soit à base d'huile ou de gaz. Je n'ai pas assez d'informations déjà de savoir si c'est une bonne idée, et ensuite si c'est faisable et comment et avec quoi. Peut être d'autres forumistes auraient des pistes ??
Merci pour tes idées sur les caméras, je vais regarder de ce côté, ce qu'il se trouve.
Pour mon compte je commence à avoir des idées plus précises grâce à tes interventions. Rien n'est encore figé dans le marbre .
Je vous dis à dans une semaine bien cordialement

La pression compensée est une bonne idée, mais si tu as une coque en alu de 5mm, je pense que ça devrait suffire pour 20m, sans soucis. Bien sur, faudra voir les joints!
Pour la propulsion, c'est plus facile avec deux moteurs excentrés par axe, mais du coup plus cher. Le fait d'avoir des paires de moteurs permet également une symétrie de l'ensemble, donc plus facile à gérer
en terme d'hydrodynamisme (si les forces sont symétriques, on a moins de dérive!)
Avec un seul moteur par axe, on aura de plus la possibilité de monter/descendre selon l'axe, si le moteur est centré, ou de tourner s'il est excentré, alors que la paire de moteurs permet les deux

Pour les joints des trappes, je pense que tu devrais chercher des vrais joints en O à écrasement. Il faudra une surface plane, dans laquelle on grave un sillon qui fait le tour
de l'ouverture, et le "bouchon" possède parfois un sillon similaire.
Le bouchon se visse sur la plaque, à l’extérieur du joint. Certes il est possible de mettre soi même du silicone, mais comment s'assurer d'avoir une épaisseur constante?

Sinon, je ne sais pas si je l'ai déja dit, mais une bonne solution, c'est les tubes PVC pour canalisation haute pression.
On en trouve de tout plein de diamètres , et en cherchant vite fait j'ai vu des modèles 10,16 et 25 bars. Donc c'est extrêmement costaud, et ça se travaille facilement.
L'avantage, c'est qu'il y a des bouchons dévissables pour ce genre de trucs, avec un joint intégré. ça se perce bien, et ça se colle aussi bien.
Le collage du PVC est en fait une sorte de soudure : la colle dissout une partie du matériau, et en séchant ça soude les deux tubes, de sorte que c'est aussi solide qu'une section normale.

Vu qu'il existe tout plein de raccords standard, ça permet de faire une sorte de meccano géant...