Robot Coupe 2014 IFRELO

[Goo]

le code du PR est pas encore open-bière

Il n'a pas l'option décapsuleur ? (ok je sors ...)

Merci pour l'exe, je suis également en train de continuer ma petite interface sous QT, je partagerais quand ca marchera un peu mieux :p

 

[louloute30]

[aux info:]
A l'origine, j'ai toujours été meilleur en prog qu'en méca, d'ailleurs, la méca, ce n'est que depuis que j'ai une CN que j'en fais... Alors que la prog, j'ai commencé sur TurboPascal (les anciens connaissent sans doute...) et QBasic, puis Visual, puis à l'arrivé d'internet dans nos maisons, j'ai enchaîné plusieurs années avec PHP-CSS-java, retour sur Visual 2008 (pour prise en compte du port COM => Top pour gérer une table d'éclairage sono), Visual C++ ed express, et après, apparition dans ma vie de "arduino", depuis je mélange un peu tout ça pour faire qq ch de mon temps libre... (j'en ai surement oublié au passage...)

Par contre, je n'ai jamais suivi d'études ni en méca, ni en prog, forcément, désolé goulou de ne pas avoir utilisé les "bons termes"... Maintenant, je sais grâce à toi ce que sont des graphcets ! (mes fameuses µStrat )

Je pêche uniquement sur un point, comment utilisez vous un µproc pour réaliser plusieurs tâches en même tps ?
- Est-ce que c'est plusieurs programmes qui tournent en même temps (Alors là, je ne vois pas comment faire ça avec 1 seul µproc),
- ou est-ce que vous avez dvpé un seul moteur mais multi-tâche ? (dans ce dernier cas, ok, je vois que vous avez poussé la prog à fond et passé qq heures en plus que moi ! Ma foi, je serai bien assez fou pour le faire d'ici la coupe.

Mais, il me semble que chez CVRA, vous avez plusieurs prog qui tournent en même temps d'après ce que j'ai entendu.
Je me vois tout à fait capable de ça MAIS, avec plusieurs µproc (1prog / µproc), sauf que chez CVRA ils n'ont qu'un seul µproc (principal).

Par ex, si on reprend le PR des SC 2013, il m'aurait fallut 2 µproc (1 pour la strat et les déplacement, l'autre pour la fabrication de la pile de verre) => c'est ce que j'avais fait dans mon GR cette année.


Là, goulou, tu me dis que tu utilises du C pour les déplacements, et du C++ pour les graphcets ? et tout ça qu'avec la TI ?
Je me demande comment faire ça.
[/aux info]

Ne me représentant pas l'année prochaine à la coupe, je vais prendre le temps de développer une interface bp plus pointue, avec une communication continue avec un "Robot-Mère" et un système de triangulation (repérage adversaire) pour développer la partie Stratégie.
Ce sera sans doute en V2008 Ed express.
Et,,, le code sera open source ! Mais ce n'est plus vraiment de l'usinage, alors dois je placer ici... je verrai bien. Mais vous serez informés !

 

[linus63]

comment utilisez vous un µproc pour réaliser plusieurs tâches en même tps ?<br abp="803">- Est-ce que c'est plusieurs programmes qui tournent en même temps (Alors là, je ne vois pas comment faire ça avec 1 seul µproc),<br abp="804">- ou est-ce que vous avez dvpé un seul moteur mais multi-tâche ?

Excellente question!! Chez nous on est plutôt multi micro. On a par exemple un micro pour l'asserv, un pour les servos, un pour la strat... Cela dit, il y a toujours un moment où il te faut faire du multi tâches dans les cartes. Très souvent, les interruptions processeur permettent de faire un pseudo multi tâches. Dans le cas d'une carte asserv, tu peux utiliser un timer qui va envoyer et calculer les consignes moteurs à intervalles réguliers pendant que ton programme principal calcule la position ou autre. Si cela ne suffit pas, je vois trois solutions:

Solution 1: utiliser un noyau temps réel. Solution somme toute assez complexe qui est souvent une source de problèmes... Dépendant de la cible code non portable et souvent baisse des performances sur une petite puce.

Solution 2: faire son propre noyau temps réel. Non je ne suis pas fou! Derrière ce "gros mot" se cache un système d'une simplicité déroutante pour nos besoins. De quoi a t'on besoin? De tâches que l'on peut démarrer, arrêter, qui exécutent un bout de code à intervalle régulier. Et toutes les autres primitives d'un noyau standard ne nous sont pas ou peu utiles. J'avais implémenté l'an dernier un petit bout de code sur PIC qui permettait de lancer des fonctions comme étant des tâches. Il suffisait de les ajouter à une liste de tâches et un timer les lançait une à une. Je vous envoie le code sur simple MP.

Solution 3: travailler en pull avec des flags. Cette méthode est un peu moins naturelle. Il s'agit de faire appelle à des fonctions depuis la boucle du programme principale. Cette solution n'est pas très adaptée à une stratégie...

Bref j'espère avoir été clair et que cela puisse t'éclairer

Seb

 

[goulou]

[aux info:]

Là, goulou, tu me dis que tu utilises du C pour les déplacements, et du C++ pour les graphcets ? et tout ça qu'avec la TI ?
Je me demande comment faire ça.

Non non, tout est en C! (mais il est tout à fait possible de mélanger C et C++ dans le même programme!).
Bon, je crois que Graphcet ça s'écrit grafcet en fait, mais je suis pas sûr (par contre, le correcteur d'orthographe oui...)

