Aller au contenu


Photo
- - - - -

Projet robot d'exploration ROBERT


39 réponses à ce sujet

#21 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 26 mars 2010 - 05:38

J'ai eu le temps aujourd'hui de faire une petite vidéo : video youtube
Désolé pour le format vidéo qui est pas génial mais j'ai pas d'APN digne de ce nom sous la main.

L'évitement d'obstacle marche plutôt bien sauf dans certain cas comme les angles morts entre 2 capteurs, ou les angles bien fins.
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#22 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 26 mars 2010 - 06:14

Super, c'est bon début. Il ressemble quand même bien à mon BOB3.

Si j'ai bien compris, pour l'instant, tu n'utilses que l'Arduino, et tu n'as pas encore monté la Roboard, ni le retour des codeurs... C'est bien ça?

Leon.

BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#23 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 26 mars 2010 - 06:30

Merci :)
Oui c'est vrai que sa ressemble beaucoup, normal Léon ton BOB3 est ma source d'inspirations :)

C'est tout a fait ça. La roboard ne sera montée qu'après que tout l'asservissement "simple" soit fonctionnel. J'ai une toute première version "beta" de la carte à cpld pour le décodage des signaux en quadrature qu'il faut que je teste branchée à l'arduino. ça devrait donc pas tarder à avancer si je suis pas trop mauvais pour calculer et coder mon PID.
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#24 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 19 juin 2010 - 11:56

Salut à tous,

maintenant que j'ai un peu plus de temps pour travailler sur le robot, j'ai pu finir avec un ami la carte à CPLD qui sert à décoder et à compter les informations des codeurs optiques. J'ai mis en place un asservissement tout simple en théta-alpha (asservissement polaire). étant donné que c'est la première fois que je me lance dans la pratique pour un asservissement (en dehors des cours mais c'est là qu'on s'aperçoit que quand on fait marcher une manip toute faite et en étant guidé cela n'a rien à voir avec le faire "en vrai") je me heurte fatalement à des petit problèmes. J'ai donc quelques petites questions pour ceux qui passerons dans le coin :

- Dans le principe mon asservissement fonctionne (plus ou moins il faut régler les coefs) mais assez régulièrement (et je ne sais pas pourquoi) je fait des lectures fausse de valeurs. Du coup quand j'ai une consigne de 30tick / dT par exemple de temps en temps je me retrouve avec une valeur -1500 ou 400. Comme vous pouvez vous en douter sa donne des à-coups sur la commande et sa fausse complètement le positionnement. Est ce que certains d'entre vous ont déjà été confrontés à ce problème là ? je pensais filtrer les mesures mais après c'est génant dans le fait où je suis limité en dynamique du système, même si dans l'absolu mon robot n'a pas besoin d'être très dynamique. Je me demandais si cela venait pas des moteurs qui perturbent la lecture à certain moments, parce que dans le doute j'ai incriminé la carte à CPLD. Comme il y a un registre qui me permet de commander des pattes en sortie du CPLD j'ai fait un programme qui réalise en boucle des cycles de lecture écriture avec des valeurs différentes. Et résultat du test : aucune erreur sur des millions de lectures / écritures. Je me suis aussi aperçu qu'il y avait moins d'erreurs de lecture quand je faisait une première lecture bidon puis les "vraies" lectures ensuite. (Il faut encore que je fasse d'autres tests de lecture sur le CPLD dans des conditions différentes, je crois que c'est trop sensibles ces bestioles là)
J'utilise pour l'instant un quartz 50mhz pour toute la partie synchrone du CPLD mais je pense diminuer un peu pour limiter les problème (vers 20/30Mhz). Autre chose que j'ai failli oublier mon CPLD est alimenté en 3.3V (5V compliant sur les entrées) et je me demandais si ça pouvais jouer sur les erreurs de lecture par le uC (même si en théorie le seuil logique est à 2V équelques il me semble pour du 5V)

