Sandro

Pour ton collecteur tournant maison : beau travail! Je te conseillerais juste d'ajouter un cache (en impression 3D?) pour éviter les saletés sur le collecteur. Je penses qu'une fois que tu as de la boue dessus, ça ne marchera pas longtemps.


Pour la commande des moteurs, je ne penses pas que le driver 13A soit un bon choix :
- les moteurs indiquent max 13.4A (>13A) max continu : on dépasse le max du driver. Et il n'est même pas clair si les 13.4A de tes moteurs sont le max qu'ils peuvent consommer, ou le max qu'ils peuvent consommer sans crammer
- je ne sais pas pour tes moteurs en particulier, mais dans mon ancienne boite, on utilisait des moteurs pour fauteuil roulant assez similaires, mais avec un frein "de parking" intégré (si le frein n'est pas alimenté, ça bloque l'axe). A 2 reprises, on a eut un problème sur l'alimentation du frein alors que le moteur tournait : à chaque fois, ça nous a cramé le bobinage du moteur. Donc je recommande vivement un driver qui permet de régler le courant max à une valeur au delà de la consommation normale, mais en dessous du courant auquel le moteur risque de cramer. Un disjoncteur ou fusible est possible aussi, mais c'est difficile à dimensionner avec assez de précision, et il faut re-armer/remplacer manuellement. Tu peux aussi utiliser un pont en H sans limite de courant mais avec mesure de courant, et gérer ça en logiciel. Ou même mettre une mesure de courant externe.

Dans mon ancienne boite, on utilisait des controleurs "RoboClaw" ( https://www.basicmic...tor-controller2 ), qui marchaient très bien, mais sont probablement overkill pour toi (leur gros avantage était qu'ils géraient directement les encodeurs et le PID, mais si tu n'utilises pas d'encodeurs, toute cette partie ne te sert à rien). En tout cas, je te conseilles vivement de choisir un système qui te permette de limiter le courant max à une valeur qui ne détruira pas tes moteurs

Je dirais que chatGPT, comme la plupart des autres IA, c'est utile dans 2 cas :
1) tu veux facilement avoir quelque chose qui marche bien en moyenne (et souvent avec peu d'effort pour l'obtenir), mais ce n'est pas grave si parfois c'est complètement à coté
2) tu as un problème "compliqué" à résoudre, mais dont la réponse est facile à vérifier : tu demandes à l'IA de le résoudre, et tu vérifie avec une méthode classique que le résultat est correct.


1)
Le premier cas est typiquement les recommandations de contenu (que ce soit de produits sur Amazon, de la prochaine vidéo sur youtube, ...) : une IA (ie des statistiques un peu poussées) permettent de prédire bien mieux ce qui t'intéresse que si quelqu'un essayait de programmer ça à la main (dans quel cas, il ne pourrait pas traiter autant de cas différents, et devrait se contenter de quelques critères). Mais si une fois sur 10 ou sur 100 l'IA se trempe totalement, et te propose une pub pour des couches alors que tu n'as pas d'enfants, ou une vidéo en chinois alors que tu n'en comprends pas un mot, bah c'est pas un problème.

Pour chat GPT, ce premier cas est (je trouve) relativement peu fréquent, en tout cas, pour l'usage que j'en fais (je ne m'en sert pas pour lui demander de me recommander des films/musiques/recettes,... sinon ça rentrerait dans cette catégorie). Dans cette catégorie, je m'en sert principalement comme "dictionnaire avec contexte", quand je tombe sur un terme (ou un sigle) que je ne connais pas, et que je veux une rapide explication, sans que cette explication ait une grande importance pour moi : j'obtiens rapidement une explication adaptée à mon contexte (et en général chat GPT est assez bon sur ce genre de questions), et si quelques détails sont faux, c'est pas bien grave). En revanche, si comprendre parfaitement le terme est important pour moi, alors je privilégie des sites traditionnels (ou je vérifie les données de chat GPT sur des sites traditionnels)

