Que sais je sur: Boucle d'asservissement, fréquences, Hz, µs

[Otatiaro]

Hello,

c'est un bk qui a cramé et quand je vois le post d'otatiaro j'ai l'impression qu'il ne connait pas cette marque !! car apparemment ce sont des servos chinois ( donc trés mauvais!!!) il vaut mieux en rire ...

Non je suis à l'écoute (d'ailleurs toute notre équipe est à l'écoute).
Par contre je n'ai jamais testé un servo BK de première main, mais les retours que j'ai eu ne sont pas terribles.

De plus, quand je vois un servo 760µs / 333Hz j'ai envie de pleurer .... pourquoi on a inventé les servos 760µs ? pour aller plus vite que 333Hz (560Hz en l'occurrence) ! Un 760/333 n'a absolument AUCUN intérêt technique.

Thomas.

Lien du message original Servo ac cramé suite au paramétrage du neuron

[mguw]

De plus, quand je vois un servo 760µs / 333Hz j'ai envie de pleurer .... pourquoi on a inventé les servos 760µs ? pour aller plus vite que 333Hz (560Hz en l'occurrence) ! Un 760/333 n'a absolument AUCUN intérêt technique.

Thomas.

Si quand même le Servo reçoit son ordre au bout de 760us au lieu 1520us ce qui fait presque une milliseconde de mieux en retard. Et ça, pour une boucle d'asservissement c'est primordial (pas pour vos pouces hein....)

Et 0.76 ms c'est pas négligeable même par rapport 560Hz = 1.9ms


A+ Marcel

[chris9200]

Que ce soit 760 ou 1520 ne change rien à fréquence égale

Si on met la fréquence a 50 hz.
Pour un 1520 On envoit une tension qui dure 1,5 ms toute les 20 ms pour qu'il soit au neutre

Pour un 760 on envoit la tension pendant 0,76 ms toute le 20 ms aussi. (50hz)

A 333hz. C'est toute les 3ms
Donc on atteint les limites d'un servo 1520. Pour être au neutre on a un signal
De 1,5 ms on et 1,5 ms off

Pour le servo 760. Le signal est 0,76 on et 2,24 off

L'avantage du 760 c'est qu'en divisant par deux la durée ON du signal on peut monter jusqu'à 560. Soit un ON off toute les 1,7 ms

J'espère que c'est compréhensible

Chris

[Joce]

Je ne vois pas comment l'asservissement peut changer à fréquence égale. La durée entre 2 fronts montants reste la même.

[my____]

Que ce soit 760 ou 1520 ne change rien à fréquence égale ... Chris

Merci des explications

[Leviatan]

Je ne vois pas comment l'asservissement peut changer à fréquence égale. La durée entre 2 fronts montants reste la même.

Il ne faut pas confondre asservissement et consigne ces deux notions sont distinct.

Quelques soit la frequence a laquel tu envois la consigne, l'asservissement du servo reste strictement la même, a une fréquence propre au servo.

Exemple bidon (pour ilustré) : le servo peut asservir a 1000Hz, c'est a dire qu'il corrige la position par rapport a la consigne 1000 fois par seconde, QUELQUE SOIT la fréquence a laquelle tu lui envoi cette consigne. (333Hz, 500Hz ou meme 50Hz)

Je ne suis pas d'accord avec ce que dit marcel (je vais me faire tapé la prochaine fois que je le vois - et je risque de me prendre un gros tir d'expliquation me contredisant et à raison) et je rejoin Otatiaro sur le manque d'intéré technique. Le seul intéret du 760ms est de pouvoir augmenté la frequence de l'envoi de la consigne.

J'en veux pour preuve que l'on sens bien que malgres les 50Hz de consigne, on sens que le servo asservis bien plus vite (sa gratte a plus de 50Hz) et MEME en ABSENCE de consigne, le servo gratte et conserve ca dernière consigne.

Marcel, me tape pas trop fort s'il te plait.