- Par la liaison série de l'arduino je renvoie les valeurs de mes codeurs et les valeurs des commandes générées par les PID. J'affiche ensuite tout ça avec matlab. C'est là qu'on se rend compte que la moteur gauche est très bien positionné par rapport à sa consigne (sans tenir compte des erreurs de lecture) alors que le moteur droit oscille autour de sa consigne. Comme l'asservissement est effectué sur les deux moteurs à la fois et non sur chaque moteur séparément je me demandais si c'était vraiment normal. Je joint deux captures d'écran Matlab : la première montre un essais de consigne de 90°/s sur 3s, la deuxième montre la même chose mais avec une lecture bidon effectuée avant les vraies lectures.
Légende : pour les odomètres courbe bleue = valeur lue, rouge = consigne.
Pour les les commandes courbe rouge = commande brute calculée par les PID, en bleu la même commande seuillée entre 255 et -255 (255 pas de PWM avec avant ou arrière).
Le delta de temps est de 1/61s (calcul des PID à 61Hz). Les unités des courbes de odomètres sont en ticks sur l'axe Y et en secondes sur l'axe X. Pour les courbes des commandes sur Y il n'y a pas d'unité ce sont des "pas de PWM" et sur X toujours le temps en secondes.

Image(s) jointe(s)

  • essai1.png
  • essai2.png

Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#25 Electron

Electron

    Pilier du forum

  • Membres
  • PipPipPipPip
  • 906 messages
  • Gender:Male
  • Location:LABEGE
  • Interests:Électronique, robotique ludique, programmation de jeux et utilitaires, et plein d'autres choses.

Posté 19 juin 2010 - 01:55

Salut Inounx, je ne connais pas bien le matériel que vous utilisez, mais je sais une chose sûre c'est qu'il vaut mieux alimenter en 5V la TTL qu'en 3,3V pour être certain de ne pas avoir d'erreurs ;)
Ils ont été étudiés pour le 5V ;)

Si tu as des broches non utilisées sur ton TTL elles seront au niveau Haut par défaut (technologie TTL) donc je te dis ça au cas où ;)

Essaie aussi de cabler un condo de 22 nF au plus prés du circuit TTL entre le +VCC et la masse, car de fortes fluctuations peuvent se produire là lors des changements d'états du circuit TTL surtout si tu utilise 3,3V en VCC.

"Plus on partage, plus on possède, voilà le miracle". LEONARD NIMOY
"Celui qui se bat peut perdre, celui qui ne se bat pas a déjà tout perdu". BERTOLT BRECHT (1898-1956)
Comment se lancer dans la robotique !
Mince encore un post pour augmenter mon compteur ;)


#26 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 19 juin 2010 - 03:29

Salut Inounx, je ne connais pas bien le matériel que vous utilisez, mais je sais une chose sûre c'est qu'il vaut mieux alimenter en 5V la TTL qu'en 3,3V pour être certain de ne pas avoir d'erreurs ;)
Ils ont été étudiés pour le 5V ;)

Si tu as des broches non utilisées sur ton TTL elles seront au niveau Haut par défaut (technologie TTL) donc je te dis ça au cas où ;)

Essaie aussi de cabler un condo de 22 nF au plus prés du circuit TTL entre le +VCC et la masse, car de fortes fluctuations peuvent se produire là lors des changements d'états du circuit TTL surtout si tu utilise 3,3V en VCC.


Salut Electron,

je me suis peu être mal exprimé, mais le CPLD que j'utilise (Xylinx XC95144) est uniquement en 3.3V. Je suis donc obligé de l'alimenter au maximum avec 3.3V et comme tout le reste de l'électronique de commande est en 5V pour la liaison avec l'atmel de l'arduino je suis obligé de mixer les 2. Coté condo toutes les cartes électroniques que j'utilise ont des condensateurs de découplage donc pas de souci de ce coté là.
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#27 Electron

Electron

    Pilier du forum

  • Membres
  • PipPipPipPip
  • 906 messages
  • Gender:Male
  • Location:LABEGE
  • Interests:Électronique, robotique ludique, programmation de jeux et utilitaires, et plein d'autres choses.

Posté 19 juin 2010 - 10:46

OK ;)
Sinon je viens de voir le datasheet et ils disent qu'il peut aussi s'alimenter en 5 V alors n'hésite pas ;)

Datasheet

"Plus on partage, plus on possède, voilà le miracle". LEONARD NIMOY
"Celui qui se bat peut perdre, celui qui ne se bat pas a déjà tout perdu". BERTOLT BRECHT (1898-1956)
Comment se lancer dans la robotique !
Mince encore un post pour augmenter mon compteur ;)


