J'ai bien envie de dire "à rien" mais ça serait faire du troll

J'aime bien tes réponses en ce moment JBot
Toujours d'accord avec toi XD


Sinon, j'ai validé le tuto
Merci julkien !



++
Black Templar

J'adore le concept ! Un robot-poisson parmi les vrai poisson, je trouve ça tellement cool ^^
D'ailleurs, quelles technologie est-ce que vous (l'entreprise) utilisez pour les déplacements du robot ?? ça doit particulièrement bien s'adapter aux algos génétiques ce genre de chose !

Bonne continuation !
Black Templar

Suite à ton expertise, je crois que l'on peut dire que le sujet est clos/résolu.
Comment fait on pour le marquer Clos / résolu?

Tu peux éditer le titre et rajouter le tag [résolu] devant

Bravo je viens de le refaire (ça me retarde dans mon usinage) mais c'est limpide. Merci bien.

Alors si on se contente du PI on obtient :
u(k)= u(k-1)+e(k)*[Kp + Ki.Te] -e(k-1)*[Kp]

Encore merci pour la leçon

Exactement,
D'ailleurs, si tu développes et que tu refactorises par les coefs, tu obtiens
u(k) =u(k-1) + Kp.(e(k) - e(k-1)) + Ki.e(k)
Ce qui est la forme récursive de u(k) = Kp.e(k) + Ki.somme(e)

Bref, c'est juste une question de point de vue. Il suffit de triturer les équations et de s’arrêter sur une forme qui te plait

Salut,

J'ai refais les calculs et je trouve bien la même chose.
Je t'invite d'ailleurs à les refaire par toi même. C'est un très bon exercice et ce n'est pas compliqué.

Je suis parti de la formule u = kp.e + ki.\integrale(e.dt) + kd.\derive(e/dt)
(La formule que j'ai exposé sur mon site, mais qui est un poil différente de la formule de départ de ton article puisque mon coef kp n'est pas en facteur.

Je discrétise avec Te, la période d'asservissement : u(k) = kp.e(k) + ki.Te.\somme{i de 0 à k}(e(i)) + kd.(e(k) - e(k-1))/Te
Pour discrétisé, j'ai remplacé

• \integrale(e.dt) par \somme{i de 0 à k}(e(i).Te)
• \derive(e/dt) par (e(k) - e(k-1))/Te

Remarque : kp = Kp ; ki.Te = Ki ; kd/Te = Kd ^^



Je fais calcule uk - u(k-1), je développe et je factorise par ek.
u(k) - u(k-1) = e(k).(kp + ki.Te + kd/Te) - e(k-1).(kp + 2kd/Te) + e(k-2).(kd/Te)


On a donc trois nouveau coef qui dépendent tous de Te.
La formule finale est donc u(k) = u(k-1) + K1.e(k) + K2.e(k-1) + K3.e(k-2)
Avec le coef K2 qui est négatif.


La question, c'est est-ce que l'on gagne quelque chose à faire ça ?
Dans cette formule u(k) = u(k-1) + K1.e(k) + K2.e(k-1) + K3.e(k-2)on doit :

• Mémoriser 3 coefficients
• Calculer une erreur et mémoriser les deux dernières
• Mémoriser la commande précédente

On a donc par boucle d'asservissement :

• 6 double en permanence en mémoire mémoire
• une soustraction/assignation pour calculer l'erreur
• 3 multiplications, 3 additions et une assignation pour mettre à jour la commande
• 2 assignations pour mémoriser les erreurs

Dans la formule de base u(k) = Kp.e(k) + Ki.Te.\somme{i de 0 à k}(e(i)) + Kd.(e(k) - e(k-1))/Te on doit

• Mémoriser 3 coefficients
• Calculer l'erreur et la mémoriser
• Mettre à jour la somme des erreurs et la mémoriser

On a donc par boucle d'asservissement

• 5 doubles en permanence en mémoire
• une soustraction/assignation pour calculer l'erreur
• une addition/assignation pour mettre à jour la somme
• 3 multiplications, deux additions et une soustraction pour calculer la commande
• une assignation pour mémoriser l'erreur

Avec la méthode du papier, on a

• un double en plus en mémoire
• une assignation en plus en mémoire
• une soustraction en moins !

Conclusion, c'est du pareil au même en fait

Mis à part qu'avec la méthode du papier, je ne vois pas trop comment régler le PID puisque les coef n'ont plus de sens "physique"
De plus, changer la fréquence d'échantillonnage demande de faire des calculs plus compliqué pour mettre à jour ces coef (ce n'est plus une simple multiplication/division !)

