Si tu t'intéresses au mini-robots, tu devrais jeter un œil du côté des Kilobots. J'en ai eu en main et c'est vraiment, mais alors vraiment, petit et léger.
Bonne continuation pour la suite.

Effectivement, c'est vraiment très intéressant comme système! Sans compter qu'ils annoncent 3h d'autonomie, c'est excellent! Et pour ce genre de petits robots, je pense qu'on doit pouvoir utiliser un système basique de charge par induction...
Seulement, je m'attendais à un produit nettement moins cher, j'ai trouvé un pack de 10 a plus de 1200€ en france, et il manque encore la base de programmation à 200€!

J'ai du mal à croire que l'ensemble des éléments intégrés vaut réellement 120€ pièce...
Mais dans tous les cas, ça me pousse à penser que je devrais m’intéresser à ce système de locomotion utilisant des pattes vibrantes... Par contre c'est chouette, car l'ensemble est open source, donc on peut récuperer des idées/codes/etc!

Merci du lien

Salut!

Je reviens un peu sur ce projet, et j'ai l'intention de refaire la conception du châssis, pour permettre d'en réaliser un à l'imprimante 3D, de sorte qu'il soit adapté au maximum, ajustable (conception paramétrique), et pourquoi pas en ajoutant une coque permettant de rendre l'ensemble résistant à la pluie.

 

Une autre piste serait d'ajouter des communications sans fil, en utilisant par exemple un module ESP8266 afin de permettre d'échanger des données. Ainsi, on pourrait ajouter quelques capteurs, en transformer ce robot sans but ni utilité en station de mesure mobile.

 

On pourra alors avancer davantage dans les techniques d'optimisation avec un cas plus concret que le précédent.

En attendant, j'ai posté une galerie avec toutes les images du précédent prototype, qui permettent de reproduire l'expérience.

Hello,

 

Okay, une plateforme de tests divers et variés en fait

 

Sinon pour la chauffe je viens de penser à quelque chose, je ne sais pas si c'est utilisable mais ça m'a occupé l'esprit un moment. On pourrait imaginer une structure en deux parties.

Je m'explique, la 1ère servirait à contenir l'électronique et tous les composants. Ce serait le bloc étanche à maintenir à une température acceptable.

La 2ème serait une coque qui envelopperait la 1ère avec un espace entre les 2. Ainsi la coque absorbe le rayonnement direct et évite au boitier de surchauffer.

Peut-être qu'en développant une forme particulière on arrive à améliorer le flux d'air entre les deux et le mettre à profit?

L'avantage que j'y vois est que sur la partie extérieure on peut sans autre y placer le panneau solaire puisqu’à cet endroit l’absorption thermique n'est pas un problème.

 

Pour les joints d’étanchéité je partirais sur des O-Rings, dont les valeurs standards sont très variées, et que, s'il te faut une longueur spécifique, tu trouves également en rouleau. Il suffit alors de couper la bonne longueur et de le ra-pondre avec une colle adaptée.

 

Si besoin je peux t'imager ce à quoi je pense

 

~Taupiot_Jr

Si je comprends bien, tu parlerais de faire carrément une séparation par une couche d'air?

du genre :

-------------------(paneau)

-------------------(plaque)

                        (air)

-------------------(plaque)

-------------------(electronique)

 

C'est une bonne idée en effet!

Car du coup, par rapport à mon idée de structure en nid d'abeille, on utilise surtout de l'air,

donc réduction du poids...

 

Pour revenir sur l'étancheité , attention a la cappilarité et a l'humidité en interne de ton robot , si les joints sont insuffisants , de l'humidité envahira le coeur de ton engin et je crains qu'il ne survive pas a cela

 

Autre chose , chez toi , il y a du vent ?! Si oui ,  tu va devoir lui trouver un endroit abriter car un vol du haut du toit risque de lui être fatal ! Je vis dans le sud de la France et les journées a 100-120 km/h de vent ne sont pas rares

L'humidité interne devrait être celle de l'endroit ou a été assemblé le robot au départ, sauf ouverture béante je pense!

Pour le vent, en effet il peut y avoir des cyclones, mais bon, dans ce cas je virerai le robot

 

Apres le risque de chute est faible je pense. En effet, le robot serait très plat , bien plus large que haut. De plus j'ai une zone de toit en béton bordée par un petit muret  de 15cm. Autour de cette zone il y a du toit en tôle, du coup, il peut difficilement passer le muret, et dans ce cas, il reste une grande surface de toit!

 

Mais bon au pire c'est pour l'instant un robot pas cher (20-30€), donc si il lui arrive quelquechose en mission, c'est pas trop grave, on aura appris quelque chose

 

 

Et du coup vous me faites penser à deux choses :

Comme charge utile, le robot pourrait emporter :

1. une/des sondes précises de température (DS18B20), peut être a divers endroits (interne, externe, batterie, panneau solaire);
2. un ou deux DHT22 pour mesurer l'hygrométrie (interne, et si on en met un second, externe);
3. un capteur d'ensoleillement;
4. ce n'est pas un capteur mais on mesurera la tension du panneau solaire et de la batterie;
5. un module RTC pour avoir une idée de l'heure, et du coup savoir quand on été faites les mesures.

Avec tout ça nous pourrions avoir des statistiques sur l'environnement de la mission.

Du coup il faudrait soit intégrer le esp8266 (solution préférée, à mon avis), soit intégrer un lecteur SD pour sauvegarder les données.

Dans le second cas, c'est le plus simple, et peut être moins consommateur en énergie.

Dans le second cas, ça nous permet davantage d'interactions avec le robot, et d'avoir les données en temps réel.

Du coup il serait possible de mettre en place une mini page web, une base de donnée SQL avec les données, et de faire des graphes

