Sandro

À part le problème qu'une batterie sera vide avant les autres (qui n'a pas l'air de trop te déranger), un autre problème est que chaque moteur aura une tension de batterie différente, donc tournera a une vitesse différente pour le même PWM. Si tu as un vrai contrôle en vitesse de chaque roue (par exemple avec un encodeur), alors ça ne posera pas trop de problème. Si par contre tu comandes en boucle ouverte, alors ton robot partira sur un coté ou sur l'autre dès qu'une batterie atteindra une tension plus basse que les autres.

Tant que la différence de tension est faible, les 2 roues du même coté devraient continuer à tourner à la même vitesse (celle avec la tension de batterie forçant plus). Si la différence est importante, tu risques d'avoir les 2 roues qui tournent à des vitesses différentes (donc glissent sur le sol), ce qui use rapidement les pneus.


Mettre des batteries non identiques et potentiellement avec des tensions différentes en parallèle est une très mauvaise idée (en gros, tu crées un court circuit entre la batterie la plus chargée et la moins chargée). Si (et seulement si) une des batteries est capable à elle seule de fournir tout le courant nécessaire, alors tu peux les mettre en parallèle via des diodes : tu vas alors décharger la plus chargée jusqu'à ce qu'elle ait la même tension que la seconde plus chargée, puis tu vas tirer du courant sur les 2 jusqu'à ce que la tension baisse au niveau de la 3ième plus chargée, puis tu utilisera 3 batteries, ... NB : dans la vrai vie, le partage est un peu plus complexe, car les batteries ont une résistance interne, donc leur tension "externe" diminue avec le courant : la batterie 2 commencera donc à fournir un peu de courant quand la batterie 1 ne sera pas encore descendu au niveau de charge de la batterie 2 (à cause de la chute de tension due au courant délivré par la batterie 1).
Si tu veux creuser cette piste, préviens moi, et je peux détailler plus.

For the leg motors :
At 3:36, they say (in german) than the robot is equipped with 2 motors (those for jumping) developed by a spin-off company from ETH-Z. They just say they are strong electrical motors without specifying the type.
I suspect (but without proof), that those motors are developed by ANYbotics, which is an ETH-Z spinoff listed among their sponsors, that develops legged robots, including some capable of jumping (and if I remeber well a presentation they gave in 2018, they told us they developped their own motors).

So those are very likely not hoverboard/electric scooters motors, but motors designed specifically for legged robots (and therefore probably quite expensive)

For the wheel motors :
I found no information about their nature

Si les capteurs infra-rouge sont moins gourmand en énergie et moins chère, ils sont effectivement le meilleur choix pour nous. Par contre j'ai pas compris pourquoi il y a des capteur de force/contrainte et potentiomètre linéaire ? Il y a peut-être des problématique qu'on n'a pas remarqué ?