#28 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 19 juin 2010 - 11:48

OK ;)
Sinon je viens de voir le datasheet et ils disent qu'il peut aussi s'alimenter en 5 V alors n'hésite pas ;)

Datasheet


c'est que tu m'as fait douter pendant un instant ^^ . Comme c'est pas moi qui ait réalisé cette carte j'ai pas fait gaffe mais je viens de regarder : le cpld est un XC95144XL (arf) et bien sur devine quoi ? XL sa veux dire tout plein truc performants... dont le 3.3V.
Les entrées sorties sont 5V compliant mais on ne peut l'alimenter qu'en 4v max.
La datasheet c'est par ici
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#29 Electron

Electron

    Pilier du forum

  • Membres
  • PipPipPipPip
  • 906 messages
  • Gender:Male
  • Location:LABEGE
  • Interests:Électronique, robotique ludique, programmation de jeux et utilitaires, et plein d'autres choses.

Posté 20 juin 2010 - 01:18

Ha oui je viens de voir en suivant ton lien que c'est le "144XL" qui est spécifiquement en 3,3 V.
Bon bein c'est bien de douter un peu des fois, comme ça on vérifie ce qu'on fait ;)

Je n'ai jamais encore fait de contrôle PID (je sais ce que c'est et comment ça fonctionne), donc tu pourrais m'expliquer ce que tu veux dire par cette phrase ?

Comme l'asservissement est effectué sur les deux moteurs à la fois et non sur chaque moteur séparément


"Plus on partage, plus on possède, voilà le miracle". LEONARD NIMOY
"Celui qui se bat peut perdre, celui qui ne se bat pas a déjà tout perdu". BERTOLT BRECHT (1898-1956)
Comment se lancer dans la robotique !
Mince encore un post pour augmenter mon compteur ;)


#30 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 20 juin 2010 - 09:08

En gros au lieu de dire je fait un PID pour le moteur gauche, et un PID pour le moteur droit, je viens asservir deux moteurs virtuels, un moteur qui fait avancer le robot dans l'axe de son orientation, et un autre moteur qui fait tourner le robot. C'est un asservissement polaire, ou en theta- alpha, avec theta distance et alpha angle. Comme ces deux moteurs sont des moteurs virtuels il y a un petit calcul permettant de redispatcher la commande d'un moteur virtuel sur les deux moteurs réels. Chaque moteur indépendamment n'est pas asservi mais ce sont ces moteurs virtuels qui le sont. C'est beaucoup plus intuitif à commander que chaque roue, mais ça a l'inconvénient d'être un peu moins précis. Pour palier à ce problème, ce qu'on voit pas mal sur les robots de coupe, ce sont 4 encodeurs, 2 par moteurs donc, 1 fixé sur l'arbre moteur qui sert à réaliser un PID sur ce moteur et un en roue libre qui touche le sol aligné avec l'axe moteur pour mesurer l'avancement "réel" et c'est avec ces codeurs là que l'asservissement polaire est réalisé. Cela permet d'avoir de la précision sur le controle des moteurs tout en les contrôlant en distance et angle. J'espère que j'ai pu t'éclairer un peu :)
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#31 Electron

Electron

    Pilier du forum

  • Membres
  • PipPipPipPip
  • 906 messages
  • Gender:Male
  • Location:LABEGE
  • Interests:Électronique, robotique ludique, programmation de jeux et utilitaires, et plein d'autres choses.

Posté 20 juin 2010 - 11:10

Merci j'aurais appris que le PID virtuel existe ;)
Je constate que je ne te serais d'aucun secours pour tes erreurs aléatoires de lecture :/
Bizarre quand même que ces erreurs n'existent pas lorsque tu utilise un programme de test en boucle, ça veut dire que ces erreurs n'existent que lors de leur lecture réelle et donc que le système de lecture entraine la venue de ces erreurs.
Le circuit de lecture n'est-il pas sensible à quelques parasites ? est-il bien cablé de la meilleure façon ? voilà j'essaie d'orienter un peu les recherches ;)