(je dispose pour cela de ressources web disponibles, avec un .com, 100go d'espace et plusieurs bases sql).

 

Qu'en pensez vous? vous voyez des capteurs à intégrer? il faut qu'ils soient compacts, et pas trop consommateurs (à moins

qu'on décide de couper leur alimentation quand on ne s'en sert pas, et de limiter les mesures?)

 

 

Le second point auquel je pense, c'est qu'il serait possible de faire des prototypes non mobiles (juste un arduino nano , une petite batterie et un petit panneau, avec les capteurs nécessaires)

pour tester certains concepts. Par exemple, l'isolation thermique par telle ou telle méthode, l'isolation contre l'humidité, etc...

 

On peut même tester l'étanchéité avec un proto vide, et rempli de riz ou semoule par exemple, si le tout est sec c'est que l'eau ne rentre pas, et la on peut faire le test de la douche par exemple.

Salut!

En fait ce robot n'a pas d'utilité précise, autre que de faire un robot longue durée.

On peut dire qu'il s'agit d'une expérimentation à faire rentrer dans le projet REA.

Après, j'ai besoin de travailler sur les esp8266, donc du coup je pourrais en intégrer un, quelques capteurs,

et faire une station de mesure mobile sur le toit. Cependant, je ne sais pas trop bien ce que ça apporterait par

rapport à une station mobile, mais d'un autre côté, ça serait un peu comme un rover martien, laché sur une planète,

en milieu hostile, qui doit "faire des trucs" et se débrouiller.

L'idée serait de le mettre sur le toit longtemps (une semaine, un mois, voire plus) pour voir s'il tient bien, l'évolution de

la batterie dans le temps, etc...

 

Concernant la chauffe interne, je ne m’inquiète pas trop, un ATmega, quelques composants du genre, ça ne chauffe pas réellement.

Même le motor driver, vu les faibles courants, ne chauffera pas des masses.

En revanche, la batterie, plus elle chauffe, plus elle s'use vite. Donc l'idée c'est de pouvoir maintenir une température intérieure faible,

enfin protéger du puissant rayonnement solaire.

Je dis bien puissant, car ici le soleil tape fort!

Du coup pourquoi pas le radiateur, mais il faut aussi qu'il soit sous le robot, car sinon le soleil le chauffera!

Je pense que je vais surtout m'orienter vers une bonne isolation. Encore une fois l'imprimante 3D peut être la solution :

quand j'imprime un matériau, je peux définir un remplissage partiellement creux, généralement en nid d'abeilles.

Donc je peux faire plusieurs couches  de plaques avec intérieur en nid d'abeilles, et ainsi on a un bon isolant thermique

L'important sera de séparer le panneau solaire du reste de la structure, car c'est lui qui absorbera la majorité des radiations solaires.

 

 

 

Pour le joint, en effet, je vais m'orienter vers un joint non collé. Donc un anneau en caoutchouc, mais peut être du silicone également.

En effet, si je mets une fine bande de silicone sur mon "couvercle", en face d'une zone plane, et que je ne mets pas en contact les deux pieces,

le silicone séchera, et formera un boudin élastique collé sur l'une des pièces. Après, je ferme, et je visse, ça me fera un joint à écrasement.

 

Mais bon, une forme adaptée peut peut être suffire à protéger de la pluie.

 

Pour l'algo pour aller à l'ombre, l'idée serait de le mettre à un endroit sans ombre. Donc on doit vaincre les problèmes de chaleur autrement.

Deja notre conso minimale entraine un faible rayonnement thermique, ensuite la bonne isolation, et si la batterie chauffe trop, on cessera de la recharger

le temps qu'elle refroidisse, ou éventuellement on la chargera à un taux plus bas.

 

Si l'ensemble chauffe trop même sans charge de la batterie, on considérera que c'est un échec de conception, et on repassera à la planche à dessins ^^

 

 

Voici la base du châssis pour le moment :

 

Il s'agit d'une base paramétrique (on définit les dimensions, et les élements se placent en fonction).

On peut définir l'épaisseur des parrois, les dimensions internes utiles, et ne nombre de barres de renforcement selon les axes X et Y,

ainsi que la taille de celles ci. Je n'ai pas encore mis les trous latéraux pour les axes de moteurs. Ici il s'agit d'une version utilisant la petite

chenille pololu (22T) qui fait moins de 10cm de long. Cela nous donnera une meilleure mobilité qu'avec une roue omnidirectionnelle, au détriment d'un poids supérieur.

 

Mais quand j'aurai fini je mettrai les schémas pour les deux : roulette + 2 roues motrices ou alors chenilles.

De toutes façons l'ensemble sera disponible sur un github, avec les sources openscad pour les modifier et adapter, et les

stl à imprimer, les dxf à découper, selon le choix effectué.

 

Après il manque encore plein de choses (couvercle, trous de vis, rainure du joint, etc etc). Pour l'instant j'ai utilisé ce système pour faire une boite à batterie pour un autre projet solaire, et ça fonctionne. J'ai pu tester des méthodes d'assemblage, mais pas encore le waterproofing.

 

Mais j'ai appris quelquechose : je ne peux pas faire des parois de 0.4mm, car mon slicer ne génère pas ces éléments lors de la génération des commandes de l'imprimante 3D. Je pense que l'imprimante peut imprimer plus fin (normalement la résolution est de 0.1mm), mais le logiciel ne le permet pas.

 J'ai donc du monter jusqu'à 0.6 ou 0.7. Les parois son toujours souples (d'ou les renforts), mais l'ensemble reste léger.

 

 

En fait, c'est un projet qui était en pause, mais comme ça intéresse des gens, ça m'a donné envie de reprendre un peu ^^

 

Bref, je vais faire quelques prototypes, quelques itérations, et je mettrai les avancées à chaque fois

 

 

 

Arduino peut aussi enregistrer facilement un fichier sur une carte mémoire SD.

Oui, mais il faut rajouter un composant coûteux, qui "mange" un certain nombre de GPIO, et dans ce cas un vrai arduino + 

le lecteur ont un coût supérieur à un raspi A+ (20€), sans compter la possibilité de regarder ou en est le test par le réseau, d'envoyer

les résultats par mail, etc...

 

J'imagine que s'il s'agit d'un mémoire de master pour une étude "one shot", ça ne change rien, mais si ça débouche sur une

thèse plus tard, ça vaut le coup d'envisager un système plus sophistiqué avec un raspi

Bonjour,

je me permets une petite remarque, mais il ne faut pas oublier le Raspberry Pi...

Avec un Raspi ça permet d'enregistrer les résultats dans des fichiers! (consultables

par le réseau). Avec la puissance de Unix on peut ainsi planifier les tests, leur durée,

compiler les données, générer un rapport, etc.

 

Mais bon, il est vrai qu'avec un Arduino + moniteur série, on peut également faire un script

qui récupère automatiquement les données par l'USB.

 

Coûteux genre 1€ ? ^^  http://www.ebay.fr/itm/Micro-SD-Storage-Board-Mciro-SD-TF-Card-Memory-Sh-IEld-Module-SPI-For-Arduino-IE-/281807990130?hash=item419d10ad72:g:J7gAAOSw9r1WAqxM

 

Un certain nombre de GPIO ? Genre 4 ^^: Les pin du spi : Miso, Mosi, Slave select, et SCK =) 

Pour le reste je suis d'accord ^^ Mais bon faut aussi voir combien de temps ça prend à mettre en place un système plus sophistiqué

Si on achète en chine, tout est moins cher ^^

En france c'est déja 10-15€ la breakout board.

Pour les GPIO, bah oui, 4 c'est pas mal à mon sens, mais bon j'ai pris l'habitude d'économiser les GPIO avec l'I2C, surtout que les GPIO restent dispos pour d'autres trucs alors qu'en SPI il faut à chaque fois ajouter un slave select pour chaque périhpérique!

Mais bon c'est vrai qu'avec Aliexpress et les sites chinois, c'est tellement pas cher qu'à la limite on prend un arduino mega et un lecteur SD pour 10€

 

Et le Raspberry Pi A+, n'a pas de port réseau, il faudrait donc ajouter un composant ...

Un dongle wifi USB a 5€, c'est négligeable ^^ Avec un Arduino, le seul truc pas cher c'est plus ou moins l'ESP8266!

 

 

Par contre je vous concède qu'étant un gros fan du Pi, je suis peut être un peu biaisé à vouloir en mettre partout ^^

Tu es fan du Pi, étrange, ici, je voyais plus les membres êtres fans de l'arduino.

Pour être franc, au début les deux m'ont paru envisageables, mais l'arduino a plus de fan ici, et je le découvre, la programmation me parait plus simple : je connais très bien le C/C++ et pas mal d'exemple sur le net...

Et comme toi, mais dans le sens opposé, en ce moment, se suis à fond dans l'arduino : j'apprends .

Apparament, la solution Raspberry Pi n'a pas été présenté aux intéressé, dommage.

Si tu regardes mon tuto sur le robot R.Cerda, tu verra que c'est basé sur du raspi.

Certes le Arduino est plus simple pour beaucoup de choses. En revanche, sur des aspects plus complexes, ou simplement lorsqu'il faut du multitâches, c'est bien plus compliqué sur un arduino. Si par exemple, tu dois lire un capteur qui prend du temps à répondre, et faire autre chose en même temps, sur un arduino, il faudra soit faire classiquement, et ajouter des interrupts, soit s'assurer d'avoir des librairies non bloquantes, sauvegarder le moment ou on a fait la requete, et analyser le timer pour voir si assez de temps s'est écoulé, etc.

Avec plein de traitements parallèles, ça devient vite chiant.

 

Avec le pi, tu lances un thread s'il le faut ou encore deux programmes en parallèle.

 

Et si les tâches deviennent lourdes c'est carrément plus simple sur un pi... par exemple faire de la cartographie en fonction du déplacement du robot, s'il faut stocker tous les points mesurés, on a de quoi sur le pi. Sur le Arduino la mémoire sature vite... Idem pour le réseau : des robots communiquants, c'est facile avec le pi : un dongle wifi par robot, et on utilise TCP/IP, qui est robuste, stable et standard, plutôt que de passer par tel ou tel module... (même s'il y a l'ESP8266 pour le arduino, et la ça change  bien la donne, même si ça reste bien plus compliqué que sur un raspi).

 