EDIT: Non je vien de comprendre !!!!!
Désolé, Otatiaro marcel a raison !!! La consigne arrive PLUS VITE a 760ms et donc l'asservissement commence plus tot qu'a 1520 !!! Ce qui fait gagné en précision, quelque soit la frequence, meme a 50 Hz !!

Mais ce que j'ai dit au dessus reste valable.
J'ai bon ?

[chris9200]

Je ne vois pas comment l'asservissement peut changer à fréquence égale. La durée entre 2 fronts montants reste la même.

EDIT: Non je vien de comprendre !!!!!
Désolé, Otatiaro marcel a raison !!! La consigne arrive PLUS VITE a 760ms et donc l'asservissement commence plus tot qu'a 1520 !!! Ce qui fait gagné en précision, quelque soit la frequence, meme a 50 Hz !!

Mais ce que j'ai dit au dessus reste valable.
J'ai bon ?

Le servo fonctionne en PWM donc il se positionne à chaque signal ON OFF donc Meme si tu prends la fin du On comme point de départ il faudra attendre la fin du ON suivant pour une nouvelle position , une position par période donc 50. 333. Ou 560. Fois pas seconde
1 position toute les 3ms pour du 333. Toute les 1,7 ms pour du 560

( ON étant la partie haute du signal carré et off la partie basse .)

On va y arrivée

Chris

[Otatiaro]