Pour ce qui est du multi-tache, voici comment je fais dans le code du PR :
-lissage de la commande en vitesse : IT à 256µs
-asservissement des moteurs en vitesse : IT 1ms
-lissage de la commande en position : IT à 5ms
-asservissement de la commande en position (avance+angle) : IT à 10ms
Dans le lot, les 2 premières sont critiques, les 2 autres le sont moins.
En dessous de ces 4 ITs, je tourne en "polling" pour tout le reste : calcul de la stratégie, exécution des actions du grafcet, communication sur le bluetooth (depuis/vers le PC de debug ou le GR). Je poste alors des évènements (démarrer tel actionneur dans 100ms), et je vérifie la date courante pour la comparer à tous les évènements en permanence dans une boucle. C'est absolument pas optimal, mais amplement suffisant
Ce qu'il faut imaginer, c'est que la tache de fond tourne en permanence, et peut être interrompue par la tâche à 10ms, qui peut être interrompue par celle d'au dessus, etc etc...
Généralement, on déconseille de mélanger les ITs car les problèmes arrivent vite... (et les stacks se cumulent, ce qui peut devenir critique si l'on n'a pas beaucoup de RAM). Dans mon cas, je spécifie explicitement des priorités différentes, comme cela je sait qui interrompt qui.

En gros, je fais donc un gros mélange, et ça marche bien grâce à la TI : elle a suffisamment de puissance pour que tout s'enchaîne suffisamment vite et que les timings soient "corrects". Je n'ai jamais testé plus loin pour valider les timings, mais "tant que ça marche, on ne touche à rien!". Dans la pratique, il m'arrive d'avoir des latences de l'ordre de 10ms sur la boucle de stratégie, ce qui est amplement suffisant!

C'est donc cela qu'il faut évaluer : soit tu t'embarques sur une solution type "temps réel" et tu te mets d'énormes contraintes, soit tu fais du best effort, et tant que ça marche tu continues
Tout dépend des quantités de calcul que tu fais dans chaque IT...

(mais attention, on dérive et on va se faire engueuler par les modos d'usinage.com )
[/aux info]

Par contre j'ai pas compris ton idée : comme tu ne fais pas la coupe l'année prochaine tu y passes plus de temps cette année c'est ça? J'aurais plutôt dit que comme tu la fais l'année prochaine, tu passes plus de temps cette année car ce sera du temps capitalisé pour l'année prochaine!

 

[louloute30]

@linus: Ha, y a des pistes... Merci

@goulou Merci pour ces explications ! Tip top ! Effectivement, c'est bp plus claire. (et content de savoir que ça reste dans mes compétences hum,,, avec des moteurs CC tant qu'à faire). En l'état, mon PR est dans une boucle le temps qu'il effectue le nb de pas, et donc, c'est moins facile d'opérer...

Par contre j'ai pas compris ton idée : comme tu ne fais pas la coupe l'année prochaine tu y passes plus de temps cette année c'est ça? J'aurais plutôt dit que comme tu la fais l'année prochaine, tu passes plus de temps cette année car ce sera du temps capitalisé pour l'année prochaine!