Si tu veux faire de la vidéo, avec du traitement d'image : la encore le pi est non seulement considérablement plus puissant, il peut aussi faire tourner opencv pour faire des choses impossibles sur le arduino (reco de formes, de visages, etc) et en plus pour moins cher qu'avec le Arduino et en qualité supérieure. Le module caméra du pi est a 25€, pour du 5mpixels, video full HD 30FPS, et il passe par le GPU du pi, donc ça mange à peine 2% de CPU de faire une capture full HD, alors que pour arduino, des modules vidéo adaptés, en 640*480 coutent souvent 50€ ou plus.

 

Donc bref, pour moi ça dépend, pour mes robots, je combine les deux. Le Arduino se charge des tâches de bas niveau comme piloter les moteurs en PWM, écouter le compte-tours de ceux ci, etc, et le Pi se charge des tâches de haut niveau comme la navigation, les communications, etc...

 

Mais attention hein, je ne dis pas qu'il faut laisser le Arduino au profit du Pi, chacun a ses avantages. Ces temps ci j'ai acheté des vingtaines de clones chinois de Arduinos Nanos, et j'en mets partout (gestion des lumières de la maison, systèmes embarqués, contrôle de mon aquarium, etc...)

Je suis AUSSI un gros fan de Arduino

Salut!
Concernant la conversion 2WD->4WD, en effet, tu envoie la même sortie aux roues de chaque coté (en gros les roues de droites peuvent être vues comme une roue par le robot, et celles de gauche comme la seconde roue).

Si les moteurs sont identiques, à mon sens, ça doit fonctionner.

Le seul souci, c'est que puisque les moteurs sont rarement totalement identiques, on aura une dérive d'un coté ou d'un autre, mais après il est toujours possible d'y apporter des solutions...

pour moi la solution simple est de contrôler précisément la rotation de chaque roue avec le type de capteurs dont je te parle, ou une version qui analyse réellement la rotation de la roue.

A mon sens, tout ça ne posera pas de problème majeur, il y a des solutions, ça pourra se régler.


En revanche le point problématique à mes yeux c'est l'alimentation et les moteurs.

Si ta batterie fait 5V pour 7000mAh, et est une batterie au lithium, elle est prévue pour fournir 1C en sortie en général.
1C revient à dire qu'elle peut sortir en continu son courant de 7000mA, et elle peut le faire pendant 1h.

Généralement, elle n'est pas trop contente de sortir plus que ça.

Le problème, c'est que tu fais ton calcul de charge à vide, avec 4*450mA, ce qui est tout à fait OK.

Maintenant, les moteurs ont une conso max de 6A chacun!

Du coup, si ton robot tape dans un mur, et essaie d'avancer, chaque moteur va essayer de tirer jusqu'à 6A, soit 24A au total.

Donc soit le driver du moteur inclut un limiteur de tension, auquel cas ça va, soit ça n'est pas le cas, et au mieux,
le driver moteur va se mettre en protection surchauffe (et il faudra peut être le réinitialiser), soit il grille,
et peut griller la batterie dans la foulée.

J'imagine bien que tu vas mettre des capteurs pour empêcher au robot de rouler contre un mur.
Mais il y a toujours un cas ou un pied de table, un objet bas, bref un obstacle trop fin ou trop bas n'est pas détecté, et ou on se coince.

Donc à mon sens, il faudra trouver le moyen de limiter le courant max des moteurs (une solution c'est d'envoyer un signal PWM au moteur,
de sorte qu'il aie une conso moyenne max inférieure aux spécifications des composants. Par ex, si le moteur tire au max 6A, mais que chaque contrôleur gère mettons 2A, avec un cycle de 33% sur les moteurs, on ne dépasse pas 2A.)

Seulement, c'est pour limiter le moteur à un tiers de sa puissance, pourquoi prendre celui là?

Mon approche est plutôt de prendre un moteur consommant moins au max, quitte à le faire tourner à plein régime pour aller à fond!
C'est à mon sens moins cher, et si un truc ne va pas, et que l'électronique de contrôle débloque, on a quand même l'assurance que rien ne va griller!

Cas pratique du truc auquel on pense pas : R.Cerda est basé sur un pi. Je lance les commandes à travers ssh, via le wifi. Un jour, le wifi est tombé, et du coup
le script de contrôle ne s'exécutait plus, et le robot est donc resté dans le dernier état ou il était... j'ai du l'arrêter à la main.

J'ai depuis résolu ce problème (maintenant je lance un service sur le pi du robot, qui continue à s'exécuter même si je déconnecte le ssh)
Mais la morale c'est qu'il y a toujours un cas imprévu, qui fait qu'il faut s'attendre à ce qu'une configuration rare arrive, et du coup que l'électronique
puisse la gérer.

Du coup ma question est "pourquoi ces moteurs?"

J'ai lu quelquepart dans le sujet que ton robot fait 2.6Kg. Si je ne m'abuse, chaque moteur à un couple de 4.3Kg.cm, et tu en as 4.
ça fait un couple sacrément énorme!

Si le moteur à un couple de 4.3kg.cm, cela implique qu'une roue de 1cm de rayon pourra tourner alors qu'il y a l'équivalent de 4.3kg force de résistance.
2.86
Puisque les roues font 6cm de rayon, ça revient à un force propulsive de 4.3/6=716 grammes-force par couple roue/moteur. Donc au total 716*4=2.86kg-force.

ça correspond à la masse de ton robot. Cependant, il n'y a pas besoin d'autant de force pour déplacer une telle masse qui roule!

Le robot serait en pratique capable d'avancer même dans le cas ou le frottement engendrerait 2.86kg-force.
Or c'est loin d'être le cas!

SI on se place sur un terrain plat, le poids du robot est compensé par la réaction du support.
Du coup il faut juste vaincre le frottement.

EN terrain incliné, on peut calculer la force nécéssaire, mais je ne me rappelle pas assez bien de mes cours de physique pour ça ^^

EN pratique, si l'adhérence du robot était infinie, le couple disponible indiquerait que sur une pente à 90° (donc en imaginant qu'il reste collé au support, et puisse transmettre sa puissance, et en négligeant les frottements), il serait capable de monter en soulevant ce poids.

Je suppose qu'un physicien me dira que je simplifie, mais l'idée est là.

DU coup, à mon sens, les moteurs sont surdimensionnés.