"Plus on partage, plus on possède, voilà le miracle". LEONARD NIMOY
"Celui qui se bat peut perdre, celui qui ne se bat pas a déjà tout perdu". BERTOLT BRECHT (1898-1956)
Comment se lancer dans la robotique !
Mince encore un post pour augmenter mon compteur ;)


#32 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 21 juin 2010 - 08:48

Merci j'aurais appris que le PID virtuel existe ;)
Je constate que je ne te serais d'aucun secours pour tes erreurs aléatoires de lecture :/
Bizarre quand même que ces erreurs n'existent pas lorsque tu utilise un programme de test en boucle, ça veut dire que ces erreurs n'existent que lors de leur lecture réelle et donc que le système de lecture entraine la venue de ces erreurs.
Le circuit de lecture n'est-il pas sensible à quelques parasites ? est-il bien cablé de la meilleure façon ? voilà j'essaie d'orienter un peu les recherches ;)


C'est toujours bien d'avoir un point de vue différent, ça permet souvent de progresser ^^
J'avais fait des tests de cette carte CPLD quand le CPLD était cadencé à 24mhz et meme avec les moteurs qui tournaient pendant le prog de test en boucle j'avais pas d'erreur non plus. Depuis j'ai passé le CPLD à 50Mhz pour pouvoir augmenter la vitesse de transmission des données (et pour qu'il puisse suivre la cadence de l'arduino@16Mhz) mais c'est peut être ça qui le perturbe. Il faut dire aussi qu'un CPLD c'est hyper sensible par nature, alors le 3.3V et du 50Mhz sa doit pas plaider en ma faveur... Je vais essayer de faire des tests sur la lecture des codeurs directement plutot que sur le registre que j'ai à coté. Si je désactive ma remise à zéro automatique des compteurs, sans faire bouger les codeurs, je peux réaliser pleins de lectures de la meme valeur et voir si il y a des fausses lectures.
Pour ce qui est du cablage, peut être pas de la meileure façon qui soit mais tout mes fils sont torsadés pour réduire les parasites, mon alim est filtrée et chaque carte a des condensateurs de découplage. Les fils sont les plus courts possibles. La liaison avec l'arduino se fait avec un cable de 10 cm de long composé de 3 fils torsadés, sa devrait marcher nickel.

Je vais essayer de faire quelques tests de plus, mais si il y en a qui passent par là et qui ont des idées je prends toujours ^^(pas que pour le problème des erreurs de lecture, mais aussi pour l'oscillation sur la voie droite)
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#33 psykokwak

psykokwak

    Nouveau membre

  • Membres
  • 27 messages
  • Gender:Male
  • Location:Paris
  • Interests:Robotique

Posté 22 juin 2010 - 08:20

Salut Marc.
Je vois que tu as appliqué mes conseils sur l'asservissement polaire ;)

PS: Pourrai tu essayer de nous joindre (jabber/mail/téléphone), nous avons quelques questions sur ton travail à Gostai...

#34 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 01 août 2010 - 10:31

Voici quelques news du petit Robert :) je n'ai pas trop le temps de m'en occuper en ce moment avec mon stage et mon rapport à finir mais j'essaye de m'y tenir.

Coté odométrie le problème est réglé, cela venais du fait que les entrées des capteurs sur le CPLD n'étaient pas synchrones avec l'horloge du CPLD ( 50Mhz), je pense que vu que c'est un composant hyper sensible avec les moteurs en marche il devait "attraper" tout les parasites qui trainaient, d'où les fausses valeurs.

J'ai essayé de mettre en place des PID sur chaque moteur, un à gauche et un à droite ça fonctionne nickel. Pour l'asservissement delta - alpha c'est pas encore ça par contre, j'ai du mal à bien régler les coefficients. J'ai aussi essayé de mettre les PID delta et alpha commandant les PID droite et gauche, je ne sais pas si cela vient du fait que la boucle d'asservissement est faite sur le même retour capteur mais le système devient très rapidement instable (oscillations dans les plages de régime permanent).

En plus c'est vrai que devoir reprogrammer l'arduino à chaque fois que je fait un changement de coeff c'est vraiment pas pratique. J'évite de faire des saisies console, les fscanf (et aussi les fprintf) sa prend 3 tonnes de place dans la mémoire et les 16ko de l'atmega168 se remplissent vite. J'ai donc décidé de prendre un peu d'avance sur ce que j'avais prévu de faire. J'ai rajouté la roboard sur le robot afin de pouvoir commander l'arduino via la connexion série.