2) Le second cas est pour moi le plus intéressant pour l'usage de chat GPT : le problème est difficile (ou laborieux) à résoudre pour moi, mais la réponse est facilement vérifiable par des moyens classiques : dans ce cas, il n'y a aucun risque à utiliser une IA (à part perdre un tout petit peu de temps, mais en moyenne on est largement gagnant).
Quelques cas classiques :
- résoudre une équation : une fois que j'ai le résultat, j'injecte la valeur numérique, et c'est facile de voir si c'était correct
- pour de la programmation, demander comment faire quelque chose (de relativement simple) dans un langage de programmation quand on ne connaît pas la/les fonctions adaptées : quand on n'a pas le bon mot clef, c'est difficile de faire une bonne recherche classique, mais une fois que chatgpt nous sort une ou 2 fonctions, c'est simple de vérifier la doc de cette fonction pour vérifier qu'elle fait exactement ce qu'on veut
- suggérer des idées de méthode, de circuit électronique, ... : une fois la suggestion faite, il est très facile si ça marche ou pas. NB : rien ne garanti que ce soit la/les meilleure méthode, mais si elle est satisfaisante, alors pas la peine d'aller chercher plus loin
- résoudre des problèmes avec beaucoup de contraintes qu'on formule facilement en langage naturel et où la vérification est facile. Par exemple, j'ai une liste de résistances en stock, et je veux obtenir un diviseur de tension avec un ratio précis, et une puissance consommée ne dépassant pas un certain seuil. Tester toutes les combinaisons à la main me prendrait plusieurs heures. Tester toutes les combinaisons avec un tableur me prendrait plusieurs dizaines de minutes. Vérifier la solution proposée par chat GPT me prend moins de 2 minutes.
- demander la signification d'un sigle dans un contexte donné : en général, si la réponse est correcte, alors il est évident que ce sigle correspond bien au texte que je suis en train de lire
- suggérer des composants électroniques correspondant à un cahier des charges (surtout quand ce cahier des charges correspond mal aux critères proposés par les vendeurs de composants) : à la main, ça fait énormément de datasheets à éplucher. Chat GPT peut facilement me suggérer quelques composants. Je regarde donc les datasheets de ces composants là en premier. À noter que c'est le type de recherche où j'ai le plus souvent des résultats faux, voir parfois même où chatgpt renvoie des résultats en indiquant lui-même des caractéristiques qui ne collent pas. Mais ça n'aide probablement pas non plus que je fais en général ce genre de recherches pour des composants difficiles à trouver (sinon je trouve les moteurs de recherches de sites comme digikey, mouser, RS, ... plus pratique car plus fiables et plus exhaustifs)


3) Des cas où je ne recommande pas l'usage de chatGPT, et où je ne m'en sert pas :
- la génération d'un code complexe : le grand problème est que le résultat est vraisemblable, mais pas forcément correct : trouver des erreurs est donc particulièrement difficile
- la réponse est importante pour moi, et difficilement vérifiable (par exemple j'ai un problème avec l’embrayage de ma voiture : est-ce que je peux rouler avec jusqu'au garage ou il vaut mieux faire venir la dépanneuse : je préfère appeler mon garagiste que de confier ma vie et celle des autres à une IA!)
- toutes les questions où je sais exactement où trouver ma réponse rapidement autrement : pourquoi prendre le risque d'une réponse erronée si je sais ou trouver une réponse fiable dans la même durée
- des questions particulièrement complexes et des cas atypiques : chatGPT peut donner des pistes, mais des experts humains restent généralement bien plus performants
- des questions impliquant des données confidentielles : pas question de donner à OpenAI l'autorisation de les exploiter!
- l'envoie de mails (et tout particulièrement de mails pour poser des questions) : je considère que c'est un manque de respect envers la personne qui reçoit le mail (et un manque d'efficacité, car la question à en général été altérée et "gonflée"). Si quelqu'un considère que ça question ne vaut pas l'effort d'être rédigée, alors elle ne vaut certainement pas la peine que j'y consacre mon temps pour y répondre (la même chose est vrai sur les posts sur les forums). NB : utiliser une IA pour suggérer des corrections orthographiques ne me pose pas de problème, même si personnellement j'utilise des outils dédiés pour ça et pas une IA généraliste. Dans le cas particulier d'une personne parlant mal une langue, je peux accepter quelques reformulations proposées par l'IA à condition qu'elles soient relues ensuite.


Donc pour moi, chatGPT est un outil qui est bien pratique dans certaines circonstances, mais peu performant dans d'autres. À utiliser quand c'est pas grave si le résultat est faux.



D'ailleurs, j'ai la même approche pour la robotique en général : l'IA me semble une bonne idée pour toutes les taches non critiques où on veut de bon résultats en moyenne (par exemple, si je devais développer un robot pour récolter les fraises mures, j’opterais pour de l'IA pour reconnaître les fraises mûres plutôt que de faire du traitement d'image "classique"), par contre, hors de question de s'en servir comme (unique) sécurité pour les fonctions de sécurité (dans l'exemple précédent, hors de question que la reconnaissance visuelle d'une "fraise" suffise à déclencher une pince puissante pour la couper en toutes circonstances : qu'est-ce qui se passe si c'est par exemple une bague en forme de fraise sur le doigt d'un enfant? Il faut forcément ajouter d'autres protections "classiques" : un capot au dessus de la pince, des capteurs de proximité pour détecter la présence d'un obstacle (potentiellement humain), un bouton d'arrêt d'urgence, un capteur de position et de force dans la pince pour détecter immédiatement si la pince essaye de couper quelque chose de trop gros, ...). Et cette notion de sécurité s'étend pour moi aussi à la sécurité du robot lui même : OK d'utiliser l'IA pour choisir une trajectoire, à condition qu'un algo classique vérifie l’absence de collisions, que le robot ne perd pas son équilibre, ... quitte à faire un arrêt d'urgence si l'algo classique ne valide pas le choix de l'IA.

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