Le capteur de force, c'est si vous voulez peser la pile, plutôt que de mesurer la hauteur à laquelle elle se trouve. Si c'est bien conçu, ça peut être très économique en énergie (selon le type de capteur de pression, c'est juste une résistance qui varie avec la pression, donc la mesure est quasi instantanée et demande très peu de courant). La difficultés est l'intégration mécanique, et la calibration (la précision de ces capteurs de forces est souvent médiocre).

Le potentimètre linéaire est encore une autre solution : tu fixe le corps du potentimètre à la partie fixe, et la "gachette" à la partie mobile : la tension mesurée au point milieu du potentiomètre sera une fonction affine de la position de ta pile. La consommation J électrique est très faible (si tu n'aliments le potentiomètre que pendant la mesure, et que tu choisis un potentiomètre avec une résistance assez élevée), et l'électronique est simplissime : tu alimentes ton potentiomètre avec une tension fixe (3.3V ou 5V) et tu mesures la tension du point milieu avec une entrée analogique de ton micro-controleur. (nb : si tu veux optimiser à fond, alors ça rajoute quelques composants : un mosfet pour couper l'alim, un condensateur entre GND et le point milieu si tu veux pouvoir faire une mesure très rapide avec un potentiomètre avec une grande résistance, ...). Je n'ai aucune idée du prix d'un tel potentiomètre (ça dépendra beaucoup de la course dont tu as besoin, et de la durée de vie souhaitée). Mais ce qui vas autour est très bon marché et facile.

Niveau consommation on a effectivement pensé à un mode veille et que la stratégie serait donc :

Côté programmation on fera en sorte que les modules seront tout le temps en mode veille et que le poste central les réveillera -> communique > remettra en veille 1 par 1 pour éviter les collisions de donnée (même si d'après les profs il reste assez robuste pour gérer ça).

Je te conseillerais plutôt d'avoir la communication à l'initiative des capteurs. Si tu gères bien le mode veille, celui-ci aura un impact négligeable sur la consommation. Il y a donc 2 élements couteux en énergie : gérer la transmission et faire les mesures.

Si c'est l'unité centrale qui dirige :
- le capteur doit être à l'écoute en permanence (ce qui empêchera de mettre l'antenne en veille, et possiblement de mettre le micro-controleur en veille (si l'antenne peut signaler qu'elle a des données, alors on peut passer par un gpio capable d'intéruptions pour réveiller le micro-controleur))
- lors de la réception du message, il faut démarrer le capteur (et attendre qu'il démarre), prendre la mesure, lire la mesure, transmettre la mesure à l'unité centrale (et optionnellement attendre une confirmation)

Si c'est le capteur qui dirige :

- le micro-controleur se réveille à intervals réguliers (toutes les 1 à 5 minutes je dirais)

- il allume le capteur et lit la valeur
- si la valeur n'a pas changée (ou pas suffisamment, le micro-controleur se rendort (on a économisé la transmission)

- si la valeur à changée, on envoi la donnée à l'unité centrale. La probabilité que celle-ci soit occupée est minime: si on envoi 8 bits (bien suffisent comme précision) sur une transmission à 115200 baud (pas très rapide, probablement ce sera plus rapide que ça), alors la transmission dure 69µs. Avec une émission par minute, ça fait une proportion de 1.15 ppm (=0.000115%) d'occupation du temps par capteur. Avec 10 capteurs, 99.999% du temps, personne n'émet. Et si tu rates une mesure, c'est pas très grave.
- en optionnel : l'unité centrale confirme la bonne réception : je te conseilles plutôt d'ajouter quelques bits pour avoir une détection ou correction d'erreur du coté unité centrale
- en optionnel : si tu veux faire de la veille prolongée en dehors des heures de repas, alors tu as 2 options : soit tu mets une RTC dans chaque capteur (consommation d'énergie très faible, tu tiens plusieurs années sur une pile bouton, mais ça rajoute un peu de cout), soit une fois par heure, le capteur envoit un messsage à l'unité centrale pour demander l'heure, et ainsi recaller l'horloge interne du micro-controleur (qui est pas très précise). Pour le coup, on est obligé de faire une communication en aller-retour (donc un peu plus de consommation), mais si en contre partie pendant toute une heure on n'émet rien car c'est pas l'heure des repas, on est gagnant. Nb : la fréquence à laquelle il faut envoyer l'heure dépendra de la vitesse de dérive de l'horloge du micro-controleur. Une astuce peut aussi être que l'unité centrale répond systématiquement l'heure à une valeur du capteur : juste, la plupart du temps, on n'écoute pas la réponse et on coupe l'antenne avant.


Pour te donner quelques ordres de grandeurs sur la consommation dont on parle, sur base du datasheet du nRF24L01+ (nb en lecture rapide, j'ai pas lu tout en détail, et j'ai jamais utilisé ce module) :
- lien vers une datasheet (probablement pas la dernière version) : https://www.sparkfun...cation_v1_0.pdf

- consommation en mode power-down : 900nA
- consommation en mode standby-I : 26µA
- consommation en mode transmission : 7 à 11.3mA (selon la puissance émise)

- consommation en mode réception : 12.6 à 13.5 mA (selon le baudrate)
- changement de mode power down à standby-I : 400µA pendant 1.5ms
- changements de standby-I vers RX ou TX, ou entre RX et TX : 8 à 8.9mA pendant 130µs

Supposons 1 transmission par minute, et calculons la capacité nécessaire par transmission et la capacité nécessaire par an.

Mode power down (900nA) :
par an : 900nA * 24*365= 7.9mAh

Mode standby-I (26µA):
par an (en continue): 26µA * 24*365= 227mAh (environ la capacité d'une pile bouton CR2025)

Mode powerdown (900nA) + réveil 1 fois/minute (nb : on compte juste le passage en mode standby-I, pas le passage en mode transmission ou réception)
- un passage de power-down à standby-I : 400µA pendant 1.5ms (=4*10^-7 h) : capacité = 0.4mA * 4*10^-7 h = 2*10^-7 mAh

- une passage de power-down à standby-I par heure pendant 1h : capactié = 60 * 2*10^-7 mAh = 1.2 * 10^-5 mAh
- une passage de power-down à standby-I par heure pendant 1 an : capactié = 24*365* 1.2 * 10^-5 mAh = 0.1 mAh

- consommation totale hors modes réceptions et émission : 7.9mAh pour le mode power-down + 0.1mAh pour les transistions ) 8mAh


Mode transmission (9mA), et passage d'un mode standby-I ou réception vers transmission : 9mA pendant 130µs:

- transmission de 16 bits @ 250kbaud : 64µs
- changement de mode + transmission = 130+64 = 200µs = 5.5 * 10^-8 heures
- capacité usée pour une transmission : 9mA * (5.5*10^-8 h) = 5*10^-7 mAh (pour envoyer un message)
- capacité usée pour transmettre 1 message par minuté pendant 1h : 5*10^-7 * 60 = 3 * 10^-5 mAh
- capacité usée pour transmettre un message par minute pendant 1an : 0.3 mAh

Mode réception (13mA):
par an (en continue): 13mA * 24*365= 114000mAh= 114Ah (114Ah@3.3V = 31Ah@12V, soit environ la moitié d'une batterie de voiture)

Mode réception (13mA) pendant 870µs + passage en mode réception (depuis standby-I ou transmission) (9mA):
 

- pour simplifier, disons 13mA pendant 1ms (=3*10^-7 heures)
- capacité usée pour une réception : 13mA * (3*10^-7 h) = 4*10^-6 mAh
- capacité usée pour une réception par minute pensant 1h : 2*10^-4 mAh
- capacité usée pour une réception par minute pendant un an : 2mAh


En conclusion, à condition d'avoir le capteur maitre des transmissions, et de passer toujours dans le mode de veille le plus profond possible (power-down) entre tes transmissions, il devrait être possible d'être <10mAh (@3.3V) si tu fais que transmettre, et <15mAh si tu veux attendre des réponses de l'unité centrale. Avec ça, la partie communication seule, peut tenir plus de 10 ans sur une pile bouton!

Reste à vérifier l'énergie nécessaire par les autres composants (micro-controleur, capteur)
 

Bonjour,

J'imagine que tu veux que chaque capteur soit autonome (ie pas de cables entre les différents capteurs, pour éviter d'avoir des fils partout en travers de la pièce).

Je vais faire l'hypothèse que vos profs attendent à ce que vous fassiez le prototype d'un système industrialisable (et pas une simple preuve de concept). Je vais donc essayer de prendre en compte dans les choix qu'il faut (que produit en grand nombre), le système soit pas cher, ait une grande autonomie, et permette le nettoyage.


Pour les capteurs :
- capteur ultrason : consommation électrique importante, et la plupart des modules pas trop cher ne sont pas étanches (quand j'avais cherché il y a quelques années, les moins cher en IP54 étaient autour de 15€ pièce). Donc pas de problème pour un proto, mais probablement pas le bon choix pour une industrialisation (il faut choisir entre pas étanche du tout et cher)

- capteurs infra-rouge : prix bien moindre (le VL53L0X (pas le module, le capteur lui même) est à 2.59$/pièce en quantité 250, je suppose qu'on peut trouver bien moins cher). Il est possible de placer une plaque de protection par dessus (nb : c'est pas forément facile de trouver le bon matériel qui soit transparent dans l'infrarouge, mais c'est faisable). Je penses que ce serait mon premier choix de techno

- capteur de force/contrainte : intégration "facile" dans une structure mécanique, assez fiable mais pas très précis. Ça peut être une solution si vous avez un mécanicien dans l'équipe, mais si toute l'équipe est en GEII, je penses que la partie intégration mécanique vous prendra trop de temps sans grande valeur ajoutée pour vos profs

- potentiomètre linéaire : honnêtement, j'en ai jamais utilisé. Donc difficile de vous faire un retour sur le prix et la fiabiltié dans le temps. Très facile à mettre en oeuvre électriquement, un peu de boulot de méca

À première vue, avec les infos que j'ai, je choisirais le capteur de distance infrarouge

Pour le micro-controleur de chaque capteur :
- en mode industriel, il faudra une solution très basse consommation avec sommeil profond entre les mesures (donc pas de cartes toutes prêtes avec une LED et un convertisseur de tension linéaire)

- dans un premier temps, n'importe quel microcontrôleur habituel peut faire l'affaire à priori (arduino Nano, stm32, ESP32, ...)
 

Si vous voulez faire simple, un Arduino Nano pour le premier proto, et un Atmega328p seul (le micro-controleur qu'il y a dans l'arduino Nano) pour le proto industriel.
Si vous voulez pousser un peu plus loin, n'hésitez pas à partir sur des micro-controleurs plus "professionnels" (STM32 par exemple), mais ce sera plus de boulot.

Pour la communication des micro-controleurs de chaque capteur vers le cerveau central :

je laisse la parole à d'autres, je ne m'y connais pas assez pour vous faire un panorama complet des solutions et de leurs avantages/inconvéniants.
Du wifi peut permettre de connecter chaque capteur individuellement au wifi de l'établissement, donc de se passer d'unité centrale "physique", et d'utiliser un serveur comme unité de centralisation. Par contre la consommation électrique est (trop?) importante
Pour les solutions bluethooth ou infra-rouge, je penses que le capteur en haut à droite risque de poser problème avec le mur.
La plupart des solutions à base d'ondes radios (wifi, modules radios, lora, ...) devraient fonctionner
Via ondes téléphone (2G/3G/4G/5G) : probablement trop cher

À noter que certains micro-controleurs (ou modules contenant un micro-controleur) contiennent déjà certaines solutions de communication sans fil ou des circuits support. Selon les cas, ça peut justifier l'utilisation d'un capteur spécialisé.

À noter aussi que certains modules de communication ont une sortie série directement : si vous trouvez un capteur compatible, il y a peut-être moyen de se passer de micro-controleur (mais il sera plus compliqué de mettre le capteur en veille)

À propos de la consommation d'énergie :

Pour que le système soit pratique, il faut que le la batterie tienne longtemps (je penses qu'en dessous de 6 mois, le système ne sera pas utilisé dans la vrai vie). Je ne sais pas la place que vous avez pour la batterie, mais elle sera probablement limitée. Il faudra donc (sur le proto industriel) réduire au maximum la consommation électrique :
- le capteur ne doit pas prendre des mesures en continue (à part dans le cas d'un capteur de pression, qui consomme presque rien). Une mesure toutes les 1 à 3 minutes devrait suffire. Dans l'idéal, passer en veille encore plus profonde en dehors des heures de repas (soit basé sur l'heure, soit sur l’absence de changement depuis X minutes).
- il faut (sur le proto industriel) à tout pris éviter un module micro-controleur tout fait (arduino nano, ...) qui contient des LEDs allumées en permanence et qui empêchent donc de réduire la consommation. Le mieux est de faire votre propre PCB avec juste le stricte nécessaire. Il faudra également jouer sur les modes de sommeil du micro-controleur, et désactivé les périphériques (ADC, timers, SPI, ... inutilisés)

- selon le capteur et le micro-controleur choisis, soit le micro-controleur peut réveiller le capteur quand il se réveille (selon le capteur, on utilisera un pin enable, ou on coupera/allumera l'alimentation du capteur, ou on envera la commande pour prendre une mesure), ou alors ça peut être l'inverse, et le capteur réveille le micro-controleur quand il a une nouvelle mesure (idéalement seulement en cas de changement non négligeable)
- probablement le plus important : la communication sans fil consomme beaucoup lorsqu'elle est active. Il faut donc envoyer des messages uniquement lorsque c'est indispensable (ie la valeur à changé de manière significative), et finir la communication le plus vite possible (ie messages courts, peu de latence, éventuellement ne même pas demander de confirmation de réception). De même, si possible, on évitera de rester à l'écoute : le mieux est si la communication est uniquement à l’initiative du capteur (voir mono directionnelle)

Unitée "centrale" :

J'ai pas trop d'avis, ça dépendra de tous les autres choix effectués. Elle pourra probablement être reliée au secteur, donc pas trop de contraintes.

Déroulement du projet :

1) Identification des technologies

2) Plan avec des modules "tout prêt"

3) Test "unitaires" des modules (ie métriser chaque élément séparément), d'un point de vue électrique et logiciel

4) Assemblage d'un premier proto à base de modules

5) Programmation du premier proto, pour obtenir un "proof of concept", c'est à dire un démonstrateur que votre idée fonctionne (même si elle n'est pas industrialisée ni optimale)

6) Conception d'un prototype (semi) industriel : pour les capteurs, vous faites votre propre PCB avec le capteur (plutôt qu'un module) et un micro-controleur "nu" (plutôt qu'une arduino). Pour la partie communication, il vous faudra probablement rester sur un module (mais si possible un module qui ce soude sur un PCB), à moins que vous ne voyez la concetion de PCBs en radifréquence en cours (mais cette partie est beaucoup, beaucoup plus dur que le reste du projet).

Avec le point 6, vous pouvez commencer avec autant de modules que vous voulez, sans pour autant que vos profs se plaignent que vous ne faites rien. Si vous n'avez pas assez de temps ou que le projet est plus dur pour vous que prévu, alors avec les points 1 à 5 (et éventuellement un début du 6), vous avez déjà quelque chose à présenter. Si vous allez au bout du 6, alors ça fera un projet très abouti (si vraiment il reste du temps : faites en plus l'enceinte mécanique propre)

N'hésites pas si certains points ne sont pas clair ou qu'il te faut plus d'informations

Si tu veux faire des mouvements lents, il y a une solution très facile pour faire un sol qui mesure les efforts : mettre un pèse personnes un minimum précis ou une balance de cuisine qui fait à la fois sol et pesée

Je te conseilles de regarder d'un peu plus près comment fonctionne un chargeur de batteries au plomb. Si tu y branches une simple alim 12V DC, tu vas :

1) cramer ton alim si la batterie est peu chargée et que ta batterie est vide (très gros courant, il n'y a qu'à regarder la section des câbles d'aide au démarrage des voitures), à moins que ton alim ait une limitation de courant interne

2) chargé à 12V, ta batterie n'est pas pleine, donc tu perds en capacité utile.

Je te conseilles de juste prévoir un connecteur de recharge sur ton robot, et d'y connecter ton chargeur du commerce pour charger ta batterie (il n'est pas indispensable de sortir ta batterie du robot si ton circuit est bien conçu

Merci Sandro pour ton retour

 

pour le potentiomètre, j'avais trouvé cette ref chez RS : https://fr.rs-online...codeurs/2836188

c'est un potentiomètre 5Kohms de "qualitey" Il n'est pas donné, mais le montage serait très simple, car je pourrais l'intégrer directement dans le couvercle au dessus des roulements

Par contre il y a une chose qui n'est pas très clair pour moi, dans la doc il est indiqué :

Recommended wiper current :  1μA max
Max. wiper current in case of malfunction : 10mA

Power rating P : max. 0.5W/40°C

 

Si je comprends bien...

si je l'utilise en diviseur de tension (c'est ce qui me parait le plus simple à interfacer, mais je fais peut-être fausse route)

U²=PxR : la tension maximum applicable serait de 50V, donc là je suis large

Je confirme, en tension, tu es large avec un 5V ou un 3.3V

par contre le courant traversant le balais au niveau de la piste ne doit pas dépasser les 1µA, donc je vais devoir mettre une

résistance en série avec le curseur pour ne pas dépasser cette valeur

Par exemple, si j'ai un montage en 5V, avec mon potard branché d'un coté de la piste sur 0V et de l'autre sur le 5V

alors je devrais avoir une résistance sur le curseur de 5Mohms

Ou en tout cas, choisir une carte d'acquisition du signal qui limite ce courant à 1µA

J'ai bon, ou pas du tout ?

Si tu as une carte avec une résistance d'entrée >5Mohms, alors tu es bon (pour un arduino uno/nano, c'est 100Mohms la majorité du temps, mais j'ai pas l'info pendant la mesure).

Si tu rajoutes une résistance de 5Mohms entre le point central du potentimètre et ta carte de mesure, alors tu va fausser ta mesure dans 2 cas :
A) si la résistance d'entrée de la carte n'est pas significativement suppérieure (au moins x10, idéalement >x100) car tu vas former un diviseur de tension entre les 5Mohms et la résistance interne de ta carte