Le protocole de communication que j'utilise est simple : on envoi un premier caractère de début de trame (j'ai choisi 0x80, mais peut être n'importe quoi d'autre) ensuite on envoi la taille de la trame sans compter les caractères de début et fin de trame. En suivant un code 8 bits est envoyé représentant l'ID de la commande (pourra être étendu à 16 bits si 255 commandes ne suffisent pas) suivent ensuite tout les octets de la commande et pour finir le caractère de fin de trame (0x90). La longueur de la trame permet d'effectuer une vérification sur la trame et évite de confondre le caractère de fin avec un octet de donnée. Ce qui donne en résumé :
START - LENGTH - ID - D1 - D2 - ... - Dn - STOP

Les commandes permettront donc de commander entièrement le bas niveau du robot (les PID, les commandes moteurs brutes, les capteurs, etc). tout le mécanisme de réception et déserialisation des commande est codé sur l'arduino mais pas encore testé. J'ai remis en marche la roboard et je me suis débattu quelques temps afin de faire fonctionner correctement le wifi. J'arrive à me connecter à mon routeur wifi pour l'instant ce qui me suffit même si à terme l'intéret serais de se connecter à un réseau connu si existant ou sinon créer un réseau ad-hoc. Il me reste encore à coder une petite application permettant d'envoyer des commande à l'arduino, ce qui va simplifier la mise au point de l'asservissement. Le but est de soit faire une application avec socket pour communiquer à travers le réseau et donc commander le robot à distance, soit faire une page web avec un script CGI. Je n'ai pas encore choisi ce que j'implémenterai même si il y a des chances que je fasse les deux.

J'avais aussi mis en place tout un système de TTS (Text To Speech) pour le faire parler, ce qui pourrait être marrant, mais je ne me rappelle plus comment je l'utilisais :( je vais essayer de retrouver ça.

Image(s) jointe(s)

  • IMG_0106.JPG

Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#35 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 03 août 2010 - 09:47

Si j'ai bien compris, tu as essayé de bidouiller des asservissements PID imbriqués.

Premièrement, ça n'est pas indispensable: tu peux utiliser directement un asservissement "avancement/angle" (que tu appelles delta alpha), qui commande directement les moteurs. C'est en général ce que font les roboticiens.

Ensuite, si tu veux vraiment faire des asservissements imbriqués, il faut que le temps de convergence de l'asservissement "bas niveau" (ici le PID sur l'avancement des roues) soit très faible par rapport aux constantes de temps de ton asservissement "haut niveau". Sinon, tu peux très bien avoir des phénomènes de divergence.

On utilise des asservissements imbriqués en général quand il y a vraiment des phénomènes physiques imbriqués.

Leon.

BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#36 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 03 août 2010 - 11:27

Si j'ai bien compris, tu as essayé de bidouiller des asservissements PID imbriqués.


C'est tout a fait ça oui. Comme j'ai vu que certains robots de coupe de france utilisaient cette technique je me suis dit "Pourquoi pas essayer ?" Par contre les robots de coupe on de bonnes raisons de l'utiliser puisque qu'ils réalisent l'asservissement des moteurs avec les codeurs qui sont fixés sur les moteurs et l'asservissement polaire avec des codeurs "libres" qui mesurent l'avancement sur le sol.
J'ai mis ces asserivessements en place surtout pour compenser la non linéarité de la commande sur mes moteurs (Commande PWM sur 8bits mais les moteurs n'avancent réellement que vers 150 / 255. Pour régler ça sans PID j'ai mis un offset tout bête dans la commande).

Premièrement, ça n'est pas indispensable: tu peux utiliser directement un asservissement "avancement/angle" (que tu appelles delta alpha), qui commande directement les moteurs. C'est en général ce que font les roboticiens.


Effectivement tu n'est pas le premier qui me dit ça.

Ensuite, si tu veux vraiment faire des asservissements imbriqués, il faut que le temps de convergence de l'asservissement "bas niveau" (ici le PID sur l'avancement des roues) soit très faible par rapport aux constantes de temps de ton asservissement "haut niveau". Sinon, tu peux très bien avoir des phénomènes de divergence.