Ki.Te.e(k)?

Remarque : kp = Kp ; ki.Te = Ki ; kd/Te = Kd ^^

Te est caché dans le paramètre Ki

Un des derniers articles de Circuit Cellar (Rotational Inverted Pendulum Design) utilise un PID. Après en avoir donné sa forme analogique classique
u(t)=Kp e(t) + Ki Intégrale(e(t)) + Kp dérivée(e(t))
il en donne "a more digital form":
u(t)=u(t-1) + K1 E(t) + K2*E(t-1) + K3*E(t-2) avec E les erreurs et les coeffs K "are variables set similar to Kp,Ki,Kd".

Qu'en pensent ceux qui maîtrisent la théorie de la chose ?

Dans les réfs de l'article il y a les détails

Hello !

J'ai lu le papier en diagonale, mais il me semble qu'a certains endroit il y ai des coef \Delta t qui ne sont pas à leurs places. A part ça, le raisonnement est bon.
Je vais refaire les calculs pour mieux comprendre les avantages/inconvénients de cette méthode plupart dans la journée.

Mais déjà, une première remarque, c'est que maintenant, les 3 coef dépendent de la fréquence d'asservissement (contre 2 pour la formulation classique).

Par contre, la fin du papier m'a donner une idée : comme on fait un asservissement discret, il peut être intéressant de faire une transformée en Z sur la formule dans le domaine continu et voir ce que ça donne.

EDIT : j'ai utilisé le même procédé dans mon article sur le PI flou, mais je ne j'ai pas développé jusqu'au bout

Jolie

En régime établi, quand la vitesse de croisière est atteinte, l'erreur devient quasiment nulle mais il reste malgré tout une certaine oscillation lente (plusieurs secondes 3 à 5).
Peut être devrais je passer à 100ms ?

Je ne pense pas non. Passer à 100ms, pour 40RPM et 24ipt, ça te fais du 16 imp/s et donc entre 1 et 2 impulsions toutes les 100ms, ce qui est trop peu pour avoir un truc propre.
Pour le moment, avec 200ms, tu dois avoir environ 3 imp par boucle, ce qui n'est pas beaucoup, mais déjà un peu mieux.