Un exemple concret, avec des moteurs bien plus petits (micro metal gearmotors je crois ceux ci : http://www.pololu.com/product/2368), et en 2WD, un de mes robots déplace plusieurs kilogrammes.
J'ai pris des boites de conserves, posées " debout" sur le sol (donc plein de frottement), et il arrive a les pousser.
Et quand elles peuvent rouler, ça ne devient presque plus un obstacle.

Si tu prenais par exemple le moteur que je viens de donner en exemple, du coup tu aurais une conso max de 700mA par moteur et un couple de 1.7Kg par nmoteur. Donc environ le tiers. Et le robot roulerait sans problème.
à la même vitesse de rotation, mais avec une version 1.6A max, tu obtiens 3.6kg-cm de couple : http://www.pololu.com/product/996

Dans les deux cas, la vitesse de rotation est plus faible que tes moteurs, mais avec le dernier, le couple est proche.

SInon, celui ci : http://www.pololu.com/product/1101 propose une vitesse de rotation supérieure pour un couple de 2.2Kg-cm, toujours avec maxi 1.6A de conso.

Dans tous les cas, les micrometal gearmotors rentrent dans ton enveloppe énergétique!

Si tu as 4 moteurs consommant 1.6A max, un driver pouvant fournir 1.2A en continu, et 2A en pic, il suffit du coup d'avoir deux drivers (un pour les roues avant, un pour les roues arrières), et commandé par les mêmes entrées (donc 6 GPIO : 2 pour le enable des moteurs -gauche et droite- , et 4 pour le sens de rotation des moteurs)

Pour ma part, j'essaie de rester SOUS la puissance disponible en continu avec mes moteurs. Mais tu peux mettre un petit rad sur la puce, et elle sera capable d'encaisser plus de courant, ou limiter tes moteurs à un cycle de 75% de charge, et tu reste dans les 1.2A.

Au total, ça fait donc 1.2A*4=4.8A, ou sans limitation 1.6*4=6.4A, donc la batterie est toujours en dessous des 1C.

Et en limitant a 1.2A, donc 4.8A max, si on ajoute 1A pour le pi (700mA) et les autres composants (300mA), tu arrives à moins de 5mA de conso continue. SI ta batterie fait 7000mAh, tu as donc plus d'une heure d'autonomie dans des conditions de consommation maximale!

Donc à mon sens en situation normales, plusieurs heures (à la moitié de leur puissance max, les moteurs tireront 600mAh chacun, donc 2.4Ah, du coup plus de 2H d'autonomie en déplacement pour le robot!)

AU passage, je me rends compte que je n'ai pas pris en compte la limitation de l'électronique de ta batterie, puisque tu dis qu'elle a une sortie a 1A (donc pour le pi) et une à 2A...
du coup ça veut dire moins de 2A de conso cible pour tous les moteurs dans ce cas!

Pour ma part, j'aurais privilégié une batterie brute, et un régulateur 5V pour le pi (c'est ce que j'ai fait sur le mien). Ainsi je peux tirer toute la puissance de la batterie (une 6000mAh, donc 6A), et le pi reçoit son 5V régulé. En revanche, ma batterie donne du 3.7V, donc les moteurs tournent moins vite.
Dans ton cas il faudrait une batterie type 2S, avec une sortie de 7.4V.

J'ai conscience que tu ne vas sans doute pas commander chez pololu, mais je donne quand même leurs liens pour la bonne raison qu'ils fabriquent tous ces moteurs, roues, etc, et que tu vas retrouver les mêmes moteurs chez les autres vendeurs. Par exemple le moteur sélectionné vient de chez pololu (en pratique, non, c'est un autre fabricant, il me semblent que ceux la viennent de chez planetary. Mais ça passe par chez pololu, car planetary vend en grosses quantités, pour l'industrie, et du coup pololu les distribue en plus petites quantités pour le domaine du hobby. Maintenant j'imagine que d'autres peuvent se fournir chez le fabricant d'origine, mais il me semble que beaucoup prennent chez pololu. J'en veux pour preuve le fait que beaucoup de ces produits s'appellent "pololu machintruc". D'ailleurs snootlab par exemple, distribue en france des produits pololu!

Au passage, je sais que leurs frais de port sont chers (pour ma dernière commande, des robots pour mes étudiants, en "programmation renforcée), pour 400€ de commande, j'avais 50€ de frais de port.
MAIS, on achète en dollars, donc le prix est bien plus bas en pratique; et de plus même à 1€ pour 1$, les prix sont souvent plus bas.

en résumé, à mon sens, tu devrais bien réfléchir à l'enveloppe énergétique du robot

Salut!
En fait, je ne comprends pas bien le problème de câblage dont tu parles!


Ce schema donne à mon sens tout ce qu'il faut pour câbler les moteur et les GPIO!

La seule chose, c'est que comme tu utilises deux cartes,, alors les mêmes GPIO vont aux deux(
GPIO A et B pour les moteurs avant droit et arriere droit par exemple, et GPIO C et D pour les moteurs avant gauche et arrière gauche).

Le Vmotor provient directement de la batterie, et tu ne connectes SURTOUT PAS l'alimentation 5V du pi au+ de la batterie. (sur ton schéma, c'est ce que je vois, à moins que le rectangle vert au dessus de la batterie soit un convertisseur dc-dc?)

En tous cas, le pi reçoit du +5V régulé, propre.

Sur ton schéma, je ne vois pas à quoi correspondent Vint et Vcp, je ne les vois pas sur la carte?

Quand à AISEN et BISEN, ils sont laissés libres, tu n'as pas besoin de t'en occuper.

Tu n'utilises pas non plus VMM, mais juste Vin et GND pour alimenter le motor driver, car il a un circuit pour gérer son alimentation électrique.

Le câblage est ici en fait très simple, il suffit de suivre le schéma de pololu.

En fait, je comprends ton problème sur le câblage maintenant, tu as regardé la datasheet.
Mais celle ci concerne la puce, et te serait utile si tu partais de la puce seule que tu devais intégrer à ton circuit.
Or, ici, tu utilise une carte intégrant la puce avec un peu d'électronique autour. Donc en pratique, hormis par curiosité, le datasheet de la puce ne t'intéresse pas trop, ce qui te sert, ce sont les spécifications de la carte!

Du coup, VCP, VM, etc, bah tu n'a pas à t'en occuper, puisque l'histoire de condensateurs et consorts, c'est géré par la carte.

L'intérêt de la carte c'est justement qu'elle te débarasse de devoir regarder tous ces petits détails.
Pour toi, tu as l'alimentation avec + et -, tu as la sortie des deux moteurs, et les 4 GPIO. le reste ne te sert pas!

Salut!
C'est un très beau projet que tu as en cours />
Je comprends parfaitement ton choix du 4WD au lieu de 2WD+ roue folle.
Le point sympa, c'est que le code sera exactement le même dans tous les cas, tu vas juste balancer en double!

Sur R.Cerda, il est possible que je passe à une telle configuration dans le futur.

Seulement ça pose quelques problèmes :
Il faut synchroniser les trains de roues. Donc à mon sens il te faut un système capable de mesurer
la rotation de la roue ou du moteur.
Pour ma part j'ai acheté ceci :
http://www.pololu.com/product/2590
http://www.pololu.com/product/2591

Le premier en 5V (pour arduino & co) et le second en 3.3V, adapté pour un pi.

ça permet de voir la rotation de l'axe du moteur, avant la boite de vitesse, donc bien plus précis qu'en sortie.
Par contre il faut prendre un moteur avec un axe arrière en plus de l'axe avant en D.
(ils les vendent sur pololu).
Si tu ne synchronise pas la rotation des roues, de la puissance sera perdue en frottement, et de toutes façons,
c'est utile même sur un 2WD pour pouvoir avoir une trajectoire rectiligne.

Le second problème, c'est que 4 moteurs peuvent consommer plus que 2.
En pratique, ça doit être proche à masse égale du robot, puisque les 4 moteurs auront moins à forcer que les 2.
Mais en cas de blocage des roues, tu aura 4 moteurs qui tireront jusqu'a 360mA si tu prends la version low power,
700mA pour la version normale, et 1600mA pour la version hi-power.

Du coup en low power, ça fait 360*4=1440mA, 700*4=2800mA, et 1600*4=6400mA.

Du coup, avec la batterie que tu as choisie (2000mAh), généralement prévue pour fournir 1C en sortie, tu risque
de la voir griller en cas de blocage, selon la puissance des moteurs. Il faudra donc prévoir soit une batterie plus puissante (j'en avais trouvé
une 6600mAh à 20-25€), soit prévoir un circuit limiteur de courant pour gérer cela.

D'autre part sur la batterie, le pi modèle B consomme à lui seul 700mA. Donc ça peut vite faire partir la batterie />

Pour ma part, j'ai pris un pi modèle A maintenant (j'ai développé sur un modèle B )/>.
J'ai aussi le module caméra, très efficace, on peut le trouver sur RS (http://fr.rs-online.com/web/generalDisplay.html?id=raspberrypi&cm_mmc=Offline-Referral-_-Electronics-_-RaspberryPi-201203-_-World-Selector-Page) ou sur farnell.


Le choix des moteurs est très bon à mon avis, j'en ai plein, ils sont minuscules, très puissants, et on trouve des quantités de roues adaptées, ou des chenilles.
Et on peut changer de configuration en un tour de main.
D'ailleurs pour ton 4WD, un kit de chenilles pourrait être intéréssant!
Par ex :
http://www.pololu.com/product/1416
Moi je prendrais des roues et des chenilles />

Sinon comme driver de moteur, moi j'aime beaucoup celui ci : http://www.pololu.com/product/24
Il est compatible broche à broche avec le L293D, mais peut fournir 1A par canal.
Il en faudrait donc moins qu'avec des L293D.
Par rapport à un L298D c'est aussi plus simple.

En tous cas, beau projet />
Mais vu la taille du robot, a mon avis autant prévoir large />

Regarde aussi les autres moteurs :
http://www.pololu.com/category/51/pololu-metal-gearmotors

Plus gros et plus puissants, mais je pense franchement qu'avec les micro metal ça ira, car certains ont un couple conséquent.

Pour la vitesse, n'oublie pas que tu peux calculer la vitesse linéaire en fonction de la vitesse de rotation du moteur, et de la taille des roues />
J'ai fait un post là dessus je crois dans ce sujet : http://www.robot-maker.com/forum/topic/8801-mini-robot-tres-compact-et-autonomie-tres-importante/page__p__57216__fromsearch__1#entry57216

A bientôt />

Salut />/>/>
Pas de soucis, tu n'as pas besoin de t'excuser, tu es déjà bien sympa de me conseiller! ^^

Oui je me suis rendue compte de ma bourde dans mon dernier post, donc je vais me diriger vers une batterie LiPoly. Surtout que j'aimerais bien, par la suite, après avoir acquis plus de compétences, partir sur un drone ainsi qu'un hexapode. J'ai trouvé un FabLab sur Bruxelles, donc si je me débrouille assez bien, il y a moyen de faire de chouettes choses! (ils ont une imprimante 3D, des CNC, ...) />/>/>

Mes seuls dernières petites hésitations sont de savoir comment brancher tout ça... J'ai peur de faire cramer une partie du matos, et ça me ferait mal de perdre ces sous aussi bêtement ^^'

Pour le contrôleur moteur, je ne comprends pas trop l'intérêt du VINT et VCP. D'ailleurs, il y a de grosses incohérences entre les schémas affiché sur le site de pololu http://www.pololu.com/product/2130 et la datasheet fournie http://www.pololu.com/file/download/drv8833.pdf?file_id=0J534 ... ^^'

Sinon, j'ai aussi un petit doute sur le fait de pouvoir relier l'ensemble des ground entre eux, sur un bornier à vis, lequel serait relié au ground de la Rpi.

Pour le site dont tu parles, il s'agit peut-être de hobbyking?
Il semble avoir des soucis, je n'arrive pasà m'y connecter. Les caractéristiques de la batterie sont : Batterie LiPoly de Turnigy, 5000mAh, 7,4V, 20-30C, 2S, 12,71€
Et le chargeur, pour 2S et 3S, connection USB, 3,46€. Frais de port pour la Belgique, 8,85€.

Salut!
Hobyking est en effet blindé de bonnes batteries, le seul problème, c'est de choisir
La batterie que j'utilise c'est celle ci : http://www.seeedstudio.com/depot/lithium-ion-polymer-battery-pack-6a-p-602.html?cPath=1_3
Mais problème, elle est 1S.

L'avantage de chez hobyking, c'est qu'ils vendent des batteries faites pour cet usage. Celle dont tu parles a des caractéristiques très intéréssantes.
5000mAh, donc 5A pendant 1h a 7.4V, donc normalement ça devrait être bon.
Autre point intéréssant, c'est une 20-30C. Cela signifie qu'elle peut fournir jusqu'à 20 à 30 fois cette puissance de 5A si besoin est, en réduisant proportionellement la charge de la batterie. Les classiques sont 1C, donc si données à 1A, elles fournissent 1A max, au dela, elles surchauffent ou se dégradent.
Ici, c'est une 20C, donc en théorie, elle peut sortir 20*5A=100A. Bien sur à ce rythme elle se videra super vite, et de toutes façons j'éviterais ce régime en continu. Mais au moins tu sais que ta batterie ne grillera pas facilement... Maintenant à 100A faut voir si les fils tiennent aussi ^^

Concernant le câblage, en effet, toutes les masses doivent être reliées, et cela ne pose pas de problème particulier. Pour ce qui est du reste, le courant de la batterie arrive quelque part sur ton contrôleur moteurs(généralement Vmotor)

Le principe général est que tu as des GPIO qui indiquent la vitesse souhaitée en PWM au contrôleur, et d'autres pour le sens de rotation. La puce commandera alors des transistors pour balancer le courant Vmotor vers les moteurs, dans le bon sens. C'est généralement assez simple, il suffit de prendre son temps et bien vérifier les branchements. Mais généralement, il suffit de ne pas faire de court circuit, et de ne PAS CONNECTER les GPIO à la partie à haut courant du circuit.

Je regarde les datasheets que tu as envoyé demain pour voir si je peux te donner un coup de main dessus

Au passage, pour faire tes schémas de câblage, tu peux utiliser fritzing, open source et gratuit, sous windows, linux et mac.
Il est bien parceque tu peux faire les circuits en drag' drop, et tu peux visualiser la tête du bidule et aussi montrer ce que tu as prévu

Merci beaucoup pour ta réponse, très instructive!
C'est un peu long donc je ne vais pas savoir revenir sur certains points, mais j'en ai pris note, et c'est vraiment intéressant d'avoir le raisonnement pour chaque partie (courant pour les moteurs, capacité électronique de la batterie, régulation de tension pour le Rpi, ...).
Effectivement, prendre une batterie de 1A passe encore pour le Rpi, mais 2A pour les quatre moteurs, y'a comme un couac' ...
J'ai donc feuilleté un peu ce qui se faisait comme robot (Let's make robot), et trop peu montrent quel type de batterie ils utilisent. J'ai aussi regardé du coté de ton robot, R. Cerda, et j'ai vu que tu avais utilisé une trappe à piles, solution qui ne m'emballait absolument pas de prime abord. Par la suite, j'ai aussi jeté un coup d'oeil à ton tuto qui était donné en lien (d'ailleurs un grand merci pour ces tutos, c'est par ceux-là que j'ai eu envie de me lancer dans mes différents projets!), et je me suis décidée à approfondir l'idée des trappes à piles.
Soit, ne trouvant pas de batterie brute sur les sites sur lesquels j'allais commander, je pars donc sur une trappe 8xAA, avec des piles AA de 1,2V et 2,2Ah. J'en prendrai 7, pour avoir 8,4V et 15,4Ah. (Les moteurs peuvent aller jusqu'à 9V), si besoin, je peux d'ailleurs toujours diminuer de une pile, soit 7,2V et 13,2Ah. Le Rpi sera alimenté par un S7V7F5, régulateur de tension avec une sortie de 5V et 1A.

Là où ça se corse, et à priori ce devrait être mes dernières hésitations, comment connecter tout ce beau monde? (je parle ici d'un point de vue alimentation en énergie).
Est-ce que je peux simplement utiliser les deux fils de sortie de la trappe (+ et -), les connecter à un domino (bornier à vis), de là, faire sortir six fils, 2 pour la carte régulatrice de tension, et 2 par contrôleur moteur?
J'ai fait un petit schéma, ça aidera peut-être à avoir plus clair...


Comme on peut le voir sur le schéma, je ne comprends pas bien la différence entre VCP et VINT, à priori l'un des deux est l'alimentation logique de la carte (du 5 ou 6V). Mais lequel? Voici la datasheet http://www.pololu.com/file/download/drv8833.pdf?file_id=0J534
Et dernière hésitation, quand on a un seul contrôleur moteur, il n'y a aucun problème au fait de fournir en énergie l'alimentation logique via le Rpi, mais lorqu'on a deux contrôleurs moteurs... Est-ce encore possible? Le Rpi est-il capable de délivrer autant? (Sauf erreur, via son GPIO +5V)

J'ai aussi fait une liste des composants que je vais acheter (qui est enfin descendue en dessous de la barre des 200€, grâce à la trappe à piles et aux moteurs moins puissants />/>/>)



Encore un grand merci />/>/>

Salut!
Désolé du délai, j'ai eu plein d'obligations ^^
Alors un point, la combinaison de batteries NiMH (ou autres, en fait).

Si tu combines X batteries de capables de produire 1Ah pour 1.2V chacune, le résultat dépend de la façon d'associer le tout.
Ainsi, en série, tu obtiens un bloc batteries de X*1.2V, mais une puissance de sortie de 1Ah toujours!
Donc avec 8 piles AA de 2200mAh en série, tu obtiens bien la tension mentionnée, mais pas les 12-15Ah que tu espères!

En revanche, si les batteries sont en parallèle, tu peux augmenter la puissance disponible, mais au détriment de la tension:
8 batteries AA de 2200mAh en parallèle donneront 8*2.2Ah soit plus de 16Ah, mais a 1.2V!

En gros, en parallèle, on augmente le courant disponible (ampères), et en série, la tension disponible (volts).

La puissance disponible reste la même dans tous les cas, puisque P=UI, donc (8*1.2V )*2.2A = (8*2.2A) *1.2V.

Une solution serait de faire une combinaison serie-parallèle. Par exemple, deux packs de 6 batteries AA en série, ces deux packs en parallèle.
ça ferait donc 6*1.2V=7.2V, et 4.4Ah disponibles à cette tension. Le montage est relativement simple, c'est juste un peu chiant de recharger toutes ces batteries, à moins d'avoir un chargeur qui prend plein de piles ou 3 chargeurs de 4 piles AA.

A mon sens, la meilleure solution reste une batterie LiPo de type 2S, comprenant 2 cellules lithium en série, donc une tension de 7.4V, et d'en sélectionner une qui fournisse bien 4-6Ah, pour avoir de la marge.

Je ne retrouve plus l'endroit ou j'avais acheté mes batteries lithium polymère, mais pour environ 20€, j'avais du 6600mAh en 3.7V. Il faudrait trouver la même en 2S, donc 7.4V.

Le gros avantage, c'est que c'est plus léger, les cellules sont équilibrées, ça fournit beaucoup de puissance pour une masse réduite, mais en revanche, c'est plus cher, et plus fragile.

Pour la recharge, gros point positif : il est possible d'utiliser un circuit spécialisé, qui ne coute presque rien (5-20$) qui permet de gérer la charge de la batterie sans surveillance : on branche un jack et le robot se recharge, sans avoir à démonter quoi que ce soit.
C'est ce que j'ai fait pour version 2.0 de R.Cerda.

Les packs de piles sont cool, car économiques, et on peut faire plein de bêtises sans grand risques, alors qu'en lithium il faut faire gaffe.
Mais c'est clairement une technologie inférieure sur de nombreux points!

J'aurais bien aimé le faire plus petit, mais je n'y suis pas parvenu.
Pour les moteurs, en théorie tu dois avoir raison, mais dans la pratique cela fonctionne bien. D'autant que ces moteurs ont un réducteur de vitesse incorporé.
Il doit y avoir un phénomène d'auto compensation. Quand on couple deux moteurs dont un seul est alimenté, l'autre tourne également. J'ai fait une vidéo sur ce sujet, ' https://youtu.be/X4BDD0Big5c '
Pour la rigidité, c'est un problème, mais une certaine souplesse n'est pas un inconvénient. Disons que j'essaye de m'en convaincre.
Mais de toute façon, rigidifier l'ensemble serait trop lourd.

Effectivement, si ça ploie un peu, ça permet sans doute une forme d'amortissement, et du coup de mieux adhérer au terrain!

Je vois l'idée pour les moteurs, merci pour les infos

Dans la pratique,, mes chenilles étant très longues et l'élasticité aidant, la différence de vitesse des moteurs n'a jamais été un problème.
Mais, c'est vrai que je n'ai jamais fait de tests de longue durée.

L'idéal serait de faire un banc de mesure pour tirer tout cela au clair.

A mon avis si le couple moteur est négligeable par rapport à la solidité des chenilles ça ne devrait pas poser problème!

Sur le pourquoi, on peut trouver une explication : le moteur c'est des aimants fixes, et des bobines de fil cuivré enroulées (électro-aimant).

L'électro aimant est fait en faisant des tours de fil de cuivre, et c'est fait par une machine. Mais même la machine n'est pas parfaite, et il

peut y avoir de petites variations, donc un champ électro-magnétique légèrement plus fort d'une bobine à l'autre.

fatalement, ça implique un couple qui varie légèrement.

 

Deuxième point : les aimants sont fabriqués avec une certaine précision. Du coup ils changent aussi, la force du champ magnétique varie légèrement.

Parfois simplement la forme des lignes de champ magnétique, et donc les forces exercées.

 

De même, l'alignement des éléments peut jouer.

Bref, plein de choses peuvent varier. Je suppose qu'on doit pouvoir avoir des moteurs calibrés pour ça, mais un retour est sans doute plus simple à mettre en oeuvre, pour un ajustement dynamique.

 

Dans la vie des moteurs, les matériaux magnétiques changent également de puissance magnétique (les aimants s'usent), principalement avec la chaleur. Du coup, encore du changement.

 

 

Concernant deux moteurs en parallèle, sur une source de courant : ils prendront chacun ce dont ils ont besoin pour fonctionner. Si le courant disponible est limité, j'ignore ce qu'il se passe. Mais même dans ce cas, l'efficacité des moteurs est variable, donc pour 1A, un moteur peut faire 3000 tours/minute et l'autre 3015.

De même le couple va varier, et donc la vitesse de rotation sous une charge.

 

D’où la nécessite en théorie de synchroniser les moteurs. Maintenant si la différence entre deux moteurs est faible, le moteur le plus rapide sera ralenti par le moteur le plus lent. Le plus rapide consommera plus, car il essaiera de tourner plus vite, et sera freiné par la résistance. Donc le tout tournera à une même vitesse.

Mais selon le couple des moteurs, ça peut générer une tension supplémentaire sur les maillons de la chaîne.

 

Le second cas de figure, c'est quand le moteur 1 tourne quand même plus vite que le 2, et là on peut avoir un glissement, quand la force devient trop important, le plus rapide va sauter un maillon, la chaîne va glisser jusqu’à libérer la tension, etc...

 

C'est pour ces raisons que pour l'instant je n'ai pas fait de robots à plus de 2 roues motrices. Mais effectivement, on perd en efficacité, mais c'est peut être négligeable, et c'est sans doute moi qui suis trop pointilleux! Et du coup si j'avais essayé au lieu d'attendre la solution parfaite, j'aurais la solution, maintenant ^^

Salut!

Il est énorme

A propos des moteurs, c'est une question que je me posais la dernière fois : 

y a t'il un système qui permet de les synchroniser entre eux (je pense à ceux qui

sont sur la même chenille)? car dans mon cas, mes moteurs ont tous une vitesse

légèrement différente, et sans ajustement précis, ça causerait des soucis pour

un robot avec plusieurs moteurs par chenille.

Comment gères tu cela?

 

Sinon, avec des dimensions aussi importantes, n'y a t'il pas des effets de torsion? Je ne connais pas bien

la rigidité des poutres lego à cette échelle!

Ok je vais essayer d'expliquer mieux !

 

Si tu achètes deux moteurs identiques on peut supposer que leurs caractéristiques seront les mêmes mais en pratique ce n'est pas exacte. De part d'infimes différences en terme d'usinage, montage, durée de vie etc on peut voir des disparités : leurs puissances ne seront pas tout à fait les même, l'un sera peut être à 100 W et l'autre à 101 W.

 

Dans ton modèle tes deux moteurs sont couplés mécaniquement par des ensembles rigides et  à priori peu élastiques. Si on raisonne en terme de couple et qu'on considère que tu utilises tes moteurs à leurs couples maximums pendant une certaine durée et du fait de leurs différences tu vas avoir un moteur qui va fournir 160 mN.m par exemple et l'autre 165mN.m. du coup ces 5 mN.m de différence vont agir comme un couple résistif et imposer une différence de couple qui va se traduire par une augmentation de l'effort dans tes chenilles. Ici ce sera de la traction !

 

Je ne suis pas sur à 100% de tout ce que j'avance et je pense que tout ceci est négligeable, mes ordres de grandeurs ne sont pas forcément correct et je ne parle pas d'expérience mais voilà c'est mon idée sur la question !

 

Je pense qu'il vaut mieux tester tout ça

 

Bonjour,

Je confirme tout cela.

j'ai acheté des TAS de moteurs, toujours par paire ou par packs de 2N, avec des spécifications identiques.

Aucun n'est jamais exactement le même que l'autre. En pratique, à moins que ce soit calibré d'usine (et là, c'est très cher),

la vitesse de rotation des moteurs pour une même alimentation est généralement légèrement différente.

 

Tous mes robots à conduite différentielle ont par défaut une déviation d'un coté ou de l'autre, alors même qu'ils sont symétriques.

Sur mes premiers robots, je pouvais attribuer cela à l'imprecision de mes assemblage, mais j'ai refait des robots avec

les pièces coupées à la laser (précision très élevée), ou imprimée à l'imprimante 3D (de l'ordre du 1/10 de mm), et j'ai toujours cet effet.

 