Là pour le coup je me sens terriblement bête :wacko: ça ma pas posé de problème quand j'ai codé mes asservissements de les mettre dans la même boucle de rafraîchissement. Rha ! tu m'étonnes que ça marchait pas... Bon au moins je crois que je m'en souviendrais pour le coup ^^ Le pire c'est que je l'ai déjà vu en cours, chose qu'on a du nous répéter X fois. Comme quoi rien de mieux qu'un peu de pratique !

En tout cas merci bien pour les conseils Léon :)
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#37 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 03 août 2010 - 06:23

J'ai mis ces asserivessements en place surtout pour compenser la non linéarité de la commande sur mes moteurs (Commande PWM sur 8bits mais les moteurs n'avancent réellement que vers 150 / 255. Pour régler ça sans PID j'ai mis un offset tout bête dans la commande).

Selon comment tu pilotes ton pont en H, le fait que le moteur démarre si tard peut très bien s'expliquer. Si tu pilotes ton pont en H en mode "roue libre", c'est à dire que tes 4 transistors sont "ouvert" quand tu ne le pilotes plus, et donc le courant est obligé de passer par les diodes de roue libre. Dans ces conditions, pour faire réellement décoller le courant, il faut une PWM de plus de 50% au delà d'une certaine fréquence. Ca s'explique très bien.

J'en parlais il y a quelques temps sur le forum d'en face:
http://www.planete-sciences.org/forums/viewtopic.php?p=133454#p133454

Leon.

BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#38 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 13 août 2010 - 03:32

Selon comment tu pilotes ton pont en H, le fait que le moteur démarre si tard peut très bien s'expliquer. Si tu pilotes ton pont en H en mode "roue libre", c'est à dire que tes 4 transistors sont "ouvert" quand tu ne le pilotes plus, et donc le courant est obligé de passer par les diodes de roue libre. Dans ces conditions, pour faire réellement décoller le courant, il faut une PWM de plus de 50% au delà d'une certaine fréquence. Ca s'explique très bien.

J'en parlais il y a quelques temps sur le forum d'en face:
http://www.planete-sciences.org/forums/viewtopic.php?p=133454#p133454

Leon.


Désolé j'avais oublié de répondre depuis l'autre fois.
Effectivement ta remarque me paraît tout a fait logique maintenant que tu le dit, tu est une vraie mine d'informations pratiques !
Du coup comme tu dit soit il faut que je passe le pont en mode frein pendant que je ne le commande pas pour reboucler le courant dans les moteurs, soit je prévois un offset sur toutes les consignes et puis basta (ce que j'étais arrivé à faire mais sans savoir pourquoi il fallait que je le fasse).
Mon PWM est actuellement fréquencé à entre 1 et 10khz (je me rapelle plus exactement combien), tu penses que si j'augmente la fréquence de rafraîchissement je pourrais gagner sur "l'offset" de démarrage ? En théorie je dirais oui puisqu'on laisse moins de temps au courant pour se dissiper dans les diodes de roue libre, mais après est ce que cela va être significatif je sais pas du tout.
Dans tout les cas j'avais déjà prévu d'augmenter cette fréquence pour dépasser les 20khz, j'en ai marre d'entendre mes moteurs "siffler" c'est très désagréable.
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare

#39 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 13 août 2010 - 06:35

Mon PWM est actuellement fréquencé à entre 1 et 10khz (je me rapelle plus exactement combien), tu penses que si j'augmente la fréquence de rafraîchissement je pourrais gagner sur "l'offset" de démarrage ? En théorie je dirais oui puisqu'on laisse moins de temps au courant pour se dissiper dans les diodes de roue libre, mais après est ce que cela va être significatif je sais pas du tout.

Au contraire...
Si tu restes en mode "roue libre", plus tu va augmenter la fréquence du PWM, et plus tu vas te rapprocher d'un offset de 50% dont je parlais. A fréquence élevée, tu peux considérer que la période d'un pulse est très faible devant le temps d'établissement du courant dans ton moteur (assimilable à inductance + résistance en série quand sa vitesse est nulle). Dans ces conditions, la courbe de montée du courant est limitée à un segment tout droit, dont la pente dépend uniquement de la tension aux bornes du moteur. Comme les tensions aux bornes du moteur sont identiques en valeur absolue, en mode "roue libre", entre les phases PWM ON et PWM OFF (+/- la tension d'alim), alors les pentes sont aussi identiques en valeur absolue (U=RxI(0)-LxdI/dt). Regardes les schémas dans la pièce jointe: à haute fréquence, à 50%, en mode "roue libre", et si le moteur ne tourne pas, le courant n'arrivera pas à décoller, car il retombera à zéro à chaque cycle, vu les pentes identiques à la montée et à la descente.