Je te conseillerai de faire un test à 500ms pour voir (8imps). (attention, changer la fréquence d'asservissement implique de changer aussi le coefficient intégrateur ! (si tu double la fréquence, tu divise par 2 ton ki)

Bon on va dire que c'est une nouvelle façon de faire que je viens d'inventer : une révolution!

Certes, mais j'ai du mal à interpréter mathématiquement ce que tu as fais.
En gros, tu as : commande = kp.e + ki.somme(e) + consigne
commande = kp.(consigne-mesure) + ki.somme(consigne-mesure) + consigne
commande = kp.(consigne.(1+1/kp)-mesure) + ki.somme(e)

Ce qui veut dire que pour le proportionnelle, tu considères que ta consigne est plus grande que celle définie (dans ton cas 50% plus grande !).
Tu asservis donc non pas par rapport à la consigne, mais par rapport à consigne.(1+1/kp)
Donc, si on fait abstraction de l'intégrateur, si ta commande est à peu près bonne par rapport à la consigne, c'est que le kp est trop faible par rapport à consigne.(1+1/kp)
Ensuite, en rajoutant l'intégrateur, tu vas corriger l'erreur restante non pas par rapport à consigne.(1+1/kp), mais bien par rapport à la consigne.

Donc oui, ça marche, mais ça ne sert à rien.
Autant utiliser la vraie formule du PI : commande = kp.(consigne-mesure) + ki.somme(consigne-mesure)
Et de bien régler le kp du premier coup (dans ton cas, si tu n'ajoute pas le terme constant, ton coef kp devra être plus grand qu'à présent)

(pour t'en convaincre, essayer de faire un dessin en traçant le comportement de ta commande juste avec le terme proportionnel)

Au démarrage la vitesse est nulle,il y a accélération,mon problème est que je ne dispose que des impulsions sur les roues (24 par tour) ce qui est je pense trop peu et je ne pense pas pouvoir augmenter beaucoup car elles sont sur le PCF8574. Si je veux asservir toutes les 100ms, mon calcul de vitesse de roue sera trop imprécis.

Oui, le problème viens du fait que tu as ta codeuse sur la roue et non sur l'arbre moteur.
Asservir tous les 100ms, c'est pas très rapide, mais ce n'est pas déconnant non plus. Surtout qu'avec 24imp/tour, tu ne peux de toute façon pas asservir rapidement. (il vaut mieux asservir tous les 500ms pour avoir environ 12 impultions par boucle d'asservissement que tous les 50ms et n'avoir qu'une seule impulsion, par fois deux)

Perso, j'ai l'habitude d'asservir mes moteurs de robots à 50hz, quand la codeuse est sur l'arbre moteur. Je ne constate pas de gain à le faire plus vite.
Alors dans ton cas, asservir tous les 200ms à 500ms en vitesse devrait être suffisant. Tu ne seras certes pas très précis, mais c'est à cause de la codeuse sur la roue. Et puis une tondeuse doit-elle être précis au cm ?

Par contre, oui, je maintient qu'un asservissement supplémentaire en angle pourrait t'assurer d'aller tout droit. ça rectifierai au moins les erreurs du à l'accélération de tes moteurs (qui n'accélèrent peut être pas de la même manière)

Je me suis donc rabattu sur les integers en procédant par essais multiples (beaucoup). Mais honnêtement le résultat est pas mauvais; l'erreur est maintenue à moins de 3 impulsions.

Si le résultat final est bon, tant mieux.
Sinon, tu peux mettre l'intégrateur à 0 et régler le proportionnel afin d'avoir une erreur statique environ égal à 5% de la consigne.
Une fois le kp déterminé, tu règles le ki pour annuler l'erreur statique en un temps raisonnable.

La "constante" n'est pas une constante mais la consigne de vitesse (croissante pendant l'accélération) c'est vrai que ça parait bizarre ...

Hum... Normalement, tu n'as bas besoin d'ajouté cette consigne car elle apparait implicitement dans le calcul de l'erreur.

erreur = consigne - mesure
somme_erreur += erreur

Cette erreur (signée) est traitée en PI avec KP=2 et KI=1 (pour l'erreur cumulée).

Hum... à première vue, si tu ne travailles qu'avec des entiers, 2 pour Kp et 1 pour Ki ne ssemble pas très précis. Quel a été ta démarche pour les déterminer ?
(Pourquoi ne pas utiliser les float (même si ça consomme plus de CPU)

A l'ensemble j'ajoute la valeur grossière nécessaire (c'est là que je ne comprends pas tout Help BT). Mais le résultat est correct.

/> c'est à dire ?
Tu fais un truc du genre
commande = Kp*erreur + Ki*somme_erreur + constante ?

Dans ce cas, c'est que tes coef sont mal réglés car la constante est inutiles.

Salut hmnrobots !

Normalement, chaque roue possède un asservissement en vitesse. Ainsi, tu es sur que chaque roue tourne bien à la vitesse de consigne.
C'est l'asservissement de base.

Par dessus ça, tu peux asservir ton robot en angle. A l'aide des codeuses, tu peux obtenir la position du robot et son orientation.
Tu calcules donc l'orientation et tu asservie par rapport à une consigne. Le résultat de cette asservissement sera les vitesses de tes roues (qui elle-même sont soumises à l'asservissement en vitesse)

Ainsi, ton robot rectifiera sa trajectoire pour aller toujours tout droit.


++
Black Templar

envoi une photo (redimensionné) du branchement

Salut et bienvenue à toi

pour ensuite m'orienter vers la musique par ordinateur (m.a.o) je me suis rendu compte qu'en fait ce qui me plaisait c'était surtout le support et non les programmes que j'utilisaient !

Génial Tu utilises quoi comme logiciel ? J'ai essayé de m'y mettre, mais impossible de prendre en main cubase... Et tout ce qui est fruitloops et compagnie est trop électro à mon gout....
Ce que je cherche à faire, c'est composer dans un style classique. (j'ai un clavier midi et j'aimerai bien m'en servir pour ne pas tout écrire à la main... ce qui est long et fastidieux !)

je précise parce que je pense que le réseau est assez "bas" (proche de la machine) comparé au C/C++ par exemple.

Pas tout à fait d'accord avec ça
En réseau, tu as justement plein de niveau ! du niveau bas hardware au niveau logiciel qui peut être très abstrait.
Tu définie des protocoles TPC/UDP pour la coucle transport, HTTP/FTP & co. pour la couche applicative. Tout ça est très abstrait et pour tout comprendre au niveau matériel, il faut regarder l'ensemble du modèle OSI dans on intégralité.
Le C, c'est aussi bas niveau, car tu manipules la mémoire, si tu codes sur les microcontroleurs, tu as accès aux registres, etc. Perso, quand je code en C, j'ai, dans ma tête, la représentation de la mémoire, du tas, de la pile, etc. (alors qu'en java, je ne marche pas du tout de la même façon !)

(J'ai essentiellement appris le C/C++ sur : www.lesiteduzero.com et le réseau sur backtrack-fr pour ceux que cela intéresse! Ce sont des sites très complets c'est toujours bon de les mentionner.)

Héhé batrack, c'est cool

les réseaux neuronaux artificiels aussi m'intriguent énormément

Héhé, si tu as des questions, n'hésites pas !

N'ayant aucune connaissance sur l'IA ni l'algorithmie liée à l'Ia ( ), auriez vous des tutoriels, livres, documentations, à me conseiller ? Par oµ débuter, par exemple.

Dès que j'ai découvert la programmation, mon objectif à toujours été de faire de l'IA. Pour ça, j'ai commencé par faire de l'algorithmique pendant plusieurs années. Au fur et à mesure que tu acquiert des connaissances en algo, tu arrive toujours à complexifier tes problèmes et finalement, tu arriveras automatiquement à l'IA.
Mes premiers algos d'IA, étaient basés sur des algos génétiques, évolutionnistes ou réseaux de neurones. Tout ce qui permet de faire de l'apprentissage. Mais je me suis vite rendu compte que ce n'est qu'un tout petit pan du domaine de l'IA !!!
Tu as tout ce qui est langage naturelle, contraintes et logique, système multi-agents (mon domaine à moi ^^) et un tas d'autre ! Donc, il y a le choix. Mais à mon avis, c'est en commençant par faire de l'algo à tour de bras que tu découvriras par toi même l'IA.



++
Black Templar

Je travaille sur un odometre "virtuel" : suivant le temps d'activité d'un moteur, j'estime le nombre de "tour" effectué.
Avec les deux moteurs, ca me permet de savoir dans quelle direction et sur quelle distance va mon tank.

Arrrrg... crise cardiaque
En gros, tu travailles en boucle ouverte totale ! Si ton robot est sur une pente ascendante ou descendent, pour la même puissance consomé par le moteur, celui-ci tournera plus ou moins vite :/
Tout ce que tu peux avoir avec cette méthode, c'est une estimation grossière et erroné de la position de ton robot sur du court terme uniquement...

Il vaut mieux mesurer le nombre de tour de roues réellement avec un odomètre fixé sur l'arbre moteur (avant le réducteur pour plus de précision)

Ah pile poil ce qu'il me faut, je n'y ai pas penser
Mais, heu... question bête : la puissance des 5 piles de 1.5v ne risque pas d'endommager les résistances (je n'ai que des 1/4 watts en stock) ?

Et bien il suffit de dimensionner ton pont diviseur de tension pour ne pas que la puissance soit trop élevé !!

P = U.I
I = U/R
R = R1+R2

Le tour est joué

Salut !

Heu, en fait, je cherchais une solution "temporaire"... car je comptais me servir de l'accelerometre du telephone mobile pour estimer les distances et directions parcourus... mais dans l'application "RemoteRobot", le mobile n'est pas (encore) solidaire du robot
Et je viens de voir que les moteurs/reducteurs dans le chassis DFRobot 4AWD ne peuvent pas recevoir d'encodeur...
J'ai vu un accelerometre a 15€, est-ce que ca sera plus fiable que la "boucle ouverte totale" ?

Le problème de l'accéléromètre, c'est que ça te donne une accélération. Pour obtenir une position, il te faut intégrer 2 fois. Ce qui implique donc une dérive très forte... A mon avis, (je n'ai pas encore testé), ça me semble dur d'obtenir des résultats précis sur le long terme... mais à tester, il se peut que l'on soit surpris par les performances (si tu prend une fréquence d'échantillonnage suffisamment élevé...)

++
Black Templar

Jolies résultats !
Merci d'avoir partagé tes sources

Beau résultat !

Et finir l'odomètre basé sur le temps d'activité des moteurs de propulsion (malheureusement pas très précis car dépendant de l'énergie disponible des piles).

Que veux tu dire par là ?? Un odomètre te permet de compter le nombre de tours de roue. Où vient faire le niveau de batterie là dedans ??

J'en profite pour demander si quelqu'un sait comment faire pour connaitre le niveau des piles a partir de la carte DFRobot Romeo.

Au plus simple : un pont diviseur de tension de ta batterie pour avoir au maximum du 5V en sortie. Cette sortie, tu la plug sur une pin analogique de l'arduino et tu mesures la tension.
Si tu as une batterie délivrant 1V chargé au max, tu fais un pont diviseur pour avoir du 5V en sortie. En cours d'utilisation, si tu mesure 4V, ça veut dire que la batterie est à 9.6V par exemple

Ou si il y a un montage facile a faire pour avoir le status de l'énergie disponible.
J'envisage de passer sur une batterie type "modélisme" ou batterie de téléphone portable à la place des 5 piles de 1.5v.
Est-ce qu'il est préférable de garder les piles pour l'alimentation des moteurs et un batterie pour les servos et la carte contrôleur ? ou trois batteries ?

Et je suis preneur pour un odomètre par cher (il ne me reste que 3 pins analogiques ou le port I2C), si vous avez des idées (soit un truc tout fait, soit à bricoler).

Aucune idée,

++
Black Templar

rbot, tu n'as pas pris en compte mon premier avertissement !
Si ça continue, je me verrai obligé de prendre des mesures plus sévères !

Black Templar

Les batteries au Lithium Li-Po sont bien connue pour leurs instabilités. Si tu les recharge trop fortement ou avec un chargeur pas adapté, elles peuvent explosées :/

Impressionnant ! Je viens de lire quelques articles de ton blog, c'est vraiment un travail colossale que vous avez abattu là !
C'est quand la deadline pour le concours ?

Lawl !
Okok ! j'ai cru que tu l'avais fait en équipe (à cause de la "Team composition" dans la rubrique "About" ;) )

Waaa !! Tu vas avoir un LIDAR !! C'est trop cool ! ça coute la peau du cul ce truc là !

Félicitation pour les performances de Maximus ! :)

Waaaa !! des nuits blanches en perspectives ?? ^^
Bon courage !!!