si le courant de mesure de la carte * 5Mohms est non négligeable (chute de tension dans la résistance). Pour une arduino Uno/Nano, il n'est pas conseillé de dépasser 10kohms de résistance entre ta source de tension et ton pin de mesure.

le point A) est probablement acceptable sur un arduino . Si on prends le pire des cas, ie une résistance d'entrée de seulement 100Mohms, alors ton diviseur de tension multiplie la tension par 100/(5+100)=0.95, soit 5% d'erreur (nb : cette erreur se laisse calibrer)

Pour le point B, tel quel, tu es fichu. Mais il y a une petite astuce : ajouter un condensateur sur l'entrée de ton arduino (entre le pin et GND) : c'est alors le condensateur qui fournira les cours pics de courant, stabilisant ainsi la tension.

La solution propre, c'est de mettre un ampli OP en mode suiveur : si tu choisis bien l modèle, le courant d'entrée est très en dessous de 1µA, et en sortie, la résistance est très faible, ce qui est parfait pour augmenter la précision de la mesure.

 

Pour loger un servo, je ne sais pas ce qui existe, je ne connais que les servos type modélisme qui ne sont clairement pas assez costauds pour faire tourner la roue,

et les servos que l'on trouve sur les CN, et là on est hors gabarit et hors budget