La solution la plus simple pour moi, c'est de faire tourner les moteurs avec un contrôle PWM de la vitesse, et de baisser légèrement la vitesse

du moteur le plus rapide.

 

Mais là encore, c'est un pis-aller, car quand la tension de la batterie variera, le rapport entre les deux risque de changer.

 

La vraie solution à mon sens, c'est d'ajouter un retour sur la rotation des moteurs, et là, on peut ajuster automatiquement la vitesse des deux moteurs.

C'est ce qui est prévu sur mon autre rover à chenilles, R.Hasika.

Salut!

Il est énorme ce robot!

Je comprends le problème d'échelle, mais j'espère que tu n'abandonnes pas le concept général, car

cette  configuration des chenilles est justement très intéressante

D'ailleurs depuis que j'ai vu tes vidéos de parcours sur les marches, je me dis qu'il faudrait organiser une sorte de challenge

 

Bref, en tous cas cette solution semble très efficace pour le franchissement d'obstacles!

. 

Bonsoir,

je me suis intéréssé à ça, également pour faire des commandes de simu de vol ou autre.

Je confirme ce que dit un autre forumeur, c'est plus simple avec un léonardo.

Je peux te conseiller les lonardo pro mini ou pro micro chez les chinois (aliexpress ou autres),

qui sont pas chers (genre 2€/pièce), du coup tu peux en prendre plein pour faire des modules