Oui je sais que le front descendant arrive environ 760µs plus tôt ... en moyenne (selon que l'on est au neutre, ou à une extrémité, le "gain" en latence est différent, ce qui n'est pas bon du tout en asservissement, puisqu'on a un temps de latence variable, on prend en compte la plus longue boucle possible).

Le gain de latence quand on augmente la fréquence est lui constant, donc un vrai avantage.

De plus, le signal PWM comme son nom l'indique se base sur le temps, or si on divise par deux le temps haut, on divise aussi par deux la précision (à horloge identique) de mesure de ce temps, donc la précision du servo.

Voilà pourquoi c'est bien l'augmentation de fréquence qui a imposé de diviser par deux le temps haut, et pas le contraire ... BK a pris les inconvénients et laissé de côté les avantages, c'est une façon comme une autre de mener son business.

Si on avait fait les choses bien, même en gardant de la PWM, on se servirait du duty cycle (temps haut par rapport au temps total d'un cycle) plutôt que de faire varier indépendamment fréquence et consigne avec les limitations que l'on connaît (un servo aurait simplement une fréquence maxi).

Thomas.

[Leviatan]

Si on avait fait les choses bien, même en gardant de la PWM, on se servirait du duty cycle (temps haut par rapport au temps total d'un cycle) plutôt que de faire varier indépendamment fréquence et consigne avec les limitations que l'on connaît (un servo aurait simplement une fréquence maxi).

Thomas.

Entièrement d'accord avec toi sur le duty cycle....

Tu le fait varier de 0 à 100%, équivalent a l'actuel 1000/2000ms.... Plus de perte de temps (1000ms)... Et comme tu le dit une frequence max. Actuellement le signal PWM n'est pas utiliser sur 100% de sa plage de cycle.

Oui je sais que le front descendant arrive environ 760µs plus tôt ... en moyenne (selon que l'on est au neutre, ou à une extrémité, le "gain" en latence est différent, ce qui n'est pas bon du tout en asservissement, puisqu'on a un temps de latence variable, on prend en compte la plus longue boucle possible).

J'ai du mal a comprendre en quoi une latence variable est un problème en asservissement. Tu calcules ta fréquence d'asservissement sur la latence la plus courte, et automatiquement la latence la plus longue sera correctement asservie....

On s'en fou que la consigne arrive a temps aléatoire, tant que le temps le plus court entre deux consigne est correctement traité c'est bon, d’où l’intérêt du 760...

Je n'essaie pas de te faire entendre raison mais j'essaie de comprendre, je suis loin d’être un spécialiste mais c'est un sujet qui me passionne.

EDIT: Ben non chris, meme si tas la meme période, tu gagne 760 (en moyene) d'asservicement d'avance sur la nouvelle consigne par rapport au 1520.

- Oui tu as le MEME TEMPS d’asservissement a 760 ou 1520 sur une même fréquence,
- Mais tu es PLUS PRECIS a 760, car tu COMMENCE ton asservissement plus tôt, la consigne passant plus rapidement (2x plus rapide )

[chris9200]

Bon on ne doit pas avoir les base sur le PWM et sur le fonctionnement d'un servo

Tu es en très de dire que par exemple sur un servo en 1520 quand tu envois une consigne pour te décaler de 90° donc 1 ms ton servo sera plus précis que si tu envoi la consigne pour te décaler de 90° dans l'autre sens donc 2ms
Vers le 0 précis vers le 180° 2 fois moins

Ça n' a rien à voir comme je l'ai dis , une position par période . On s'en fou que le ON dur 760. Ou 1520 il changera de position à la période suivante.

Fait des recherche sur le net tu trouvera des graphiques pour mieux comprendre

Chris

[Leviatan]

Je m'explique mal :

Quand je parle de précision, je veux dire que le servo commence a traiter la consigne un peu en avance ! Donc oui, la consigne est traité plus rapidement a 1ms qu'a 2ms. Précisément 1ms avant ! Je ne parle pas de la précision de la position du servo, mais de la vitesse a laquelle le servo interprète la consigne !

Quand je parle de précision, je prend en compte cette vitesse de traitement de consigne .

A partir du moment ou le module FBL envoi la consigne, si elle est traité 1ms apres envoi, ce sera 1ms plus précis que si elle est traiter a 2ms.

Donc si le ON dure 760 (de 500 a 1000), ben le servo agira sur la consigne 760us après que le module FBL l'ai envoyé, et non pas 1520us (de 1000 a 2000), donc le servo interprète a la consigne plus rapidement !

Et plus le servo repond rapidement a une consigne, plus il est "proche" des attente du module FBL.

[chris9200]

Je m'explique mal :

Quand je parle de précision, je veux dire que le servo commence a traiter la consigne un peu en avance ! Donc oui, la consigne est traité plus rapidement a 1ms qu'a 2ms. Précisément 1ms avant ! Je ne parle pas de la précision de la position du servo, mais de la vitesse a laquelle le servo interprète la consigne !

Quand je parle de précision, je prend en compte cette vitesse de traitement de consigne .

A partir du moment ou le module FBL envoi la consigne, si elle est traité 1ms apres envoi, ce sera 1ms plus précis que si elle est traiter a 2ms.

Donc si le ON dure 760 (de 500 a 1000), ben le servo agira sur la consigne 760us après que le module FBL l'ai envoyé, et non pas 1520us (de 1000 a 2000), donc le servo interprète a la consigne plus rapidement !

Et plus le servo repond rapidement a une consigne, plus il est "proche" des attente du module FBL.

J'ai très bien compris mais tu n'a pas lu se que j'ai écrit plus haut.
Exemple une consigne de neutre sur un 1520 et sur un 760 à une fréquence de 333 hz. La période dure 3ms
Ok Le 1520 va mettre 1,5 ms pour ce mettre en position et le 760 0,76 ms
Le 1520 va attendre 1,5 ms de off puis encore 1,5 ms de ON pour valider sa position
Le 760 va attendre 2,24 ms de off puis encore 0,76 de ON pour valider sa position

Donc je le répète à 333 Hz le servo reçoit un ordre toute les 3ms

Le gain du 760 et si tu as un ON a0,76. Et un OFF a 0,76 ms mais la c'est une période de 1,7 ms donc une fréquence de 560Hz


Voir définition de la fréquence , période

Chris

[Leviatan]

Le 1520 va attendre 1,5 ms de off puis encore 1,5 ms de ON pour valider sa position
Le 760 va attendre 2,24 ms de off puis encore 0,76 de ON pour valider sa position

Si si, j'ai tres bien lu, et je suis d'accord avec toi, d'ailleur je le dit aussi, ton temps d'asservicement est exactement le même a 1520 ou a 760 pour une meme fréquence.

Il auront tous les deux des periodes de 3ms a 333Hz oui, mais ce n'est pas ce que j'explique, un dessin vaux peut etre mieux qu'un long discours :


(on considère un ordre au neutre ici)

Le temps d’asservissement est donc le meme, je ne te contredit absolument pas la dessus, c'est la meme periode !
Mais le 760 va exécuter la consigne avec moins de latence que le 1520. L'ideal étant qu'il y ai 0 de latence.

La latence est de 500µs a 1000µs pour un servo 760, contre 1000µs a 2000µs sur un servo de 1520. Alors oui, je maintien que même a 50Hz, un servo 760 auras une meilleure réponse a la consigne qu'un servo 1520 (a condition qu'il ai les meme caractéristiques techniques, et meme asservissement bien sur).

[KoRn_BeeF]

pas tout à fait d'accord

en fait il y a juste un décalage d'origine

le servo ne peut interpreter l'ordre que sur le front descendant et regarde ta periode entre ces deux fronts sur les deux types elles sont exactement pareil puisque c'est la fréquence (à la modulation près sur un changement de consigne)

[Leviatan]

Tout a fait d'accord ! C'est ce que je dit aussi ! Je repette, le temps d'asservissement est exactement le meme ! Due a la periode. Et oui le servo interprette sur le front descendent.

(Oui tout a fait, selon la consigne la période "change", mais c'est négligeable car dans tous les cas la problematique est identique si l'on considere une meme suite de consignes pour le 760 et le 1520. On peu considéré un unique ordre au neutre pour facilité la comprehension.)

en fait il y a juste un décalage d'origine

C'est justement de ce décalage dont je parle !!! Et ce decalage, ben c'est la latence ! Le servo 1520 est decalé par rapport au 760. Le 760 execute dans le temps l'ordre avant le 1520.

C'est donc plus précis. (Quand je dit précis, je ne parle pas de la précision du servo en lui meme, mais de la précision de la boucle complète module/servo)

[KoRn_BeeF]

C'est justement de ce décalage dont je parle !!! Et ce decalage, ben c'est la latence ! Le servo 1520 est decalé par rapport au 760. Le 760 execute dans le temps l'ordre avant le 1520.

C'est donc plus précis. (Quand je dit précis, je ne parle pas de la précision du servo en lui meme, mais de la précision de la boucle complète module/servo)

il n'y a pas plus de précision dans l'un ou l'autre des cas sur la boucle d'asservissement
pour avoir un système stable, il faut que la logic de la boucle d'asservissement soit synchronisé avec le récepteur de consigne de sortie
donc pour avoir un système stable, il faut que la boucle soit calé sur la même fréquence que le servo
si nos servo sont en 200hz, la boucle de calcul doit être à 200hz sinon on rend le système instable

[mguw]

Merci leviathan

C'est toute la nuance entre fréquence et phase, c'est à dire délai.

Essayez d'asservir un ac à 560 Hz mais avec une ligne à retard de 20ms sur le fil du signal.... Ça sera pas mieux que du 50hz.

Moi dans mon boulot je fais des asservissement, et je peux te dire que j'optimise les calculs pour être au plus près du dernier échantillonnage et pas juste avant le suivant... Si cette optimisation permet d'augmenter la fréquence c'est tout bénef, mais si ta fréquence reste limitée par un autre facteur c'est quand même intéressant pour la marge de phase de ta boucle.

A+ Marcel

[mguw]

De plus, le signal PWM comme son nom l'indique se base sur le temps, or si on divise par deux le temps haut, on divise aussi par deux la précision (à horloge identique) de mesure de ce temps, donc la précision du servo.

Voilà pourquoi c'est bien l'augmentation de fréquence qui a imposé de diviser par deux le temps haut, et pas le contraire ... BK a pris les inconvénients et laissé de côté les avantages, c'est une façon comme une autre de mener son business.


Thomas.

D'accord seulement à moitié Thomas

Oui le PWM serait mieux que le PPM actuel, mais ce choix était historique pour les Servo analogiques avec des avantages certains à l'époque.

Par contre pas d'accord pour l'augmentation de la précision. Paradoxalement la précision n'est pas bénéfique aux asservissements car elle est justement synonyme de délai supplémentaire.
C'est une erreur assez commune en asservissements de vouloir filtrer le signal pour le rendre plus propre, mais le résultat est un retard de groupe préjudiciable à la dynamique de l'asservissement. En pratique il vaut mieux transmettre la pire merde mais le plus vite possible et c'est la bande passante (passe bas) de l'actuateur qui va faire le filtrage sans ajouter un retard additionnel.
La seule contre-indication à cela c'est une surconsommation de l'actuateur qui reçoit des ordres bruités, mais la dynamique de l'asservissement reste meilleure. La précision globale du système est pas impactée car le terme I est identique en cumulant du bruit ou en cumulant le même bruit filtré...

A+ Marcel

[KoRn_BeeF]

C'est une erreur assez commune en asservissements de vouloir filtrer le signal pour le rendre plus propre, mais le résultat est un retard de groupe préjudiciable à la dynamique de l'asservissement. En pratique il vaut mieux transmettre la pire merde mais le plus vite possible et c'est la bande passante (passe bas) de l'actuateur qui va faire le filtrage sans ajouter un retard additionnel.

complètement d'accord, d'ailleurs la plupart du temps on estime que c'est du bruit mais avons nous raison ?

[mguw]

Oui c'est du bruit, mais si il n'y a une petite part de réalité dedans elle sera utilisée au plus vite par l'actionneur. Si ce n'est pas bruité (pas de vibration, pas de parasites) c'est encore mieux

A+ Marcel

[Leviatan]

Haaa en tous cas j'etait pas fou !

Par contre je me suis rendu conte d'un truc, c'est que le lag supplementaire du 1520 par rapport au 760 est compensé par la une plus grande resolution de la commande :

Dans un microcontroleur, on va utilisé les sorties specifique PWM (il y a d'autre methode bien sur) pour controler notre servo :

On regle donc cette sortie a la frequence de refresh du servo : 50Hz, 330Hz .... Metons que notre sortie PWM a 12bits de resolutions et un duti cycle de 330 Hz. cela nous fait : 4096 different point sur TOUS le duti cycle. Sur les 3 ms de notre frequence, seul une partie est utile pour la commande servo :

- Servo 1520 : 1ms est utile pour controler notre servo. (1ms de UP, et entre 0 et 1 ms de UP et le reste DOWN)
1ms nous donne, dans ce contexte, 1369 point de resolution de controle de notre servomoteur.

- Servo 760: 0.5ms est utile pour controler notre servo. (0.5ms de UP, et entre 0 et 0.5 ms de UP et le reste DOWN)
0.5ms nous donne, dans ce contexte, 684 point de résolution de contrôle de notre servomoteur.

Nous avons donc moitié moins de résolution sur un 760 par rapport a un 1520, pour un même microcontrôleur, une meme frequence.
Dans cet exemple, cela montre que la chaine de regulation n'est qu'une histoire de compromis. Si le 760 nous fais gagné en rapidité (Baisse de la latance dans la boucle module FBL->Servos), il nous fais perdre en resolution (Resolution 2x plus petite). le tout est de savoir la quelle des deux solutions et la meilleur pour notre boucle d'asservissement FBL :
Une meilleur resolution du servo ? ou une plus petite latence ?

Attention, ce n'est pas le servo 1520 qui a meilleur résolution que le 760, mais la commande du microcontrôleur qui a une meilleur résolution.

Donc effectivement, Otario n'as pas entièrement tord quand il dit que le réel avantage du 760µs c'est de passer a 560Hz :
- Evidement on augmente le taux de commande par sec (premiere et plus evidente des idée)
- Moins evident mais sujet du debat ici : on reduit la latence en 760 et ça c'est cool
- encore moins evident : on concerve une resolution correct de notre microcontrôleur car un plus grand pourcentage du duti cycle est utilisé sur notre sortie PWM


PS d'apres ce que dit Marcel, il vaux mieux moins de resolution au profit d'une plus petite latence Donc meme a 333Hz le 760 et meilleur..

[KoRn_BeeF]

C'est ce que disait Thomas

De plus, le signal PWM comme son nom l'indique se base sur le temps, or si on divise par deux le temps haut, on divise aussi par deux la précision (à horloge identique) de mesure de ce temps, donc la précision du servo.

cette précision depend donc de la plus faible vitesse d'horloge entre l'émetteur et le récepteur du signal

pas la peine de tirer avec avec précision si la cible est tres grosse
ou de donner un Petrus à un alambique sur pattes

[Leviatan]

Oui tres juste.

ceci dit a cause du module FBL il faut vraiment faire la distinction entre les differents elements de notre boucle d'asservicement :

emetteur -> recepteur -> moduleFBL -> servos

Meme si "emetteur -> récepteur" et a 50Hz (la plupars des cas) il reste tres intéressent d'avoir du 333Hz sur les servos car en FBL ce qui prime c'est "moduleFBL -> servos" pour l’asservissement, "emetteur -> récepteur" n'ettant la que pour indiqué les taux de rotations & pas au module FBL

[KoRn_BeeF]

Après je vais faire un test :
si on envoi un seul créneau haut est ce que le servo bouge ?
ou alors il bouge a la réception du front montant du deuxième créneau haut ??
si c'est le deuxième cas, il n'y aurait aucune différence de latence entre un 760-333 et un 1520-333
ceci serait assez logique mais je vais m'amuser pour voir

[Leviatan]

je pencherais sur le cas 1....
J'en metrais presque ma mains a coupé : a 50Hz la latence serais tous bonnement horrible pour le module FBL dans le cas 2...

Rien a redire sur ta logique par contre !

Mais je testerais aussi, RDV ici pour le résultat

[KoRn_BeeF]

si c'est le cas 1 ça voudrait dire que l'on pourrait avoir une fréquence variable car il suffirait de mettre le signal a zero pendant seulement un minimum de 2 tours d'horloge du récepteur pour pouvoir renvoyer le créneau suivant
donc une fréquence variable et on pourrait exploser les 560hz facilement

[KoRn_BeeF]

Rien a redire sur ta logique par contre !

Mais je testerais aussi, RDV ici pour le résultat

on devrait faire du développement ensemble ça pourrait être intéressant

[Leviatan]

Oui SEULEMENT si le servo en est capable.

N'oubli pas qu'il y a un microcontrôleur sur le servo, et que c'est lui qui dicte la fréquence admissible ! C'est petit dans un servo, les microcontroleurs sont loin d'etre aussi puissant que dans un module FBL !

Et il est plus facile de codé en "Real Time" avec du PWM, donc une frequence fixé.

Mais dans l'idée tu as raison, il est possible de faire varié la frequence. Seulement voila, si le servo n'est pas assez rapide pour interprété tes 2 cycle d'orloge, il impose l'utilisation d'une frequence maximale, meme dans le cas 1.

on devrait faire du développement ensemble ça pourrait être intéressant

Oui carrément. J'ai plein de projet en cour (Tu les a vus sur ma page il me semble) et de l'aide est bien sure la bienvenue

[KoRn_BeeF]

C'est pour ça les 2 tours d'horloge du récepteur (le servo)

cool tes projets

[Leviatan]

Okok, oui vus comme ça sa devrais marché.....

Proof of concept en vue ça se teste aussi !

PS par contre tu "casses" encore plus la régularité d'envoi des commandes

[Otatiaro]

Pas eu le temps de tout lire, mais pour préciser sur la précision du servo en 760 :

Mettons qu'on veuille 1000 pas sur la plage d'un servo qui va de 1000 à 2000µs de consigne, il faut une horloge à 1MHz (1000 pas / 1000µs de plage).

Maintenant avec la même horloge, je passe sur un servo qui va de 500 à 1000µs de consigne (760µs), le nombre de pas sur la plage est de 500 ... donc je suis 2 fois moins précis.

Sachant que Shannon nous dit que pour être pas trop mal il faut être deux fois plus précis que le servo, qui est souvent en 11 ou 12 bits (2048 ou 4096 pas sur la plage), on commence à allez chercher des vitesses d'horloge de l'ordre de 10MHz ...

Quand on utilise un "gros" STM32 qui à une horloge de base à 84MHz, et des timer très réactifs, ce n'est pas un problème de doubler (ce qu'on fait sur le Neuron), mais quand on utilise un Atmel de base qui peine à sortir 16MHz à pleine vitesse, on perd de la précision.

Il y a plusieurs constantes de temps dans le système, notamment celle liée à la fréquence de calcul du PID, mais aussi la latence entre les données du capteur et l'actionneur final (la pale qui bouge et qui agit sur le vent), tout cela rentre en ligne de compte pour la qualité de l'asservissement.

Et intégrer de la merde, ca fera toujours de la merde intégrée ... là la fréquence d'échantillonnage joue beaucoup sur la précision.

Mais bon après je peux me tromper, c'est pas comme si je connaissait un peu le domaine en pratique ...

Thomas.

[Leviatan]

Pour la précisions c'est exactement ce que je disait.
Et c'est aussi clair que si tu implémente un PID avec 16MHz sur un système qui demande de la grosse fréquence échantillonnage ça deviens vite merdique. C'est du vécu sur un projecteur laser.

J'ai trouvé ! Le nouveau module a la mode sera mécanique, une sorte de tige sur laquelle on place des palettes et qui ferais grace a un effet gyroscopique bougé les pas de cyclique pour stabilisé hélicoptère ! On appellera ça la Barre de Bel !

[MaYeuT]

Ou barre de léviatan pour le coup

[Otatiaro]

Par contre qui a découpé le post dans un thread séparé avec un titre aussi idiot ?
Le sujet initial n'était pas du tout celui-là.

Thomas.

[my____]

Par contre qui a découpé le post dans un thread séparé avec un titre aussi idiot ?
Le sujet initial n'était pas du tout celui-là.

Thomas.

Thomas il a décidé de se faire plein d'ami aujourdh'ui

C'est juste que le post initial traité d'un problème en particulier et que vu la tournure que prenait le post un admin aussi idiot soit-il c'est dit que ce serait bien d'en faire profiter le plus grand nombre.

[Otatiaro]

Le sujet initial était de savoir quel intérêt pour un servo BK.

Je sais qu'une bonne partie de l'équipe d'administration de H4 ne peut pas me voir en peinture ... jusque là ca se passait bien mais si c'est pour essayer de me faire passer pour ce que je ne suis pas, je peux aussi ne plus faire de support pour les produits EZNOV sur H4.

A vous de voir, en fonction des modifications qui seront faites (ou pas) sur ce post, j'en déduirait les conclusions qui s'imposent.

Thomas.

[Leviatan]

Le sujet initial c'etait un probleme d'un servo qui a cramé sur le neuron. (Servo ac cramé suite au paramétrage du neuron, viewtopic.php?f=123&t=63160&start=40) Il a dérivé ensuite sur les servos, leur fonctionnement, les boucles d'asservissements, les latences, le mode de communication.

Le sujet initial portait sur le neuron, et un probleme servo. Cela ne me choque pas du tout qu'un modo soit venue partagé le sujet, et meme je trouve cela bien car je trouve ce sujet plus generaliste.

Preuve en est que je ne connais NI le neuron NI les servo BK et j'ai pourtant participé au sujet. Et je ne vois pas en quoi ce sujet aurais aidé le sujet précédent, 'Servo ac cramé suite au paramétrage du neuron'. Nous ne faisont QUE debattre sur le fonctionnement et non expliqué en quoi ça a pus cramé, ou quel reglage faire.

Je te dirais meme que je sentais des mes premieres participation que nous allions prendre un souflon d'un admin pour HS. Donc je ne pense pas du tous que tu sois la cause de ce partage.

Je trouve se sujet extremement intérréssant et je trouve que tu y apporte (tu es le concepteur du neuron il me semble ?) aussi je trouve dommage que tu le prenne comme ça.

Je precise que je ne connais les modos ni d'eve ni d'adam et que je me contre fou d'etre d'accord avec eux.

[Yoy24]

Yop)

Par contre qui a découpé le post dans un thread séparé avec un titre aussi idiot ?
Le sujet initial n'était pas du tout celui-là.

Thomas.

L'idiot c'est moi, et j'ai pas eu à forcer pour le demeurer...

C'est pas figé dans le marbre ce titre, et je suis bien-sur, ouvert à d'autres propals...

==> https://fr.wikipedia.org/wiki/Que_sais-je_%3F

Le sujet initial était de savoir quel intérêt pour un servo BK.

Je sais qu'une bonne partie de l'équipe d'administration de H4 ne peut pas me voir en peinture ...

Ben non pas moi, tu m'as rien fait perso,
py j'aime bien me faire l'avis des personnes qui m'entourent par moi même...

jusque là ca se passait bien mais si c'est pour essayer de me faire passer pour ce que je ne suis pas, je peux aussi ne plus faire de support pour les produits EZNOV sur H4.
A vous de voir, en fonction des modifications qui seront faites (ou pas) sur ce post, j'en déduirait les conclusions qui s'imposent.

Thomas.

Peux tu m'informer de ce qui te fait poster ça, j'ai pas du-tout suivi ce post,
donc je n'ai pas compris le cheminement qui t'as emmené à vouloir
prendre une décision aussi tranchée...

Je suis un poil perplexe là!

Bref j'ai pas compris...

Tu peux m'appeler si tu veux Thomas ou MP si tu le souhaites,
et réglons cela par le calme et une compréhension mutuelle du PB.

[my____]

@Otatiaro, il n'y a franchement pas d'attaque sur le fait de dissocier le sujet ... votre discussion très intéressante est partie sur des concepts qui mérite un sujet à elles seules.
Et je vois pas en quoi le sujet est idiot ? H4 est plutôt bien référencé Google et donc si quelques cherche à comprendre des choses sur cette thématique le titre est plutôt efficace, non ?
"Que sais je sur "c'est comme si il avait mis "l’asservisment pour les nuls" ... c'est pas un titre qui attaque pas les auteurs en les traitants de nuls, c'est pour attirer les nuls comme moi qui veulent piper quelque choses

[mguw]

Sachant que Shannon nous dit que pour être pas trop mal il faut être deux fois plus précis que le servo, qui est souvent en 11 ou 12 bits (2048 ou 4096 pas sur la plage), on commence à allez chercher des vitesses d'horloge de l'ordre de 10MHz ...
Mais bon après je peux me tromper, c'est pas comme si je connaissait un peu le domaine en pratique ...

Thomas.

heu non shannon dit qu'il faut etre 2x plus rapide et pas 2x plus precis, ce qui confirme d'une autre manière ce que je disais plus haut. il vaut mieux aller plus vite que etre plus precis dans le cas des asservissements.
d'ailleurs on peut toujours remoyenner apres coup pour récupérer la precision mais inversement on ne récupérera jamais la vitesse. Mais c'est justement ce moyennage qu'il ne faut surtout pas faire dans une boucle d'asservissement
A+
Marcel