J'ai repensé à ce que ton petit doigt t'a dit mais je ne comprend pas ce qu'il a voulu te dire. Tu peux m'en dire un peu plus stp, je voudrais bien comprendre, même si ce n'est qu'un doute.
Je reprends :
Normalement, à moins que je ne doive revoir complètement la théorie et mes expériences pratiques , jouer sur la fréquence, dans le cadre d'un pilotage de moteur CC par PWM, ne doit pas avoir d'impacte sur la vitesse de rotation ( mais essentiellement des impactes sur le bruits etc... et tant qu'on reste dans des plages de fréquences " correcte " )
Du coup il faut chercher une explication. Je ne sais pas ce qui se passe quand tu fais ton " time.sleep(x) " . mais c'est possible qu'il y ait un lien.
Essaye de refaire ton test sans l'utiliser.
Je me suis lancé là dedans ... J'ai réussi alors je partage.
Mon dongle wifi : Wifi Netgear N150 (WNA1000M). Il supporte le mode station (ou AP) mais il n'est pas reconnu d'office par la raspbian. Je m'en suis sorti grace à ce lien : https://matt.niloo.f...i-netgear-n150/. On s'en sort en mettant la conf du driver dans /etc/rc.local.
Ce qui m'a fait perdre un temps fou c'est mon netgear et son driver. Dans la conf de hostapd, par défaut, c'est driver=nl80211. Il fallait driver=rtl871xdrv.
Mais ce n'est pas tout. La conf des services hostapd et udhcpd fonctionnait bien mais pas au redémarrage ... J'ai cru devenir fou. Le problème venait de rc.local qui arrive après le lancement des services. Du coup, je restart les 2 services dans rc.local, après le driver. Je ne trouve pas ce contournement super bien.
Ça fonctionne, je me connecte directement au raspberry en wifi sans passer par mon router. Mais si quelqu'un a mieux que /etc/rc.local pour installer le driver 8192cu, je suis prenneur.
@Mike, je n'ai pas ton expérience ^^ De mon expérience, mettre un sleep dans une boucle ça fait respirer le processeur. C'est comme un réflexe pour moi ^^ Je refais un test et je te tiens au courant
sense.show_letter("A", text_colour=[255, 0, 0])
duty = 2
freq = 50
moveForwardMotorA(duty, freq)
moveForwardMotorB(duty, freq)
time.sleep(3)
moveBackwardMotorA(duty, freq)
moveBackwardMotorB(duty, freq)
time.sleep(3)
sense.show_letter("B", text_colour=[255, 0, 0])
# Je laisse le B à 50 Hz
# pendant que le A varie
# Le duty reste à 2
for freq in range(50,20000, 200):
moveBackwardMotorA(duty, freq)
time.sleep(.1)
sense.show_letter("C", text_colour=[255, 0, 0])
stopMotorA()
stopMotorB()
duty = 2
freq = 50
moveForwardMotorA(duty, freq)
moveForwardMotorB(duty, freq)
time.sleep(3)
sense.show_letter("D", text_colour=[255, 0, 0])
stopMotorA()
stopMotorB()
# Je laisse le B à l'arrêt
# pendant que le duty du A varie
# La freq reste à 50 Hz
for duty in range(0, 100, 1):
moveBackwardMotorA(duty, freq)
time.sleep(.1)
sense.show_letter("E", text_colour=[255, 0, 0])
stopMotorA()
stopMotorB()
# on atend 2s sinon pas le temps de voir
time.sleep(2)
# Je laisse le B à l'arrêt
# pendant que le duty du A varie
# La freq reste à 50 Hz
for duty in range(0, 100, 1):
moveBackwardMotorA(duty, freq)
#time.sleep(.1)
sense.show_letter("F", text_colour=[255, 0, 0])
# Je laisse tourner 2s car 'E' est trop court sans le sleep
time.sleep(2)
sense.show_letter("G", text_colour=[255, 0, 0])
stopMotorA()
stopMotorB()
duty = 2
freq = 50
# Je ne fait varier ni la freq, ni le duty
for toto in range(0, 100, 1):
moveBackwardMotorA(duty, freq)
time.sleep(.1)
sense.show_letter("H", text_colour=[255, 0, 0])
stopMotorA()
stopMotorB()
duty = 2
freq = 50
#
for toto in range(0, 10000, 1):
moveBackwardMotorA(duty, freq)
time.sleep(.001)
clean()
Le A et le B, tu connais déjà. Ils montrent l'accélération fonction de la fréquence.
Le C pour se redonner un repère.
Le D, je fais varier le duty de 0 à 100 sans changer la fréquence avec un sleep de 0,1 sec. (Cas attendu, et documenté)
Le E petite pause avec les moteurs à l'arrêt
Le F, comme le D mais sans sleep.
Remarque, cela monte tellement vite de 0 à 100 que j'ai mis un pause de 2 sec après la montée sinon on ne voit rien.
Le G et le H, pour observer le comportement de la boucle sans faire varier ni la fréquence, ni le PWM. Pour G, la pause est de 100ms pour le H, la pause est de 1ms.
Alors, si j'ai bien compris ce que ton petit doigt te dis (ou pas), tu remarqueras comme moi qu'il n'y a pas de différence entre G et H. T'en pense quoi ?
Perso, je crois que cela vient de la carte contrôleur. Mais je ne trouve aucune info là dessus. En tout cas, je fait mes derniers tests d'équilibrage avec une fréquence fixe. Elle est autour de 150 - 200 Hz.
Bon je ne vois pas non plus ... faudrait vraiment voir ce qui se passe avec un oscillo ... Je continu de me gratter la tête ...
Sinon, tes vidéo sont très belles =) et j'aime beaucoup l'idée de l'afficheur pour afficher les différentes phase du programme
Bonne continuation pour la suite ! =)
Et bienvenu à Ash ! J'espère pour lui que son nom c'est plutôt une allusion au phénix et à sa naissance plutôt qu'à la façon dont il va finir ! =)
A part cela, le robot est baptisé "Ash". (Tu m'as répondu pendant que j'éditais)
J'ai changé le montage pour éviter qu'il ne tombe de trop haut.
Au repos, ça permet de ne pas le poser sur les composants. Et, comble du luxe, il se relève tout seul.
Et pour replacer ça dans la conversation : j'ai besoin de la fréquence la plus faible pour avoir des mouvements doux. Mais pour qu'il se relève, j'ai du passer de 50 à 150 Hz. En dessous, il n'a pas assez de force pour se relever.
Tout cela est encore un peu brutal, il continue de se balader sans que je lui dise ... J'ai encore du taf pour calibrer ce PID.
il continue de se balader sans que je lui dise ... J'ai encore du taf pour calibrer ce PID.
Par contre je ne me rappel plus tu as pris la version avec les codeurs sur tes moteurs ?
Si oui tu vas bientôt pouvoir commencer à intégrer des asservissement imbriqués et là ça va devenir un chouilla plus costaud
En fait tout d'abord tu fais en sorte d'avoir un asservissement qui te permet d'être en équilibre => angle du robot par rapport au sol en consigne fixé = 0°
(ou 90° en fonction de comment tu vois la chose )
Pour cela pas besoin des codeurs car tu te base sur l'angle mesuré par ton capteur.
Sauf que si maintenant le but est de faire aller ton robot à un point précis, tout en gardant ton équilibre, là tu vas te servir des encodeurs pour générer un consigne angulaire donné en gros un PID de "consigne angulaire" en fonction d'où le robot se trouve et en fonction d'où il doit aller. Et quand le robot sera en place le résultat de ce PID sera de donner en consigne fixe ton 0° pour rester en équilibre au point souhaité...
Et ensuite pour faire plus compliqué encore :De même pour faire tourner ton robot ...
As tu remarque que tu peux essayer d'asservir ton robot en n'utilisant qu'un seul des deux moteurs ?
Quand il se tiendra bien droit sans trop osciller, j'ai bien l'intention de le faire avancer, reculer et tourner. Je prévois de piloter depuis mon téléphone et à vue. Sans mesurer la distance parcourue.
Après, pour avancer, le crois que cette commande revient à reculer (très légèrement) pour donner une inclinaison (toujours très légère) vers l'avant. Avec l'oscillation, même faible, pas certain qu'il faille reculer préalablement. Sûr que je vais tester tout ça Et tout le temps qu'il doit avancer, il faut corriger vers cette nouvelle inclinaison au lieu de 0. Pour s'arrêter, il faut remettre l'inclinaison cible à 0.
Pour tourner, c'est peut être une roue à la fois mais j'avoue trouver plus sympa de le voir pivoter sur son axe vertical ... tant qu'il tourne à l'arrêt. Pour tourner en mouvement, c'est donner une différence de vitesse aux 2 moteurs.
Mais je crois redire ce que tu disais avec mes mots.
J'ai tout démonté pour améliorer la forme, retirer les câbles en face avant (par dessus l'afficheur), retirer un peu de matière et fixer plus solidement le capteur inertiel. Il a minci et il est plus léger.
Coté logiciel, j'ai fait un compromis. J'avais donné la possibilité de piloter indépendamment la vitesse des 2 moteurs en affectant les 2 uniques sorties PWM aux moteurs. Aujourd'hui, je n'en laisse qu'un pour donner le 2eme au pilotage d'un servo. Raspberry oblige ... Le prochain ce sera avec de l'arduino ou un mix des 2 !
Donc il perd la possibilité de tourner en avançant. Il tournera à l'arrêt. En contrepartie, il gagne la vue avec une tête pivotante.
Je lui cherche des yeux ou plutôt une canne blanche Je vais essayer avec ça. Je vous tiens au courant.
PS.
Au passage, j'ai appris au sujet du capteur inertiel et plus précisément sur la librairie utilisée RTIMULib. Elle donne des valeurs correctes (attendues) pour le yaw et le roll (entre 0 et 360). Mais pour le pitch, elle va varier entre 90 et - 90. Sur une demi sphère. Surprenant. Tout est super bien expliqué là : https://richardstech....com/imu-stuff/. Du coup, vu la nouvelle position du capteur, je n'utilise plus le pitch mais le roll avec 90° comme objectif de correction.
Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir
Posté 06 mars 2016 - 01:30
Ah je me disais bien que soit c'était pas possible soit je ne comprenais pas ce que tu souhaitais faire... Du coup je m'étais dis que je ne comprenais pas ... Mais ne t'inquiète pas il y a d'autre solution ( et peu coûteuse ) pour qu'ash ne perde pas la tête
En fait c'est hyper limité le raspberry !!! Ça a de bons cotés mais niveau sorties, c'est trop juste.
Du coup je m'étais dis que je ne comprenais pas ...
... Mais faut pas hésiter hein. Je suis là pour être challengé
Là, je dis une autre connerie :
Pour scruter son horizon, il tournera sur lui même.
... Je n'ai pas d'encodeur sur les roues. Or si Ash doit tourner sur lui-même pour scruter autour de lui, comment je vais faire pour viser tous les 15° ? hein ? Je me le demande que maintenant ? Je suis un noob mais j'adore cette matière !!
Bref, merci Mike, je viens de comprendre ta remarque sur ces encodeurs.
Dans l'état de ma réflexion, j'ai deux solutions : Arduino ou extension
Arduino, je remplace le rpi mais je dois aussi remplacer le capteur inertiel (le sensehat du rpi n'est pas compatible)
Extension, mais le port i2c du rpi est déjà occupé par le sensehat. Si je dis ça, c'est certainement par méconnaissance.
Donc partons sur l'extension. Dis moi si j'ai bon.
J'ai déjà une alimentation 5V dédié à la tête (Servo+ capteur ultrason + extention maintenant).
The IMU (Gyroscope, Accelerometer, Magnetometer) through a LSM9DS1 found at i2c address 0x1c(0x1e),0x6a(0x6b), with Interrupts on the ATTINY88.
Environemental sensors are represented by a LPS25H Pressure+Temperature sensor at address 0x5c and by a HTS221 Humidity+Temp sensor at 0x5f on the i2c bus.
Les leds et le joystick sont sur le bus SPI.
Je me dis que si je configure l'extension PWM sur 0x60 par exemple, il sera compatible avec le sensehat.
Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir
Posté 06 mars 2016 - 06:40
Oui tu as raison, l'avantage de l'I2C c'est que tu peux brancher plusieurs périphériques sur un même Bus tant qu'ils on chacun une adresse différente.
Par contre attention, toi si j'ai bien compris tu as ton capteur qui te sert à garder ton équilibre avec qui tu "discute " en I2C ... Du coup tu discute très souvent avec lui pour récupérer les valeur, si tu as besoin de "discuter en continu" pour garder l'équilibre ton port I2C sera occupé !
Par contre ta première remarque d'ajouter une arduino elle est pas mauvaise mais l'idée n'est pas de remplacer la pi par la arduino mais de compléter la PI par la arduino.
Le but c'est de faire un contrôle de haut niveau avec la raspberry Pi du genre " tiens en équilibre et avance de 3m à tel vitesse , il faut que je cherche la balle verte dans l'image "
Et en faites les action " avance de 3m " " tiens en équilibre " seront elle géré par la carte arduino en esclave ... qui elle a plus d'entrée sortie mais moins d'intelligence etc...
Enfin pour savoir tourner sur sois même si tu as pas d'encodeur sache tu peux utiliser la centrale inertielle sur ton sense Hat et l'utiliser comme boussole et te servir de cette boussole pour savoir de combien tourner etc... bon tu auras de la dérive dans le temps et la précision peut pas mal varier en fonction des objets autour de toi mais ça fera un bon début !
Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir
Posté 08 mars 2016 - 06:37
J'ai déjà ces questions :
Sur le robot j'ai 2 batteries : 5V pour le pi et 12V pour les moteurs (c'est la fameuse 10 cellules NiMh qui sort du 14,1V).
1. C'est déconnant si je branche l'arduino en parallèle des moteurs sur la batterie 12V ?
2. Je lis qu'il accepte entre 6 et 20V. Quelque soit la tension d'alim, il sort sur 5V sur ses broches ? C'est bien comme ça que ça fonctionne ?
1) Non c'est pas " complètement déconnant " car la tension la tension d'alimentation sur VIN est recommandé entre 7 et 12V mais comme tu les dis les maximum ratings sont à 20V...
cependant
a) si tu l'alimente en 14V je te garantis que ta arduino va rapidement chauffer et c'est pas bon pour sa durée de vie.
b ) si tu l'alimente en parallèle des moteurs, il y a de grande chance que les moteurs " parasitent l'alimentation" le résultat d'un tel parasitage : carte qui réset ou qui plant sans explication dû en fait a des fluctuation sur l'alimentation ...
2) oui quelque soit la tension d'alim sur VIN il sort du 5V sur ces broches.
Comme je n'y connais encore rien sur l'arduino, comment on alimente le truc etc ... Je check tout ça et je reviens
Tu peux aussi directement alimenter la carte arduino par la broche 5V avec du 5V ( en parallèle de ta pi par exemple ), ou bien l'alimenter par l'usb en passant par ta Pi.