indépendants. Par exemple, une boite avec plein de boutons pour gérer les freins de stationnement,

les lumières, la radio, etc, un autre pour gérer l'axe du manche, un autre pour la manette des gaz, etc.

ça simplifie la gestion du projet, tu fais un module, tu teste, tu l'installes, et ensuite du passes au suivant,

plutôt que d'avoir 50 000 câbles dans une grosse boite, avec en plus de longs cables pour aller partout ou il faut

mettre des boutons.

Avec le léonardo, tu peux faire de l'émulation clavier facilement (c'est juste du code, pas de flashage de firmware requis),

parfait pour tous les boutons. Tu les mappes sur des touches du clavier, celles qui correspondent aux actions que tu veux.

 

Pour les axes analogiques, là il faut faire de l'émulation joystick, tu peux avoir 8 axes par arduino, et 64 boutons.

Je crois qu'avec le léonardo tu n'as toutefois que 6 entrées analogiques, mais bon 6 axes c'est bien hein...

Et si ça suffit pas tu en rajoutes un second.

 

les simu/jeux gèrent généralement bien d'avoir plusieurs joysticks/claviers...

 

Autre truc au passage : regarde les teensy, ils sont TRES utilisés par les gars qui font des contrôleurs home-made;

y'a plein de code déja disponible, et le teensy est considérablement plus puissant qu'un Arduino classique.