En fait, normalement, je ne devrais pas la faire l'année prochaine, ni peut être celle d'après, le temps de fonder une bonne équipe, mais je vais utiliser ce temps à profit pour remettre à plat certaines choses, et travailler des parties de codes ou de méca qui ne nécessitent pas forcément de règlement (Asserv - communication PC et PR-GR, interface PC, IA, balise de repérage adversaire...) histoire qu'il ne me reste (presque) que la méca à me soucier pour la coupe 201X. Sinon, ça reste trop dur de tout faire, et puis finalement, je ne prends pas assez de temps à bien tout exploiter: Par ex, j'avais un super capteur de couleur que je n'utiliserai finalement pas, sans compter que mon GR ne sera très probablement pas prêt... Bref, du gâchis chaque année.
Cette année, je mise bp sur le PR et son IA, le GR de remplacement n'a pas de tâches très évoluée...
Je dois dire que je stagne un peu chaque année et j'aimerai présenter un truc qui tient vraiment la route maintenant ! Alors il me faut plus de temps pour une seule coupe...

 

[antoine_cvra]

Salut louloute,
Alors effectivement, on a un seul microprocesseur pour tout gérer et dans celui ci on fait tourner un noyau temps réel (et quasiment tout dans une seule interruption ). Néanmoins, contrairement à ce que décris linus pour ses PICs, qui semble être un noyau "collaboratif", c'est à dire où chaque tache se termine pour laisser sa place à la suivante à un moment ou à un autre, on utilise un noyau "préemptif", c'est à dire que tes tâches peuvent prendre autant de temps que nécessaire pour leur exécution et le noyau se charge de les mettre sur pause au milieu du code et de reprendre où elle en était plus tard. Il y a également un système de priorité qui te permet de définir quel tâche peut interrompre une autre (exemple chez nous : la tâche de communication est moins importante que l'asservissement, donc celui ci peut interompre la comm pour s'exécuter mais pas l'inverse).

Réaliser un noyau de ce genre est un projet en soi, et nous avons choisi de ne plus le développer nous même (on le faisait l'année passée), car c'est quand même difficile à programmer sans introduire d'erreurs qui peuvent être très compliquées à corriger. Nous utilisons donc un noyau industriel, connu sous le nom de uc/OS-II développé par Micrium et qui est gratuit pour la recherche et le hobby. Beaucoup d'informations se trouvent sur leur site internet : http://micrium.com/rtos/ucosii/overview/. Ce noyau a l'avantage d'être vraiment très très bien documenté (il y a un livre entier qui détaille chaque fonction) et très stable.

Par contre utiliser ce genre d'outil est assez difficile, tu dois notamment faire assez attention sur comment tu communiques entre deux tâches : écrire dans une variable globale peut être assez catastrophique suivant comment. Heureusement le système te fournit des interfaces permettant de garantir, par exemple, qu'une seule tâche va accéder à une variable donnée simultanément.

Pour finir sur un exemple plus concret,de à quoi ca ressemble une tâche codée avec ce système, tu peux par exemple voir notre tâche d'odométrie ici : https://github.com/antoinealb/debra/blob/master/cvra_cs.c#L207. Comme tu peux le voir, c'est vraiment agréable : tu fais juste une boucle infinie avec des attentes si nécessaire, et le noyau s'en occuppe à ta place.

Si t'as encore des questions. je reste à ta disposition !

 

[Keuronde]

Chez Poivron, cette année, on utilise deux microcontrôleurs. On s'en sort principalement avec des routines en interruption et de machine à état.
Par exemple pour la commande d'un moteur pas à pas, on aurait une routine en interruption.

Cette routine déclencherait le pas du moteur pas à pas et planifierait avec un timer le pas suivant. (Un peu comme la fonction mPaP_int() du fichier https://github.com/Keuronde/Poivron-2011_PIC/blob/master/R11_Moteur/PaP/PaP.c).

D'un autre coté, on aurait une machine à état non bloquante avec trois état : Initialisation, EnCours et Terminé.
Initialisation : On défini le nombre de pas à parcourir, le sens, et on passe à l'etat Encours. (Comme la fonction set_consigne(int consigne) du fichier précédent - Attention, c'est moche)
EnCours : On regarde si tous les pas on été parcourus, si oui, on passe à l'état terminé.
Terminé : On ne fait rien, mais la variable d'état de la machine à état peut être utilisée pour déclencher l'action suivante.

Nous n'avons que des fonctions très courtes. On arrive à gérer la stratégie, les capteurs soniques, les servomoteurs, la com (I2C et série) sur un microcontrôleur PIC 18F (8 bits - 12 MIPS) et sur l'autre, l'asservissement des moteurs, la localisation du robot, la gestion du gyroscope et la com I2C sur un autre microcontrôleur dsPIC 33F.

Un exemple simple de notre attente pour la tirette de démarrage :
switch(etat_strategie){
case ATTENTE_TIRETTE:
if ( TIRETTE == 0){
etat_strategie = ACTION_1;
}
break;
case ACTION_1:
// Code pour lancer l'action 1
break;
}

Ca doit se rapprocher de la solution 3 décrite par linus...

Désolé pour le hors sujet...

 

[louloute30]

Petites news en direct de la Ferté!

Notre premier match nous permet d'atteindre la 20ème place, à 3 points de la 15ème place... sur près de 100 équipes homologuées.
Mine de rien, on va tenter d'arracher la 16ème position. Qui sait, pourquoi pas.
Et puis, on n'a encore qq stratégies en rab qui permet de gagner un surplus de 9 à 11 points en diminuant les risques de collision; On va donc tenter ça demain. En espérant ...

Bilan Premier match: 18 points.
le PR dépose les 2 fresques, + 2 balles sur 3 sur le mammouths de notre coté, par contre, le PR reste collé aux fresques (littéralement) donc, pas de possibilité de lancer les 3 autres lances.
Le GR se fait percuté en pleine face par l'équipe adverse et nous fait perdre notre position, il n'arrive finalement pas à lancer le filet.

On va donc assurer ses "points perdus" par une stratégie plus soft, on verra le résultat demain.

PS: La wifi est arrivée à la Ferté !

A bientôt!

 

[antoine_cvra]

Oh la classe ! Ca serait top que tu sois dans les 16 premier ! Bonne chance en tout cas

 

[romain_cvra]

Je cherchais IFRELO mais en faite c'est Evasion

Qu'est ce qui c'est passé se matin? Courage! Tu peux remonter!

 

[romain_cvra]

PS: La wifi est arrivée à la Ferté !

Bien pratique sa!

Il faudrait qu'il améliore la webtv pour l'année prochaine parce que niveau bande passante et qualité c'est pas ca...
Il y a du son 1x sur 2 et l'image est vraiment de mauvaise qualité... pas facile de suivre les match...

 

[louloute30]

Bonsoir,

Je suis vraiment crevé de cette semaine, et surtout suite aux incident hélas rencontré le vendredi:
En cause principale, l'odométrie: Je n'arrivais pas à comptabilisé tous les pas de la roue codeuse droite du PR.
J'ai cherché d'un point de vu méca, prog... rien n'a fait.
Le dernier match, on a simplement retirer le PR pour éviter que ça se reproduise, et marquer "qq points d'encouragement".
La nuit m'a permis de recoder un asserv sans odo, pour finalement, repartir samedi avec un meilleur score que la veille, mais, le vendredi nous a été fatal !

Toutes les vidéos des matchs et photos bientôt dispo, dès que mes yeux supporteront à nouveau un écran d'ordi !

Ma foi, je suis content du résultat au classement...

A très bientôt.

 

[Goo]

PS: La wifi est arrivée à la Ferté !

Il faudrait qu'il améliore la webtv pour l'année prochaine parce que niveau bande passante et qualité c'est pas ca...

Il faut qu'ils changent les disques dur aussi ^^. Ils ont perdu 1h de tournage dont les 20 min de notre passage à on refait le match :'(.

Tout de même félicitations à EVASION pour le classement final

 

[TDS-Team]

Je n ai pu vous voir a votre stand, mais j ai vu 2 match de votre part, vos robots simple et efficace fonctionné vraiment bien

 

[louloute30]

Je n ai pu vous voir a votre stand, mais j ai vu 2 matchs de votre part, vos robots simple et efficace fonctionné vraiment bien

Salut TDS-Team,
Je dois dire que je n'ai pas fait non plus le tour de bp d'équipes ici présentes, et en suis désolé. Préoccupé par mon Vendredi noir, ça a cassé tous mes plans de ce coté.

Si tu parles de mon premier et dernier match, ok, ils étaient bien, mais les 3 du vendredi, pour qu'on en arrive à supprimer le PR du jeu, c'est qu'il y avait de sacrés pb avec...

On se rencontrera peut-être une prochaine fois !

[Je vais reprendre la fabrication de mon imprimante 3D...]

 

[TDS-Team]

Oh oui sans probléme, on est de la Ferté ... On est pas bien loin quoi ...

 

[antoine_cvra]

Salut louloute,
Hier avec Romain on discutait de tes problèmes de comptage de pas, en réfléchissant bien on est arrivé à différentes observations :

• Si tu as des codeurs industriels qui n'ont pas pris de choc, un défaut soudain du codeur nous parait peu probable.
• Un problème de décompte de pas par le module hardware des TI, c'est juste pas possible à mon avis, ils peuvent monter bien plus haut en fréquence et le bug apparaitrait pas soudainement.

Est-ce que tu utilises un outil pour gérer les versions de ton software, genre Git/Mercurial/SVN ? Si oui, tu peux facilement voir ce qui a changé dans le soft, sinon, tu devrais vraiment t'y intéresser, c'est super pratique de pouvoir savoir ce que tu as changé d'une version à l'autre facilement pour débugger les jours de coupe

A partir de là, deux possibilités :

• Un problème de câblage, un contact intermitent, etc.
• Ton codeur pourrait avoir besoin de résistance de pull-up que tu pourrais avoir oubliées ou alors elles ont une valeur bien trop grande !

Si tu as un oscilloscope, ca doit être faisable de vérifier si les flancs venant du codeur sont bien droits, et vérifier dans la datasheet du codeur si il a besoin de pull-up et si oui de quelles valeurs.

En tout cas c'est vraiment dommage ces bugs soudains :(

 

[louloute30]

Salut antoine,
Je vais essayer à nouveau cet après-midi le PR avec la première Stratégie (celle qui a bien fonctionné).
Je te dirai s'il y a un changement.
Actuellement, je n'ai pas de logiciel de débuggage, à part l'interface Serie, qui m'indique la position Théorique du robot...

Autrement, voici un petit bilan de la semaine...

Phase homologation…
La Statique passe bien, la dynamique aussi, jusqu’à la vérification des capteurs du PR...
Ceux-ci étaient dans un premier temps réglé un peu trop proche ; On voit bien qu’il rentre dans le robot en bois.
Second passage, ils sont réglés à 20cm de la cible, mais ce coup ci, on me demande de les placer de manière incliné pour mieux voir du coté des flancs… D’un sens, il n’avait pas tord lorsqu’on regarde notre premier match, où les 2 PR se rencontrent, mais dans ce cas, les toulousains auraient aussi dû revoir leur capteurs/balises.
Bref, grosse difficulté à passer la dynamique cette année, avec les mêmes capteurs que l’année passée. => Ccl, désormais, je les placerai dans des balises !
[Vidéo en cours de téléchargement]

Premier match, face aux toulousains, mes robots ont fait leur travail…
Sauf que le PR est resté collé à la fresque, pas la force de pouvoir avancer (c’est pour dire le risque de casse sur un robot adverse), et que le GR s’est fait rentré dedans par le GR de l’autre équipe : de ce fait, il a perdu 20cm sur sa trajectoire environ, et le servomoteur droit a été abîmé ; C’est pourquoi, il fait tomber le triangle adverse, et a bp de mal à rejoindre le mammouth pour le filet.
18 pts.
PS : L’un des support balise de notre GR n’était pas droit au départ, j’ai donc placé une petite cale par-dessous (une pièce de 2€, j’ai prié pour qu’elle ne tombe pas sur la table)

Le Vendredi Noir…
Second Match, on modifie la prog, on attribue au PR l’obligation de tirer les 6 balles sur notre mammouth, faute d’avoir testé dans nos loges, le GR sort, et ses capteurs placés aux extrémités de ses cotés, ne permettent pas de repérer le PR qui est au centre du GR. Le GR perd son cap, sa distance… et de plus, nous avons pu remarquer que le GR n’avait pas la possibilité de voir de très près: d’où le rentre dedans. Concernant la pièce casée, qui appartient à l’équipe d’en face, ils m’ont indiqué qu’elle était mal fixée…
Là, on se prend une pénalité de 5pts. Pour blocage + mauvaise visibilité.
Enfin, le match dure plus de 1:30 minutes...
0pts

Troisième match, on retente avec la même strat, mais un délai de départ au GR plus long ; Le PR cette fois ci, en fait à sa tête, et l’un de ses petits bras à l’arrière se coince dans le GR… On suppose que les codeurs en sont la cause. Après qq tests sur notre table devenue sale, on voit que le PR est incapable de faire une ligne droite.
5 pts (ou 1pts je ne sais plus)

Quatrième match, au vu des résultats, on décide de retirer le PR du jeu. Le GR fait alors son travail correctement.
11 pts

Cinquième match, après avoir recoder entièrement l’asservissement sans implémentation des impl des roues codeuses (sans odo), et coté GR, on lui fait faire à sa sortie 2 rotations de 45° au lieu de 90° de manière à ne plus rencontrer le PR, on réalise un match de 21 points.

Quelques tests du PR en loge… (avec tentative du triangle sur foyer adverse).

Coté Moumoute…

 

[louloute30]

Bonsoir,

il me semble avoir entendu que le thème 2015 est ROBOTMOVIES... à moins que je me suis fait des films...

 

[syoctax]

Oui et les règles seront diffusées le 27 septembre (ça va être long...)

 

[looplyla]

je confirme, ça viens d'être annoncé officiellement. et la coupe Eurobot aura lieu en suisse à yverdon-les-bains.

 

[louloute30]

Re,

A ceux qui ont suivi mon pb avec les encodeurs, il se trouve que j'ai pris le temps de bien recharger la batterie, j'ai lancer le code du 3ème match sans changer une ligne, et il a parfaitement bien fonctionné.
Je suppose qu'il s'agissait d'un pb de batterie... bien secouée la journée du vendredi avec les matchs et les tests... Ca m'apprendra à ne pas me servir du transfo sur place...

Je rajouterai donc sur les futurs robots, une prise XLR au milieu de mon support balise pour amener du 12V et 24V au robot + une fiche USB.

La bonne nouvelle, c'est que ni les codeurs ni la TI n'a subit de dommage. (comme me l'avait suggérer MrDus, un pb de batterie !)

 

[looplyla]

la tension d'alimentation de tes codeurs n'est pas régulée? bouclé (monitoring de la tension de sortie)?
si tu devais changer quelque chose à ton électronique pour éviter ce genre de problème, que ferais-tu?
je demande ça parce qu'on a aussi subi les affres de la variation en tension des batteries sur nos programmes.

 

[Goo]

variation en tension des batteries sur nos programmes.

Sur quelle partie ? Car mis à part la tension d'alimentation des moteurs, j'ai du mal à voir où peut-on avoir ce genre de problème.

 

[looplyla]

mis à part la tension d'alimentation des moteurs, j'ai du mal à voir où peut-on avoir ce genre de problème.

précisement là, les moteurs!

 

[syoctax]

précisement là, les moteurs!

Si il y a un asservissement, le comportement devrait être le même quelque soit la tension des batteries non? (hormis la vitesse max)

 

[Goo]

précisement là, les moteurs!

Si il y a un asservissement, le comportement devrait être le même quelque soit la tension des batteries non? (hormis la vitesse max)

Souvent on alimente les moteurs avec une fraction de la tension batterie (hacheur), même avec un asservissement les différences se font sentir.
En effet, cela revient quasiment à une modification des coefficients de manière proportionnel à la variation de la tension batterie.

Du coup en mesurant la tension de la batterie cela doit pouvoir se corriger assez facilement non ? Et c'est plus efficace énergiquement que de réguler cette alimentation à une valeur fixe

 

[syoctax]

En effet, cela revient quasiment à une modification des coefficients de manière proportionnel à la variation de la tension batterie.

Heu pas d'accord avec toi
Si on donne une consigne de vitesse, la commande en entrée du hacheur va automatiquement augmenter son rapport cyclique si la tension batterie diminue: c'est tout le principe d'un système bouclé.
Éventuellement la dynamique (ça se discute) va être affectée, et bien sûr la vitesse max; mais sinon pour moi le comportement devrait être identique.

 

[Goo]

En effet, cela revient quasiment à une modification des coefficients de manière proportionnel à la variation de la tension batterie.

Heu pas d'accord avec toi
Si on donne une consigne de vitesse, la commande en entrée du hacheur va automatiquement augmenter son rapport cyclique si la tension batterie diminue: c'est tout le principe d'un système bouclé.
Éventuellement la dynamique (ça se discute) va être affectée, et bien sûr la vitesse max; mais sinon pour moi le comportement devrait être identique.

Mea Culpa, je ne parlais pas d'un asservissement en vitesse, je n'ai qu'un asserv en position sur mon robot, les rampes de vitesses sont donc des "rampes de PWM", d'où ma remarque.
J'imagine que les équipes ayant des changements de comportements avec la tension de la batterie sont dans le même cas que le mien ^^.

 

[antoine_cvra]

En régime établi, oui tu auras l'asservissement qui corrige, mais en régime transitoire... j'ai des gros doutes là dessus.