A basse fréquence, au contraire, l'offset sera inférieur à 50%. A très basse fréquence (temps d'établissement du courant négligeable devant la période), l'offset devrait même être nul. Mais bonjour les oscillations!

En mode "frein" par contre (1 transistor au moins passant quand PWM à zéro), l'offset "électrique" devrait être toujours nul.

Tout ça c'est évidemment sans prendre en compte les frottements mécaniques.

Je remet les petits schémas que j'avais fait pour expliquer ça:
Fichier joint  explication_pont_H.doc   37 Ko   89 téléchargement(s)
Leon.

BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#40 Inounx

Inounx

    Membre occasionnel

  • Membres
  • Pip
  • 111 messages
  • Gender:Male
  • Location:Toulouse

Posté 13 août 2010 - 07:29

Comme les tensions aux bornes du moteur sont identiques en valeur absolue, en mode "roue libre", entre les phases PWM ON et PWM OFF (+/- la tension d'alim), alors les pentes sont aussi identiques en valeur absolue (U=RxI(0)-LxdI/dt)


Je ne sais pas si j'ai bien compris mais je pense que tu as voulu dire que la différence de tension entre deux états (ON-> OFF et OFF -> ON) est toujours la même en valeur absolue (ici env 7V).

Au contraire...
Si tu restes en mode "roue libre", plus tu va augmenter la fréquence du PWM, et plus tu vas te rapprocher d'un offset de 50% dont je parlais. A fréquence élevée, tu peux considérer que la période d'un pulse est très faible devant le temps d'établissement du courant dans ton moteur (assimilable à inductance + résistance en série quand sa vitesse est nulle). Dans ces conditions, la courbe de montée du courant est limitée à un segment tout droit, dont la pente dépend uniquement de la tension aux bornes du moteur. Comme les tensions aux bornes du moteur sont identiques en valeur absolue, en mode "roue libre", entre les phases PWM ON et PWM OFF (+/- la tension d'alim), alors les pentes sont aussi identiques en valeur absolue (U=RxI(0)-LxdI/dt). Regardes les schémas dans la pièce jointe: à haute fréquence, à 50%, en mode "roue libre", et si le moteur ne tourne pas, le courant n'arrivera pas à décoller, car il retombera à zéro à chaque cycle, vu les pentes identiques à la montée et à la descente.

A basse fréquence, au contraire, l'offset sera inférieur à 50%. A très basse fréquence (temps d'établissement du courant négligeable devant la période), l'offset devrait même être nul. Mais bonjour les oscillations!

En mode "frein" par contre (1 transistor au moins passant quand PWM à zéro), l'offset "électrique" devrait être toujours nul.


Ouais ça y est j'ai compris. J'aurais mis le temps ^^ effectivement si le courant met toujours autant de temps à monter qu'à descendre (hypothèse des pentes identiques) alors c'est certain qu'à cycle < 50% si on laisse le temps au courant de monter et qu'on lui laisse le même temps ou plus il redescendra à 0. Fatalement (arg). Et oui du coup si j'accélère le pwm la seule chose que sa va faire en dessous de 50% c'est diminuer la valeur moyenne du courant qui passera dans le moteur...
Et encore pour le coup je comprend mieux ton graphique en high speed >50% ou le courant monte et n'a pas assez de temps pour redescendre à 0 et ainsi de suite jusqu'à la valeur d'équilibre. Euréka !

merci pour l'explication, je me coucherais moins bête ce soir.
Mon blog : InounxProjects - Projet en cours : Robert
"All the world's a stage, And all the men and women merely players." - William Shakespeare



Répondre à ce sujet



  


0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users