Du coup on peut faire plein de choses avec, sans se fatiguer, car encore une fois y'a des librairies bien développées

et documentées, alors que pour le léonardo, la doc sur les interfaces homme-machine est plus rare et absconse.

 

Pour ce qui est des écrans LCD en revanche, je n'ai pas trouvé de solution évidente. En effet, pour afficher par exemple la vitesse

air d'un avion sur un LCD, il faut extraire l'info du jeu. Or, je ne crois pas que ce soit par défaut dans les normes de joystick, et

généralement ce sont des trucs spécifiques aux constructeurs qui sont supportés ou nom par le jeu.

 

maintenant, je pense que selon le jeu/simu, il doit y avoir moyen de rajouter un plugin pour extraire les données et les envoyer vers un programme

qui a son tour fait du serie-USB pour sortie sur un écran.

 

petite astuce : tu peux aussi utiliser des LED adressables, genre W2812 pour faire des affichage, par exemple une jauge, ou encore des indicateurs on/off, etc.

Pour la manette des gaz par exemple, en prenant une bande de led adressables RGB, tu peux, en fonction de la position du levier, allumer les N premières LED.

Comme elles sont RGB, le premier tiers peut s'allumer en vert, le second en jaune, le troisième en rouge... et là, que le jeu supporte ou pas, comme le arduino connait la position du potentiomètre de la manette des gaz, il peut afficher l'indicateur.

 

Dans mon projet, j'ai commencé à faire les modèles 3D pour le couplage de l'axe du potard à un levier, j'ai imprimé les pièces, et j'avais prévu de rajouter un servomoteur,

pour faire le retour de force, ou encore le mouvement auto de la manette des gaz par l'autopilote.

Mais bon, ce projet à été relégué en fin de liste, car j'en ai d'autres plus urgents ^^.

 

Mais d'ici quelques mois si j'ai avancé je publierai les fichiers 3D/plans découpe laser avec le code sous licence libre bien sur, si ça t'intéresse toujours.

Salut! Je ne connais pas spécifiquement ton tube, mais j'ai un peu l'habitude de ceux ci, car j'ai un ampli à lampes pour ma guitare. Encore une fois peut être que ce que je vais dire n'est pas adapté à tes tubes, mais avec les Lampes audio en tous cas, il y a un temps de chauffe. Les caractéristiques des tubes varient en fonction de leur température, et bien souvent ils doivent chauffer pour atteindre leur caractéristiques optimales. Dans mon cas, mon tube de puissance dans mon ampli (5W) prend facilement quelques secondes à s'allumer... Je viens de retester, et il a pris environ 5s avant de prendre sa belle coloration bleutée...
Et la lampe de préamplification, moins gourmande, ne s'allume pas du tout (visuellement).
En fait si, les deux ont un petit effet lumineux, à la base, deux points orangés. Mais ce n'est pas très significatifs.
Je pense que l'effet que tu cherche, c'est celui plus important qu'on voit sur les lampes de puissance...

A mon avis, tu auras deux problèmes :
-ta lampe de faible puissance peut elle réellement produire un effet lumineux?
-si oui, peux tu réellement la faire "clignotter", sachant qu'il y a une certaine inertie (la mienne prend 5s à s'allumer, 2s à s'eteindre).

Je pense que tu peux peut être tabler sur un effet "fade", comme le programme éponyme dans les exemples Arduino...

Par contre pour ton robot ça me semble chaud comme consommation : 6V a 300mA c'est beaucoup />

Si tu veux mon avis, tu auras plus vite fait de mettre une LED sous la lampe et d'illuminer la lampe via une LED.
En te débrouillant bien, tu dois pouvoir faire en sorte qu'on ne voie pas la LED, et qu'on aie l'impression que c'est la lampe qui s'illumine...

