Sandro

Super!

Je me disais bien que vu la puissance de tes moteurs, il y avait largement de quoi tourner sur place.

Et pour le PID, c'est bien ça l'intérêt : pouvoir choisir ta vitesse (par exemple 10cm/s), et la maintenir quel que soit la pente. Et au passage, tu peux aussi définir la vitesse à 0, et même si ton robot est dans la pente, il ne bougera pas

Bonjour,

c'est pas vraiment mieux non plus : https://www.mouser.f...93d-1849134.pdf , cf p3, lignes VCE(sat)H et VCE(sat)L

la perte typique est de 1.4V pour la sortie a l'état haut + 1.2V pour la sortie à l'état bas, soit une perte total de 2.6V (max : 1.8+1.8=3.6V) : c'est un peu mieux que le L298N, mais pas de beaucoup (et je ne suis pas sur que les 600mA te suffisent)

Sans connaitre tes contraintes exactes en terme de tension d'alimentation (tu comptes rester en 7.4V ou utiliser une tension plus élevée?) et le courant max de tes moteurs, je ne peux pas te donner d'indications précises sur quel driver convient.

Mais à titre de comparaison, si on prend 2 des drivers "décents" disponibles sur la boutique :

- DRV8833 (https://www.ti.com/l...ink/drv8833.pdf ) : résistance typique de 400mohms, donc perte de 0.4V @1A (le courant max en continue). Attention, tension limitée à 10.8V, donc tu le grille si tu utilises une batterie lithium 3 cellules

-  TB6612FNG ( https://www.mouser.f...1001-708260.pdf ) : perte de 0.5V @1A, tension max 15V

NB : on peut même trouvé des pertes encore plus faible si besoin

Bonjour,

pour les robots en kits, j'en ai jamais utilisé.

Roues -> controle plus précis (mais tu ne fera pas des miracles sans encodeurs)

Chenilles -> meilleur franchissement

Pour le second kit, il est prévu pour fonctionner avec 10 piles AA : donc à moins de remplacer l'alim, ça va te couter cher à l'usage.

Dans les 2 cas, il vas te falloir une raspeberry. Si tu veux faire du traitement d'images, je pencherait plutôt sur le haut de la gamme (je dirais une 4B avec 4GB (ou 8GB) de RAM).

Il te faut aussi une carte SD qui servira de "disque dur".

Et je te conseilles de prendre un adaptateur micro-HDMI vers XXX pour pouvoir y brancher un écran (c'est pas obligatoire, mais c'est parfois bien pratique).

Enfin, quand tu codes, c'est pratique de ne pas vider tes batteries, donc n'hésites pas à prendre une alim (pour la 4B, ils recommandent du 3A 5V, mais si tu branches pas trop de périfériques, je penses que 2A suiffisent, donc tu aura probablement un chargeur de téléphone qui traine qui ferra l'affaire).

Programmer en scratch, j'ai jamais essayé, mais ça semble possible.

Pour ROS, c'est possible aussi, même si j'ai l'impression qu'il y a quelques subtilités pour installer ROS2 (mais il y a des tutos)

Bonjour,

tout d'abord, pour les moteurs, ça a l'air d'être ceux là : https://education.ma...-encoder-motor/ : tu confirmes? En tout cas, même avec ton lien moins détaillé, le moteur est donné pour 5V ou 7.4V : pas dit qu'il résiste longtemps à 11.1V (en particulier les encodeurs), encore  moins à 12.6V (quand tes batteries sont chargées au max).

Pour tes batteries, je te déconseilles vivement de brancher deux batteries non identiques en série : l'une sera déchargée avant l'autre, ici la 3.7V qui a moins de capacité. Du coup, la tension totale restera positive, alors que la tension de la petite batterie descendra très bas, la tension totale suffisant à maintenir le courant. Si tu ne débranches pas à temps la petite batterie, tu atteindra vite des tensions critiques (<2.7V) qui endommageront ta batterie, voir risquent de la faire prendre feu/exploser, soit lors de la décharge, soit des charges suivantes.

Je te conseilles vivement de ne jamais mettre 2 batteries de types différents (ou même de vécu différent) en série, tout particulièrement s'il s'agit de batteries au Lithium : au mieux tu vas casser tes batterie à la moindre innatention, au pire tu vas mettre le feu à ta maison ou avoir une batterie qui t'explose entre les mains)

Pour vérifier si la batterie est assez puissante, tu peux brancher 0, puis 1, puis 2, puis 3, puis 4 moteurs en direct sur la batterie 7.4V, et vérifier s'ils tournent bien, et quelle est la tension de la batterie (si elle baisse fortement avec le nombre de moteurs, alors elle n'est pas capable de fournir assez de courant).

Ensuite, le choix des L298N comme controleur de moteurs est un très mauvais choix (je ne sais même pas pourquoi on les trouve encore de nos jours), surtout pour des moteurs très basse tension : en effet, on perd jusqu'à 4.9V de tension dans le L298N (cf https://www.st.com/r...asheet/l298.pdf, page 3, ligne VCEsat).

Je ne suis pas sur non plus que le convertisseur de ton module L298N te fournisse un 5V propre, en particulier lorsque la tension n'est que de 7.4V. Je te conseillerais plutôt d'alimenter l'arduino en 7.4V sur la pin Vin, et d'utiliser le régulateur interne de l'arduino.

Tu peux aussi vérifier si sur la sortie 5V tu as bien du 5V.

Si  976.56 Hz (la fréquence du PWM sur les pin 5 et 6) te suffit, alors ça n'a pas d’intérêt.

Si en revanche tu veux une fréquence plus élevée (980.39 Hz, 3921.16 Hz ou 31372.55 Hz), alors tu peux l'obtenir en une ligne de code pour une paire de pins (dans ce cas, je te déconseilles vivement la paire 5-6, car le timer sous-jacent est utilisé par millis et delay, donc si tu modifie le timer, tu modifie aussi toutes les mesures de temps).

Les codes pour changer les fréquences avec les explications sont dispo ici : https://arduinoinfo....o-PWM-Frequency

Je vous remets juste les codes :

//---------------------------------------------- Set PWM frequency for D5 & D6 -------------------------------
//NOTE: Changing this timer 0 affects millis() and delay!
//TCCR0B = TCCR0B & B11111000 | B00000001;    // set timer 0 divisor to     1 for PWM frequency of 62500.00 Hz
//TCCR0B = TCCR0B & B11111000 | B00000010;    // set timer 0 divisor to     8 for PWM frequency of  7812.50 Hz
  TCCR0B = TCCR0B & B11111000 | B00000011;    // set timer 0 divisor to    64 for PWM frequency of   976.56 Hz (The DEFAULT)
//TCCR0B = TCCR0B & B11111000 | B00000100;    // set timer 0 divisor to   256 for PWM frequency of   244.14 Hz
//TCCR0B = TCCR0B & B11111000 | B00000101;    // set timer 0 divisor to  1024 for PWM frequency of    61.04 Hz


//---------------------------------------------- Set PWM frequency for D9 & D10 ------------------------------
// Note : changing this affects Servo
//TCCR1B = TCCR1B & B11111000 | B00000001;    // set timer 1 divisor to     1 for PWM frequency of 31372.55 Hz
//TCCR1B = TCCR1B & B11111000 | B00000010;    // set timer 1 divisor to     8 for PWM frequency of  3921.16 Hz
  TCCR1B = TCCR1B & B11111000 | B00000011;    // set timer 1 divisor to    64 for PWM frequency of   490.20 Hz (The DEFAULT)
//TCCR1B = TCCR1B & B11111000 | B00000100;    // set timer 1 divisor to   256 for PWM frequency of   122.55 Hz
//TCCR1B = TCCR1B & B11111000 | B00000101;    // set timer 1 divisor to  1024 for PWM frequency of    30.64 Hz

//---------------------------------------------- Set PWM frequency for D3 & D11 ------------------------------
//Note : changing this affects tone
//TCCR2B = TCCR2B & B11111000 | B00000001;    // set timer 2 divisor to     1 for PWM frequency of 31372.55 Hz
//TCCR2B = TCCR2B & B11111000 | B00000010;    // set timer 2 divisor to     8 for PWM frequency of  3921.16 Hz
//TCCR2B = TCCR2B & B11111000 | B00000011;    // set timer 2 divisor to    32 for PWM frequency of   980.39 Hz
  TCCR2B = TCCR2B & B11111000 | B00000100;    // set timer 2 divisor to    64 for PWM frequency of   490.20 Hz (The DEFAULT)
//TCCR2B = TCCR2B & B11111000 | B00000101;    // set timer 2 divisor to   128 for PWM frequency of   245.10 Hz
//TCCR2B = TCCR2B & B11111000 | B00000110;    // set timer 2 divisor to   256 for PWM frequency of   122.55 Hz
//TCCR2B = TCCR2B & B11111000 | B00000111;    // set timer 2 divisor to  1024 for PWM frequency of    30.64 Hz

Il suffit de copier dans le setup la (ou les) lignes correspondantes aux fréquences que tu veux changer (pas la peine de les mettre si tu gardes la fréquence par défaut).

A noter que ces lignes modifient des registres (ie des variables internes du micro-controleur), et que le code ci-dessous ne sera valable que sur des micro-controleures ATmega328P (Arduino Uno et Arduino Nano). Pour d'autres modèles (par exemple Arduino Méga), on peut obtenir des résultats similaires, mais le code sera différent
 

Pour ce qui est de désassembler du code, c'est possible (je l'ai jamais fait sur arduino, mais je l'ai vu en cours sur linux).

Par contre, le résultat ne sera pas du C/C++, mais de l'assembleur, ie du language machine, et sans même les commentaires et étiquettes utilisées quand on écrit de l'assembleur à la main. En gros, tu obtiendra un code :

- dans un autre language de programmation (l'assembleur)

- avec aucun commentaire, ni mise en forme

- avec seulement des opérations super basiques (je crois que sur l'arduino, l'opération hardware la plus complexe doit être la division ou le modulo d'entiers) : toutes les opérations un peu plus complexes (toutes les opérations sur les float, les delay, les digitalWrite/read, ...) sont soit des appels de fonctions, soit une suite d'opérations élémentaires

- il n'y a pas à proprement de variables : il y a quelques registres (des variables "à tout faire" qui stoquent les valeurs pour les opérations en cours, mais vu qu'il y en a si peu, la même variable sert succéssivement à stocker plein de trucs différents) et des adresses mémoire. Donc imagine toi un code ou les variables s'appelleraient variable1, variable2, ... : et bien c'est encore pire que ça.

- toutes les boucles et les ifs ont disparus, c'est remplacé par des sauts en mémoire (un if, c'est un saut à après le if si la condition est fausse)

- ...

Donc oui, on peut lire un code désassemblé, mais c'est vraiment, vraiment pénible : il te faudra probablement plus de temps pour comprendre le code désassemblé que pour le re-écrire toi même.

Sans compter que sur la plupart des microcontroleurs bas-moyenne gamme, il n'y a pas de déboggueur, donc on ne peut même pas exécuter pas à pas le programme (ce qui aide beaucoup à comprendre le code désassemblé).

Donc si le challenge de la rétro-ingénérie te tente, tu peux essayer, mais si seul le résultat t'intéresse, je penses que tu sera plus rapide à re-écrire le code depuis zéro.

Bonsoir,

Tu confirmes que tu as mesuré 16A pour un seul moteur qui tourne dans le vide?!? C'est beaucoup trop. 18V*16A=288W. Pour comparaison, la puissance maximale autorisée pour un vélo à assistance électrique est 250W, et c'est en charge, pas à vide.

Je te conseillerais vivement (sauf si tu l'as déjà) d'ajouter un fusible ou un disjoncteur en sortie de ta batterie : une batterie lithium de cette taille, en cas de court-circuit, ça chauffe assez pour faire fondre du métal (déjà vu), voir ça peut exploser (il est bien possible qu'il y ait une électronique de protection dans la batterie, mais je ne miserais pas la maison dessus).

Pour tes cables d'alim, pour du 16A, j'ai l'impression qu'ils sont un peu fins. Sauf erreur de ma part, pour 16A, il est recommandé d'avoir une section d'au moins 2.5mm² (https://installation...able-electrique).

D'après le lien que tu avais donnée plus haut (https://fr.aliexpres...4105235410.html), "La séquence sur la carte doit correspondre à la séquence des lignes triphasées sur la carte de commande du moteur pour fonctionner correctement. Si vous ne connaissez pas la définition du fil de Hall, vous pouvez déboguer la basse tension et le courant à la première mise sous tension. Changer l'ordre de la ligne Hall jusqu'au fonctionnement normal, ne pas utiliser de courant important, débogage haute tension, si la ligne Hall n'est pas connectée en séquence, la machine de test haute tension et courant élevé" : c'est dur de comprendre la traduction automatique affichée sur aliexpress, mais ça peut peut-être s’interpréter comme le fait qu'une erreur sur le câblage des capteurs à effet hall peut entraîner de gros courants.

Si tu peux, je te conseilles aussi de commencer à faire tes tests à basse tension (9V devraient suffire pour faire tourner la roue à vide) : en divisant par 2 la tension, tu divises par 4 la puissance, réduisant ainsi le risque (autant pour les composants que pour tes doigts)

C'est une belle démonstration d'équilibre, et globalement un "beau" robot.

Par contre, pour des applications concrètes, et plus encore en milieu hospitalier, je suis assez septique :

- le système de boule est intrinsèquement instable : à la moindre défaillance du contrôle, la moindre panne d'un moteur, le moindre faux contact, ou même juste une batterie vide, et le robot bascule et tombe. Et se prendre un robot dessus entraînera probablement des blessures, d'autant plus graves sur des personnes déjà affaiblies.

- aucun système d'arrêt d'urgence n'est possible, vu qu'en cas d'arrêt des moteurs, le robot tombe

- je ne sais pas jusqu'à quel point le robot peut récupérer un léger déséquilibre, mais je penses que s'il se fait bousculer, il tombera probablement (dégâts sur le robot, voir risque de se le prendre sur le pied)

- il n'est pas possible d'éteindre le robot, sinon il tombe. Et contrairement à la plupart des robots à pattes, je n'ai pas l'impression qu'il puisse se mettre dans une position stable pour s'éteindre, et ensuite se remettre dans sa position de travail

- du fait de l'instabilité intrinsèque, le robot consommera de l'énergie juste pour rester immobile, réduisant d'autant l'autonomie

- vu la complexité du robot et le nombre de moteurs, le prix sera probablement conséquent. J'ai des doutes sur la possibilité d'amortir le prix du robot (surtout, si le but est juste de déplacer des plateaux, il n'y a même pas besoin d'un infirmier pour le faire : une personne sans la moindre qualification, payée au smic, le fera probablement mieux et avec plus de flexibilité).

- j'ai des doutes qu'il soit capable de transporter des charges bien lourdes

- ça vas être complexe de le rendre suffisamment étanche pour pouvoir être désinfecté régulièrement (contrainte propre à l’hôpital)

En avantages:

- grande mobilité sur sol plat (mais avec des roues mécanum, on obtient la même chose, stabilité en plus)

- la forme "sympatique" sera peut-être mieux acceptée (mais risque aussi de faire plus peur à certains)

- une belle prouesse technologique, surtout si, comme je l'ai compris, il a été développé en 1an (bon, à 50, ça aide)

A mes yeux, c'est un beau gadget, mais j'ai du mal à voir l'application pratique, et je suis assez septique sur l'application en milieu hospitalier

Pour ce qui est de B, je connais deux options :

1) si tu utilises ROS1, tu peux utiliser rosserial-arduino (cf https://maker.pro/ar...ting-system-ros ) : l'arduino se comporte alors "comme" un noeud ROS (nb : il faut lancer un noeud ros sur l'ordi pour "relier" l'arduino au réseau ROS. A noter que c'est assez lourd coté arduino (ie tu ne pourra pas publier/souscrire à beaucoup de topics différents, ni recevoir/envoyer des messages à haute fréquence). Je ne sais pas si un équivalent existe en ROS2.

2) Tu peux utiliser l'approche "classique" pour communiquer entre l'arduino et ton ordinateur via la liaison série via USB. Tu écris un programme coté ordinateur (ici un noeud ROS en C++ ou en python) qui écrit et lit sur la liaison série. Coté arduino, tu lis et tu écris sur la même liaison série : de cette manière, tu échange des messages comme tu veux (c'est toi qui définit le format des trames).

Quelques exemples de trames :

- chaine de caractère de commande (terminé par \n) : tu écris en clair ce que tu veux,avec éventuellement des nombres en texte. C'est intuitif, mais pas très optimisé

- envoi d'un nombre fixe d'octets (par exemple 6 octets si tu as 6 positions entre 0 et 255). Pour plus de robustesse, on peut ajouter un octet de début de trame toujours le même (par exemple 42) et/ou une checksum qui permet de vérifier que la commande est valide

- envoit d'un nombre variable d'octets : j'utilise en général le format suivant : octet_de_démarrage; longueur_le_la_trame=N; N octets d'information utile; xor de tous les autres octets

Bonsoir,

en effet, il est possible de commander un ruban RGB depuis une Arduino (à condition de choisir le "bon" type de ruban RGB, à savoir un qui est est prévu pour être commandé par un signal externe, et non par une télécommande par exemple). Les rubans led "adressables" (ie chaque LED est commandée indépendament) seront souvent commandable par arduino. Mais sauf si tu trouve une information explicite que ton modèle est commandable depuis une arduino, je te conseille de poster ici le lien avant de l'acheter pour qu'on vérifie ensemble si le ruban est bien commandable depuis une arduino.

Pour brancher des LEDs 5V (ou standard + résistance) directement sur les pins de l'arduino, c'est possible : il n'y a pas de limite de nombre en soit, mais des limites de courant : il est conseillé de ne pas dépasser 20mA par pin (et il y a des limites globales que j'ai plus en tête). Sinon, une solution simple, c'est de rajouter un transistor de type NMOS bien choisi (commandable en 5V et laissant passer le courant nécessaire) : on peut alors alimenter autant de LEDs qu'on veut.

A noter que si on veut pouvoir réguler la luminosité, il faut prendre des LEDs "bêtes" (ie sans régulation interne), et on ne peut utiliser que les pins PWM (6 sur l'arduino uno ou nano). A noter qu'avec un NMOS, un seul pin PWM peut controler la luminosité d'autant de LEDs qu'on veut (elles auront toutes la même luminosité)

Il y a 3 choses :

- si l'arduino est toujours en train de demander des pas au moment où tu désactive l'AU, alors il est complètement normal que le driver exécute ces nouveaux pas. Et l'Arduino n'a aucun moyen (dans l'état) de savoir si l'AU est enfoncé, donc n'arrêtera pas de demander des pas : elle enverra les mêmes commandes peu importe que l'AU soit ou pas enfoncé. Si l'arduino fini sa série pendant que l'AU est enfoncé, alors il n'y aura probablement pas de pas au désenclanchement de l'AU. Si en revanche l'arduino est encore en train d'envoyer des commandes au désenclanchement, les nouveaux pas s'exécuteront (mais les pas demandés pendant que l'AU était enfoncé seront probablement perdus)

- si toute la séquence "ratée" s'exécute au désenclanchement, alors tu es tombé sur un driver assez atypique.

- un moteur pas à pas a un certain nombre d'étapes pour faire un "cycle" complet (ie passer pas toutes les tensions pour les 4 fils), d'autant plus si tu es en mode micro-pas. Il est possible que le driver continue à avancer "dans son cycle", et que lors du désenclanchement, tu "sautes" donc dans un entre endroit du cycle

Globalement, l'implémentation la plus basique d'un DISABLE, c'est que le driver continue comme d'habitude, sauf que la tension de toutes les sorties est mise à 0V (ou en haute impédance). Ensuite, selon le driver, la logic de controle interne sera également bloquée ou pas. Il n'y a que la documentation détaillée (datasheet) qui peut te le dire (ou des tests)

Bonjour,

j'ai pas le temps de regarder en détail, mais à première vue, ça semble pouvoir convenir (nb : la carte utilise les capteurs à effet hall du moteur brushless en guise d'encodeurs : c'est moins précis que de vrai encodeurs, mais possible que ça suffise). NB : si tu utilises des moteurs 24V, il faudra l'alimenter en 24V (et tant mieux, car les batteries 48V, c'est pas très répondu)

Bonsoir,

Tu veux faire quoi? Guider le robot vers une cible unique (par exemple la station de recharge), ou avoir plusieurs cibles.

Si tu veux une seule (ou 3-4) cibles, alors une solution facile pourrait être les lumières vives : tu détecte la tache la plus vive en bleu, violet, orange, ...

Sinon, pour ce qui est des QR codes, c'est pas optimal, mais globalement, plus tu as de pixels, moins tu as de porté de détection (et bien sur, plus la cible est grosse, plus tu la voie de loin). Sinon, si tu es prêt à quiter la Huskylens pour une caméra+micro-ordinateur, alors je te conseilles de passer sur les AruCo Tag (ou les April Tag, ou les AR Tag), qui sont optimisés pour la détection de loin (ils ont moins de pixels, et un contour noir bien reconnaissable). Plus tu prendra une caméra haute résolution, avec un temps d'exposition si possible court (global shutter est l'optimal), et si possible avec un champ de vision étroit, plus tu pourra détecter les tags de loin. Pour ma part, avec une caméra 2K plutôt grand angle, je détectais des AR-tags de 25*25cm à 10 à 20m de distance. Sur un autre projet, j'arrivais à détecter un tag de 1.5*1.5m à 30-40m de distance avec une caméra de bien plus faible résolution (720p ? je ne suis plus sur)

Pour le zoom, avec la Husklens, est-ce que ça ne vas pas "casser" la calibration (et donc donner des positions complètement fausses)? À moins qu'on puisse la recalibrer.

Si c'est un zoom réglable (ie motorisé), il est quasi-impossible de le calibrer proprement, donc on n'aura pas de position précise. Mais si le but est simplement de se diriger vers la cible, alors je suppose que ça doit être faisable.

Bon, alors on a tous les éléments qu'il nous faut pour faire les calculs :

r=rayon_roues=350mm/2=175mm = 0.175m

p=périmètre_roues=2*pi*r = 1.1m (=distance parcourue en un tour de roue)

v_lin=vitesse_linéaire = 0.5 m/s (ton objectif)

ce qui correspond à nbr_tours_par_seconde = v_lin / p = 0.5 / 1.1 = 0.45 tours/s

soit en tours par minute (rpm) : w=nbr_tours_par_seconde*60 = 27.3 rpm

Il te faut donc un moteur qui tourne à au moins 27.3 rpm en charge (attention, on ne parles pas de la vitesse à vide, qui est plus élevée). Si ton moteur est plus rapide, c'est pas un problème (au contraire), tu pourra baisser la vitesse avec le controleur moteur, et ça te laissera de la marge de sécurité.

Calculons maintenant le couple nécessaire. En système internationnal, le couple est en N.m : on utilisera donc cette unité pour les calculs (par contre, la plupart des vendeurs donnent le couple en kg.cm, donc il faudra convertir). Il y a deux contraintes sur le couple : l'accélération, et la capacité à monter une pente.

1) L'accélération.

D'après la seconde loi de newton, on a :

m*a=somme_des_forces.

où :

- m est la masse du robot (m=50kg)

- a est l'accélération du robot, en m/s^2

- somme_des_forces est la somme des forces exercées sur le robot (en N). A noter que sur un sol plat, le poids du robot, et la réaction du sol s'équilibrent, il ne reste donc que la force des moteurs. Si on pars sur 4 moteurs, on a donc somme_des_forces=4*Fmot où Fmot est la force d'un moteur.

On veut que le robot passe de la vitesse v0=0 à la vitesse vmax=0.5 m/s en dt=5s, donc on a besoin d'une accélération a=(vmax-v0)/dt= 0.5/5= 0.1 m/s^2

On a donc m*a=4*Fmot. Donc Fmot=m*a/4=50*0.1/4 = 1.25 N

Chaque moteur doit donc exercer une poussée de 1.25 N (soit l'équivalent du poids de 0.125 kg)

La roue à un rayon r=0.175m, et on veut qu'elle exerce une force Fmot=1.25N. Donc elle doit exercer un couple C = r * Fmot = 0.175*1.25 = 2.2 N.m.

Donc sur un sol parfaitement plat et lisse, avec 4 moteurs, chacun devrait avoir un couple d'au moins 2.2 N.m pour te permettre d'atteindre la vitesse max de 0.5 m/s en 5 secondes max.

2) montée de pente.

D'après la seconde loi de newton, on a :

m*a=somme_des_forces.

où :

- m est la masse du robot (m=50kg)

- a est l'accélération du robot, en m/s^2. Ici, on considère qu'on veut monter à vitesse constante, donc a=0

- somme_des_forces est la somme des forces exercées sur le robot (en N). Cette fois-ci, la réaction du sol ne pousse plus verticalement, mais perpendiculairement à la pente : elle n'anulle donc que la composante du poids selon la perpendiculaire à la pente, mais pas la composante parallème à la pente.

On a donc m*a=0, donc somme_des_forces=0.

Si on projète les forces parallèlement à la pente (perpendiculairement à la pente tout ce compense), alors on a 0=somme_des_forces=4*Fmot + F_poids_parallel

Avec Fmot la force exercée par un des moteurs et F_poids_parallel la composante du poids parallelement à l'axe.

On a F_poids_parallel= - m*g*sin(pente), où m est la masse du robot (50kg), g est l'accélération de la pesanteur (c'est une constante, qui vaut g=9.81 N/kg), et pente est la pente en degrés (ie 25°)

On a donc 4*Fmot - m*g*sin(pente)=0. Donc Fmot=m*g*sin(pente)/4 = 50*9.81*sin(25°)/4 = 50*9.81*0.42/4=51.8 N

Comme tout à l'heure, on peut convertir cette force en couple du moteur, en applicant C=r*Fmot = 0.175 * 51.8 = 9.1 N.m

3) Conclusion couple

on voit bien que monter la pente demande beaucoup plus de couple que les accélérations, donc il faut dimensionner les moteurs avec le couple pour la pente (et tu pourra atteindre ta vitesse max en bien moins que 5 secondes). Il faut donc au minimum, en théorie, un couple de 9.1 N.m si tu pars sur 4 moteurs (si tu n'en utilises que 2, chacun doit fournir 2 fois plus de couple). En pratique, il faut faire attention au fait que le couple à regarder est le couple à la vitesse à laquelle tu veux rouler (souvent on te donne le couple max, qui correspond au moteur bloqué : ça permet de sortir d'un nid de poule mais pas de monter une pente). Et il faut prendre en compte que tu aura des pertes mécaniques dans ta transmission par chaine et dans tes roulements, donc en pratique, il te faudra plus de couple que la valeur théorique. Je partirais sur minimum 14 N.m

Pour info, les vendeurs donnent souvent les couples en kgf.cm (certains écrivent juste kg.cm) : 1 N.m = 10.2 kgf.cm

Conclusion générale :

Pour répondre à ton cahier des charges (avec le choix des roues et le poids du robot), il te faudrait donc un moteur avec :

- une vitesse nominale d'au moins 28 rpm. Je te conseillerais de viser entre 35 et 50rpm (il est facile de ne pas faire tourner un moteur à fond)

- un couple nominal d'au moins 14 N.m (env 500 kgf.cm) si tu pars sur 4 moteurs (le double si tu n'en prends que 2). Plus tu as de couple disponible, mieux c'est, excepté que le moteur deviendra plus gros et cher et lourd. Je te conseillerais de chercher entre 15 et 30 N.m

NB : j'insiste sur le fait qu'il s'agit de vitesse et couple nominal, ce qui veut dire que 1) le moteur est conçu pour supporter ces vitesses/couples dans la durée et 2) qu'il peut fournir cette vitesse et ce couple en même temps (un moteur pourra fournir plus de couple que le couple nominal, mais il tournera alors moins vite). Si jamais tu pars sur des moteurs qui ne spécifient pas de vitesse et de couple nominal, alors il faut y aller un peu au pif : je te conseillerais dans ce cas d'en prendre avec une vitesse à vide d'au moins 40 rpm, et d'un couple max d'au moins 20N.m. Mais en général, si le fournisseur donne pas les vitesses et couple nominal (ou une courbe vitesse vs couple), alors c'est mauvais signe sur le sérieux du vendeur et/ou du fabriquant.

A part ça, il y a quelques autres points à prendre en compte :

- vérifie que le moteur est prévu pour 24V

- vérifie que le moteur ait des encodeurs intégrés (ou une tige à l'arrière pour en ajouter toi-même), sauf si tu comptes mettre les encodeurs sur des roues supplémentaires

- vérifie que le moteur te donne le courant consommé (idéalement à la fois le courant nominal et le courant max)

- vérifie que le moteur se laisse fixer raisonnablement

- vérifie les dimensions du moteur

Bonne soirée

Sandro

PS : le tout sous réserve d'erreurs de calculs

EDIT : correction d'une erreur de calculs, une division par 4 avait disparue en cours de calcul sur le couple en pente

Pour les roues, il faudra faire attention à prendre des roues prévues pour être motrices (sinon, il y a un risque que le pneu tourne autour de la jonte, si la roue est prévue comme non motrice). Dans mon ancienne boite, pour un robot de taille à peu près similaires, on avait pas mal galéré pour trouver des roues motrices solides. On avait fini sur des roues de quad.

Pour la dimension, je dois avouer que j'ai pas trop l'abitude des tailles de roues. 3.5x6 correspond à 6 pouces de diamètre et 3.5 pouces de largeur? Si c'est pas ça, c'est quoi le diamètre extérieur?

Pour les moteurs, je te conseillerais de partir sur 1 moteur par roue : ça rend le robot beaucoup plus maneuvrable, et en mode 4x4, tu aura plus de facilité sur des terrains non plats. OK pour du brushless.

Vitesse max en 5 secondes ne devrait pas trop poser de problème.

Par contre, il manque l'information de la pente max du terrain. Si le terrain est quasi plat, alors je proposes de partir sur 25° pour avoir asser de puissance pour ne pas être trop embêté par des nids de poule.