Les vérins électriques que je compte utiliser ont une capacité de charge de 1000N, et avec le bras de levier, le couple à la roue (pour pivoter) sera compris entre 50 et 70 N/m

( entre 500 et 700 kg/cm comme on dit dans le monde du modélisme)

Mais si certains ont d'autres idées, je prends

Tu as quelques servos à fort couple qui sont disponibles (au pif : https://www.amazon.f...6T/ref=sr_1_290: 380kg.cm = 37 N.m ). Après, tu peux aussi juste reprendre l'idée et le faire toi même : un moteur à courant continu avec un encodeur absolut (ou un potentiomètre), et un contrôleur (pont en H + asservissement). Mais à part que c'est moins linéaire, tu peux aboutir à la même chose avec un retour angulaire et un asservissement sur tes vérins.

Ton idée d'aimants sur la roue m'a fait pensé au système ABS sur les voitures : une roue dentée et un capteur inductif
je pense que je pourrais je pourrai faire un truc... (je fonce sur freecad!)

 

Bon, voilà une solution avec un capteur inductif sur la roue

Capture d’écran_2024-10-17_11-47-41.png

 

je n'ai que 22 points par tour, et avec une roue en ø254, on est sur une précision de 36mm/points, mais vu la destination, je pense que ça sera suffisant

et même si pour l'instant je vais me focaliser sur un pilotage par radiocommande, ça ne me demandera pas beaucoup plus de boulot, donc c'est validé

penses qu'il te faut une mesure "en quadrature" (ie 2 capteurs) si tu veux pouvoir déterminer le sens de rotation. L'avantage, c'est que tu double la résolution.

Je me demande s'il ne serait pas possible d'utiliser un fil pilote, un peu comme pour les robots tondeuses, mais au lieu de servir à délimiter une zone,

ça servirait de "chemin", un truc simple à dérouler au sol... si vous avez des idées... (oui, je me sers de Robot-Maker comme un bureau R&D gratuit )

La solution la plus simple serait de tracer une ligne au sol, et de faire un suiveur de ligne.

Sinon, en plus complexe, tu mets des AruCo tags (des espèces de QR-codes) le long du chemin, et tu te positionne par rapport à ceux-ci. Si ta caméra voit 1 AruCo Tag, alors tu as la position du robot par rapport à ce tag. Après, en pratique, si tu veux être fiable, ça demande pas mal d'ajustements
 

Bonsoir,

Un potentiomètre utilisé sur 1/4 de tour pour "coder" l'angle des roues ça serait jouable niveau précision ?

Ou je vais devoir trouver autre chose ?

Tout dépend de la précision que tu veux obtenir (ce serait dommage de gâcher une méca aussi poussée par une mesure trop imprécise de l'orientation des roues).

Je penses qu'avec un bon potentiomètre (pas un truc à 10 centimes sur aliexpress), je penses que ça peut se tenter, à condition de bien calibrer la position (et éventuellement de devoir refaire une calibration de temps à autre).

Quelques points à prendre en compte :

- assure toi que la tension d'alimentation du potentiomètre soit bien propre

- évite de faire passer les câbles d'alimentation et de mesure des potentiomètres trop proches des cables d'alimentation des moteurs. Et torsade les 2 fils d'alim de chaque moteur. Si possible, torsade les 3 fils allant vers le potentiomètre L'idée étant de réduire le bruit parasite capté.

- utilise un potentiomètre avec une résistance relativement faible (1kohm ou moins) pour réduire l'impact du bruit rayonné par les moteurs et leurs cables

- si tu as moyen de mesurer proche des potentiomètres, c'est mieux (si tu as un potentiomètre à sortie numérique, c'est encore mieux)

- assure toi que la durée de vie du potentiomètre soit conséquente (certains ne sont prévus que pour un réglage occasionnel)

Dans tout les cas, teste bien la précision angulaire de ton potentiomètre avant de prévoir de l'utiliser.


Sinon, si tu veux quelque chose de plus précis, je te conseilles soit d'utiliser directement des servos pour la direction, soit d'utiliser un encodeur absolut (ou incrémental avec signal d'indexage) : c'est plus cher, mais tu aura quelque chose de bien plus précis (à voir si tu as besoin ou pas de cette précision)

Mes moteurs n'ont pas de retour de vitesse, et à moins de les démonter et modifier la flasque arrière pour avoir accès à l'axe, je ne vois pas comment faire

(après je compte les piloter tous avec la même consigne PWM, sans tenir compte du rayon de braquage).

Je ne sais pas si c'est problématique pour faire mes premiers essais (j'en suis pas là je sais ), ou si je peux voir ça comme une amélioration future...

Entre les 2 moteurs du même coté, utiliser un PWM commun (sans contrôle de vitesse) ne pose en général pas problème : ils sont mécaniquement asservis via le sol (si en l'air le moteur A à tendance à tourner plus vite, alors il va devoir fournir plus de couple, donc il va ralentir jusqu'à avoir la même vitesse que le moteur B (qui tournera un peu plus vite, vu qu'il aura moins de couple à fournir)). Le seul cas où ça marche mal, c'est si une roue patine / tourne dans le vide : dans ce cas, elle va fortement accélérer. (NB : je parles bien de moteurs identiques : si tu mélanges les modèles, alors ça commence à pousser un peu loin, et un moteur risque de fournir presque toute la puissance).

En revanche, entre la gauche et la droite, si tu as une petite différence (probable), ton robot aura une légère tendance à partir du coté des moteurs moins rapides. Tu devrais pourvoir partiellement compenser en calibrant (ie ajuster un peu les PWM). Si tu commandes le robot avec un joystick 2 axes (et que tu gardes le robot à vue), alors c'est assez facile à compenser au pilotage. Si par contre tu as des commandes découplées (ie un bouton est sensé faire une parfaite ligne droite), alors c'est plus embêtant. De même si tu veux faire des mouvements autonomes.

Pour illustrer, dans mon ancienne boite, on avait conçu un robot sur base de 4 moteurs de fauteuil roulants (dépourvus de retour de vitesse/position). On avait monté des engrenages en impression 3D sur la pièce reliant le moteur à la roue, de manière à faire tourner les encodeurs (donc d'avoir un relativement bon contrôle en vitesse). Avec une grande roue dentée sur l'axe moteur, et une petite sur l'encodeur, on peut même fortement augmenter la résolution.
Suite à un incident, on a du enlever les encodeurs (on a du souder à l'arc les pièces de fixations sur les moteurs, et les roues dentées imprimées en PLA n'auraient jamais tenu la température, et n'étaient pas montables après soudure). Après calibration, le mode joystick et suivit de personne (asservissement par caméra) marchaient sans problème, et sans perte significative de qualité. En revanche, le mode autonome est devenu inutilisable jusqu'à ce qu'on ait le temps de faire une remise en état propre avec des encodeurs.


Donc tant que tu est en mode joystick/télécommande, je penses que tu peux facilement te passer d'encodeurs. Si tu veux de l'autonomie, alors si tu veux enlever les encodeurs, il te faudra une autre source d'information précise et fréquente (avec des encodeurs, tu peux te contenter d'une information intermittente).

Si tu veux rajouter des encodeurs, le plus simple est probablement un engrenage monté sur l'axe (avant) moteur voir sur la jante des roues. Un engrenage en impression 3D suffit, vu que l'effort est très faible, et la précision nécessaire n'est pas énorme.
Une alternative encore moins précise (mais moins cher), serait de coller de petits aimants à intervalles réguliers sur ta jante, et de mettre un capteur magnétique en face
 

Pour le SyRen50 (lien PDF), il est possible de l'acheter via la boutique Robot-Maker ?
ces drivers ne risquent pas d'être un peu justes ? ça me fait toujours bizarre de voir de si petits composants passer autant de puissance (surtout pour celui où il n'y a même pas de radiateur )

Pour moi, c'est plutôt le contraire : quand je vois un "petit" driver avec un gros radiateur, je trouve ça suspect : en général, c'est qu'il contient un pont en H pas du tout efficace.

En général, au delà de 1A, si on cherche l'efficacité, il vaut mieux un driver avec 4 mosfets séparés (comme ceux présentés) qu'un pont en H tout intégré.

Avec de bon mosfets, on arrive a avoir des Rdson aussi bas que 0.5 milli-ohms (ie 0.0005 ohms). À cette valeur là, avec un courant de 13A, ça nous fait une puissance dissipée (pour chacun des 2 mosfets actifs) de P=R*I²=0.0005*13² = 0.0845 W : tu ne sentirais même pas la chaleur en mettant le doigt dessus. (NB : je considère que la fréquence de PWM est assez faible, et le driver assez réactif, pour qu'on puisse ignorer les pertes de commutations).

Après, je doute que les mosfets soient aussi bon (le moins cher serait à 1.26€ pièce en quantité 10k, trop cher pour un produit vendu à 24€ en France).

Mais même avec un mosfet 10 fois moins performant (Rdson = 5milli-ohms), on est encore en dessous de 1W, ce qui me semble réaliste sans dissipateur tant que le PCB est dans un endroit aéré (pour que l'air autour ne chauffe pas trop). Et là, on est
en trouve à partir de 0.2€/pièce en quantité 10k, ce qui me semble raisonnable.


Si quelqu'un arrive à me trouver la référence des 4 mosfets, alors je peux regarder quelle puissances ils doivent dissiper (sur la photo, je n'arrives pas à lire la référence)

Si tu as des oscillations sur un PID, tu peux essayer :
- de diminuer Kp

- de diminuer Ki

- d'augmenter Kd

Après, intrinsèquement, si tu modifie brusquement la consigne, un PID aura tendance à osciller (sauf si tu le règles très peu réactif). En général, si des oscillations (ie dépassements) sont autorisés, alors la meilleure solution consiste en de petites oscillations qui s'atténuent rapidement (si tu oscilles longtemps une fois revenu en ligne droite, alors ton PID est probablement mal réglé).


Si tu dispose de l'information nécessaire, alors une bonne "astuce" est de combiner le PID avec une consigne en boucle ouverte.
Par exemple, pour aller à 1m/s en ligne droite, tu calcules que chaque moteur doit recevoir un PWM de 200.
Donc au lieu de juste demander au PID de "trouver" le PWM correct, tu donne à tes moteurs la consigne 200+PID_gauche et 200+PID_droite , avec PID_gauche/droite le correctif calculé par PID (dans un monde idéal 0, en pratique, de petites valeurs, qui compenseront la différence entre tes 2 moteurs, les frottements, ... bref, tout ce que tu ne sais pas calculer/modéliser).
Si brusquement tu change d'objectif (par exemple tu sais que tu as un virage de rayon R vers la droite), tu calcules que pour le parcourir à 0.8m/s, il te faut envoyer un PWM de 160+30 à gauche, et 160-30 à droite. Tu enverra donc 160+30+PID_gauche au moteur gauche, et 160-30+PID_drotie au moteur droit.

De cette manière, tu peux changer brusquement de consigne sans avoir besoin d'une valeur Kp importante (ce qui entraîne souvent les oscillations), tout en ayant le PID qui te permet de corriger si tu pars un peu trop à gauche ou à droite.


NB : cette approche est "facile" si tu connais ta trajectoire (par exemple par caméra), avec de simples capteurs alignés comme ça semble être ton cas, il faudrait un peu creuser pour savoir comment calculer la courbure du virage.



Pour l'enregistrement en RAM des valeurs des capteurs, il n'y a quasiment aucun risque que ça augment significativement la latence (à priori, lire le capteur devrait être aussi coûteux voir bien plus que de l'enregistrer en RAM), sauf si le code est très mal optimisé. N'hésites pas à poster ton code si tu veux qu'on y jette un coup d'oeil

C'est normal qu'un GPS ne renvoie pas (directement) un cap, vu qu'un récepteur GPS ne donne qu'une position (et l'heure très précise).

La seule manière d’obtenir un cap à partir du GPS, c'est de calculer le déplacement entre 2 instants. Si la distance de déplacement est faible par rapport au bruit de la position, alors le cap est très imprécis (voir complètement faux). Mais il n'y a aucun moyen de savoir à priori sur quelle échelle de temps tu veux avoir ton cap (est-ce que tu préfères un cap précis mais avec beaucoup de délai, ou un cap imprécis avec moins de délai).

La solution "usuelle" est de combiner, via un filtre de Kalman,  les données du GPS avec celles d'un gyroscope (+accéléromètre pour connaître la verticale si tu ne te déplaces pas sur une surface 100% plane). Le gyroscope est très précis pour te dire de combien tu as tourné (sur une courte durée), mais accumule de l'erreur sur le cap au fil du temps. Le GPS, lui, permet facilement et précisément d'avoir le cap moyen sur une longue durée, mais est peu précis sur le court terme. En combinant les 2, tu es très précis et réactif en permanence (sauf parfaitement immobile).

Une autre solution, c'est d'utiliser une carte avec 2 antennes GPS, et de faire du GPS différentiel : il est possible de mesurer très précisément l'écarte de position entre les 2 antennes (beaucoup plus précisément que leur position GPS absolue), ce qui donne une très bonne orientation de l'axe entre les 2 antennes.

À noter que Ardusimple vend les 2 options : https://www.ardusimp...-sensor-fusion/

L'option IMU (gyro) + GPS peut aussi se gérer de ton coté en soft, si tu préfères creuser plus le sujet mais payer un peu moins cher (mais si Ardusimple a bien fait les choses, ils devraient arriver à une meilleur précision à IMU donné, vu qu'ils connaissent exactement les caractéristiques des 2 capteurs).


PS : je gardes aussi un très bon souvenir du support Ardusimple à l'époque où, dans mon ancien boulot, on avait testé leurs produits (on avait fini par laisser tomber le GPS, car on était trop souvent en zone trop densément bâtie, où le GPS RTK ne marchait plus correctement)

Franchement, pas convaincu du tout :
- l’étain qui ne tient pas : c'est qu'il a complètement cramé/oxydé sa pointe. Il faut la nettoyer régulièrement en y mettant de l’étain frai, puis en essuyant l’étain fondu (éponge humide ou les espèces de "fils de métal en vrac" prévu pour les fers à souder (j'ai plus le nom en tête). Et ce que j'ai appris récement chez notre fabriquant de PCB, c'est que le meilleur moyen d'éviter l'oxydation de la pointe, c'est de la couvrir d'étain frai juste avant d’éteindre le fer à souder : la couche d'étain s'oxydera à la place du fer (et on enlèvera l'étain oxydé avant de commencer à souder la fois d'après)

- le papier verre sur la pointe, c'est le meilleur moyen de l'abîmer (à moins que ce ne soit les pointes premier prix en cuivre massif)

- mettre en quasi court-circuit un chargeur USB, c'est un bon moyen de chercher les ennuis (probabilité non négligeable de le détruite (voir qu'il prenne feu) si c'est du no-name premier prix, sinon, s'il est bien fait, il est bien possible qu'il se mette en sécurité (donc ça sert à rien) ou que le fusible lâche). Le seul cas où ça marche, c'est si c'est un chargeur qui passe en mode contrôle de courant (avec la tension qui baisse) quand il atteint son courant max). Il faudrait utiliser une alim de labo (réglée en contrôle de courant), ou à minima une alimentation avec une résistance (de puissance) en série calculée pour limiter le courant à la valeur choisie

- l'électrolyse : je ne suis pas sûr si la présence de l'étain change quelque chose, mais si non (ou si l'étain est entièrement électrolyser), alors c'est l'eau salée qui est électrolysée, et ça produit du Dichlore, un gaz asphyxiant (utilisé pendant la première guerre mondiale). Donc à éviter absolument à faire à l'intérieur.

Bienvenue Robotito!

Un autre spéléo sur le forum, quelle bonne nouvelle!

Pour l'architecture, celle proposée par Mike me semble cohérente.

Une alternative pourrait être d'utiliser du PoE+ (alimentation et signal ethernet 100Mbps sur les mêmes 4 fils (ou un cable ethernet standard)). L'avantage est que tu n'as plus besoin de batterie sur ton crawler (tant que tu n'a pas besoin de plus de 25W). Mais c'est un peu plus complexe. Si tu débutes en programmation, je penses pas que ce soit la solution la plus facile. Si tu es sûr de vouloir utiliser ton robot uniquement pour des entrées (et pas au fond d'une grotte), alors il y a peut-être moyen d'utiliser Vigibot (https://www.robot-ma...sur-vigibotcom/ https://www.robot-ma...taller-vigibot/ ). Dans cette option, au lieu d'utiliser des arduinos, tu utiliserais une raspberry pi (avec un hat PoE+) et une caméra raspberry Pi. Coté extérieur, il te faudra un injecteur PoE+ (avec de quoi l'alimenter), et de quoi y fournir internet (routeur 4g par exemple, ou raspberry pi/ordinateur portable qui transmet l'internet du téléphone portable vers l'ethernet). C'est l'ordi ou le téléphone qui te serviront de manette.

Même si je penses que techniquement cette solution est plus performante que celle de Mike, elle est aussi plus complexe a mettre en oeuvre (surtout si vigibot ne te conviens pas).

Sinon, pour répondre à tes autres questions :

- pour transférer le choix des options de mouvement sur une télécommande classique : tout dépend de la télécommande que tu veux utiliser : à partir du moment où tu as des boutons physiques correspondant (par exemple 2 boutons à bascule), le reste, on peut le faire en logiciel.

- remplacer l'arduino Uno du tutoriel par une arduino Nano (voir une pro mini si tu veux encore plus petit, mais c'est plus pénible de transférer le programme) ne pose aucune problème. Le tuto utilise juste 2 modèles différents pour faciliter la distinction qui est le maître et qui est l’esclave

- pour apprendre à programmer sur arduino, j'ai surtout appris avec des tutos en ligne (il y en a plein), donc j'ai pas de bouquin en particulier à te conseiller.

Enfin, une petite remarque pratique : en spéléo, il n'y a presque rien qui puisse donner l'échelle. Donc quand on voit une simple image, on n'a souvent aucune idée de la taille de ce qu'on voit (et pour ton utilisation, si la galerie fait 30cm ou 2m, ça change tout). Une solution simple est de rajouter un capteur de distance qui pointe vers le centre de l'image : si tu as la distance de ton objet, ça te donne une assez bonne idée des dimensions.

@Oracid : je dirais que tout dépends de ce que tu veux :

- si tu veux utiliser un robot pour une tâche définie, et qu'il existe un robot sur le marché qui l'accomplit, le mieux est probablement de l'acheter

- si ce qui t'intéresse c'est d'utiliser un robot/"jouer" avec, le mieux est probablement de l'acheter

- si ce que tu aimes c'est la programmation, alors ça vaut le coup d'acheter un robot programmable, et de le programmer

- si tu veux effectuer une tâche faisable avec un hardware existant, mais pour lequel il n'existe pas de robot dédié, alors un robot programmable est probablement la meilleur solution

- si tu aimes construire un robot, alors n’achètes pas un robot, mais construit le toi même.

- si tu as une tâche non standard très spécifique, alors il faudra probablement construire un robot sur mesure

- si tu veux apprendre à fabriquer des robots, alors le mieux est de les construire toi même.

Pour ma part, je trouve que l'intéressant, c'est la construction "totale" du robot. Du coup un robot juste programmable (voir pré-programmé), ça ne m'intéresse pas trop.

Mais je penses qu'il y a encore de l'avenir dans la construction de robots, y compris dans le monde pro (dans ma boite, on est une petite 20ène, avec plus de la moitié de l’équipe dédiée à la conception du robot(méca, élec et soft))

Pour la dernière remarque je pense qu’effectivement c’est la que nous ne nous comprenons pas.

Vous avez écrit :

Si tu soulèves 10kg, tes bras fournissent une force F=mg = 10kg * 9.81 N/kg = 98.1N. Et le fait qu'en réaction, tes pieds poussent le sol avec 10kg (98.1N) de plus, ne fait pas "magiquement" que tes bras ne portent plus que 5kg.

Je pense donc que c’est ce schéma : Car le poids ne peut pas (peser) tirer mes bras vers le sol sans une contre-partie de la terre qui l’attire. C’est la loi de la gravitation universelle.

Avant que j’aille plus loin, pouvez-vous me confirmer si j’ai bien compris. Sachant que la réaction sous mes pieds est le poids que je soulève plus mon propre poids.

Oui, on est d'accord, la réaction sous tes pieds, c'est ton poids + le poids que tu soulèves.

Mais je ne vois toujours pas pourquoi tu penses que le Cfcém est divisé par 2 dans ton montage.

Pour moi, si l'alternateur classique tourne à vitesse w, et le tien à vitesse w sur un axe et 2w sur l'autre, alors :

- dans l'alternateur classique, tu aura un couple Cfcém_classique exercé entre le stator et le rotor (ie couple Cfcém_classique exercé sur le stator et sur le rotor).

- dans ton alternateur, tu aura un couple Cfcém_bi_rotor=Cfcém_classique exercé entre les 2 axes. Ce couple s'exercera sur les 2 axes (le plus lent cherchant à accélérer, le plus rapide à freiner).