C'est un projet que j'avais en tête depuis un moment, mais je n'ai pas de lampes à sacrifier pour faire l'essai />
(en plus les lampes audio ne doivent pas être touchées avec les doigts : les matières organiques laissées par les doigts altèrent la façon de chauffer du tube, qui n'est plus uniforme, et ça altère le son...)

Au passage, la doc que tu fournis parle d'un courant de 6.3v pour le filament, mais de 125 ou 300V pour le reste...
Et j'aurais tendance à penser que c'est quand cette partie haute tension est active que tu peux avoir les effets lumineux!

Si tu n'y connais rien, ça me semble ambitieux...
Peut-être devrais tu commencer progressivement.
Pour faire de la reconnaissance de visage, il faut faire du traitement d'image, par exemple OpenCV permet de faire de la détection
de visages à partir d'un flux de webcam, on peut sans doute faire de la reconnaissance faciale. Mais à mon sens c'est assez loin
du genre de réalisations que peut faire une personne qui ne sait pas programmer...

Quand au reste, il te faudra également probablement revoir tes attentes à la baisse, car si tu veux faire un robot "comme néo", mais
que tu n'as pas idée des pièces incluses c'est que c'est probablement ton premier projet robotique. Or, pour néo, un robot bipède
de forme anthropomorphe, il faudra pas mal de servomoteurs, un circuit de commande capable de gérer tout ça, sans doute des systèmes
pour gérer l'équilibre (gyroscopes), et un bon gros code capable de gérer tout cela.

Si tu n'as jamais fait de robot, je te conseillerais de commencer par un robot roulant, à évitement d'obstacles, soit
par capteur de contact, soit par détecteurs ultra-sons ou IR.

Quand à la synthèse vocale, ce n'est pas très compliqué sous linux, avec espeak par exemple. Mais encore une fois je pense qu'il
est plus réaliste de commencer par un robot arduino ou quelquechose du genre, avec des moteurs DC à rapport réducteur.

Je déterre un peu ce sujet, qui a reçu une solution, mais je pense que ça mérite une explication plus détaillée

Le L293D est un contrôleur moteur prévu pour fonctionner avec une tension d'entrée d'au moins 4.5V (voir ici pour des explications plus poussées sur le L293D dans ce tuto  en français, ou encore la datasheet, en anglais). 

Une discussion plus poussée à eu lieu sur ce sujet du forum sur la conception générale du robot, et ce billet précisément traite du choix du contrôleur de moteurs, avec une comparaison entre le L293D (le plus basique), le SN754410 (comparable, en plus puissant) et le DRV8835 (bien mieux).

 

Que ce soit avec le L293D et le SN755410, on aura des difficultés avec l'alimentation depuis une batterie lithium ion, dont la tension nominale de 3.7V variera entre 3 et 4.2V, alors même que les moteurs branchés directement sur la batterie tournent parfaitement.

 

le DRV8835 en revanche fonctionnera parfaitement dans ce contexte, tout en permettant de contrôler un courant plus élevé, et en utilisant moins de GPIO.

 

La solution du régulateur de tension est une solution fonctionnelle, certes, mais pas optimale si l'autonomie est importante. Pourquoi? parceque le régulateur (même si celui ci est très efficace selon les données affichées) n'est pas parfait, et gaspille une partie de l'énergie dans la conversion, réduisant d'autant l'autonomie de la batterie. La fiche annonce ici 94% d'efficacité maximale, mais il faut savoir que ce n'est valable que dans une région bien précise de la courbe de courant du composant. Un exemple avec un bon convertisseur step up : 

On peut voir ici que selon la tension d'entrée, l'efficacité maximale sera obtenue pour un courant bien spécifique, dans une plage restreinte. Au mieux, nous obtenons environ 92%, mais on peut facilement perdre 10% d'efficacité à 3.3V ici, et bien plus avec d'autres tensions d'entrée.

 

L'efficacité est primordiale, puisqu'elle impacte directement la durée de fonctionnement du dispositif. Sans la courbe de tension, difficile de dire précisément l'autonomie perdue ici... Au mieux, on perd 6% de l'autonomie effective pour les moteurs, et plus probablement entre 10 et 15% selon leur consommation.

 

Dans ce billet, j'utilise un convertisseur step-up pour alimenter un raspberry pi depuis une batterie lipo, et je présente davantage de détails sur le calcul de l'autonomie effective.

 

 

En résumé :

• Le L293D ne peut pas fonctionner efficacement avec moins de 4.5V comme tension d'entrée;
• le régulateur step up permet de corriger le problème, mais en contrepartie d'une autonomie diminuée;
• un composant comme le DRV8835 permet de commander les moteurs depuis la tension d'une batterie lipo une cellule (3.7v).

 

Au passage : l'efficacité variera également selon la charge des moteurs. Si le moteur ne force pas, il consomme peu, et plus il force, plus il consomme. Du coup on peut se retrouver dans la plage "basse consommation" du moteur, et donc avec une faible efficacité du convertisseur de tension.

 

Deuxième remarque : il peut être bien de rajouter un condensateur autour de l'alimentation de l'électronique de commande, car quand les moteurs tirent du courant soudainement, ça cause une baisse brutale de tension. Une solution serait d'ajouter ce condensateur et pourquoi pas un convertisseur de tension efficace. La consommation faible de l'électronique de commande entraîne une perte faible due au convertisseur.

Dans le cas d'un Arduino, on peut carrément bypasser le régulateur linéaire 5V inéficace et passer par un bon régulateur de type switching

Salut,

 

Le DRV8835 semble bien adapté au lipo 3.7v. Probablement que j'aurai pris ce composant si j'en avais eu vent au début. 

J'y penserai si je refait un petit robot. 

Le résultat : http://www.robot-maker.com/forum/topic/9932-ailgorwebrtc-car-rc-ioio-otg-en-wifi-chatvideo-webrtc/?p=64735

Je confirme, c'est ce que j'utilise pour mes robots maintenant

 

En tous cas good job^^

Hello,

LA prussa I3 MK2 est simplement la meilleure imprimante 3D disponible autour (et même à deux fois plus cher) en ce moment.

C'est une prussa, donc full open source, la doc est exemplaire, la communauté devrait vite grossir, vu qu'à peine sortie, elle est

déjà une favorite partout, d'un peu tout le monde.

Elle est en kit a 700$, et pour ce prix, elle à:

-auto niveau du Z, mais avancé (mesh grid leveling), en gros même avec un lit tordu elle compense;

-grand volume d'impression (25*21*21cm)

-très haute résolution (0.05mm de couche, soit moitié moins que la plupart des autres imprimantes)

-lit chauffant avancé, avec multi-zones, pour une chauffe bien répartie sur toute la surface (peu d'imprimantes ont ça, hormis la big box, je vois pas)

-AUTO CALIBRATION X et Y : même si l'imprimante est mal montée, elle compense pour faire du bien carré (aucune autre imprimante de ma connaissance ne fait ça)

-extrudeuse E3DV6 : juste le top;

-direct drive extrusion;

-une vraie carte RAMBO, un standard

-une vraie imprimante prussa labs, donc composants de qualité;

-qualité d'impression EXTRAORDINAIRE (parmi ce que j'ai vu de mieux, on est pas loin de la SLA en qualité);

-supporte tous les filaments, jusqu'au polycarbonate, en passant par les souples;

-full open source;

-full open hardware;

 

Bref, à mon avis, cette imprimante vendue à 2000€ vaudrait toujours le coup. Or, en kit, elle est à 700...

Si je n'avais pas déjà une printrbot simple qui fonctionne bien j'en aurais acheté une dans l’immédiat.

Mais bon y'a des chances que j'en achète une avant la fin de l'année de toutes façons!

 

Le seul avantage de la rostock est d'être une delta, ce qui imprime une hauteur d'impression importante (37cm, c'est pas mal quand même), mais en contrepartie, elle fait 19*19cm sur X,Y, contre 25*21.

Pour ma part je préfère plus de surface en X,Y que de hauteur sur le Z. Egalement, c'est une delta, donc elle a les défauts des deltas.

La résolution de la prussa I3 MK2 est le double de celle de la rostock, la communauté sera supérieure sans le moindre doute, le lit chauffant est meilleur,

on pourra plus facilement rajouter de la multi-extrusion, elle a les avantages d'une cartésienne, bref, que du bon.

 

SI en plus tu n'as jamais monté d'imprimante, prends la prussa, elle est livrée avec un vrai manuel physique, détaillé avec les photos, et au passage, le prussa dans le nom, c'est le nom de Josef Prussa, un des GRANDS noms de l'imprimante 3D moderne, qui a conçu la I3 classique que tout le monde copie à droite et à gauche.

 

La carte RAMBO a aussi de vrais fusibles, contrairement à d'autres.

 

Sur tout ça, ne me crois pas sur parole : cherches le reviews sur youtube ou ailleurs de la I3 V2, tu verra, tout le monde est ultra enthousiaste, tous les tests sont élogieux.

Par exemple, lui :

 

Il dit simplement que c'est la meilleure imprimante 3D qu'il ait utilisée, alors qu'il en a testé d'autres qui valent 4000€...