Informations sur la carte pixl (raspberry Pi - XL320)

Nous n’avons pour le moment jamais vue ce genre de cas, @lpierron tu fais partie des premiers utilisateur de cette carte!

Il est peut être aussi possible que ton transformateur secteur soit mort. A tu tenté de ne pas brancher la prise secteur de la Pixl et d’alimenter le tout par la raspberry?
Tu pourrais aussi tenter de brancher un transformateur différent sur la Pixl!

Si le problème ne viens pas du transformateur ca doit provenir du régulateur. Serait-tu en mesure de nous dire comment tu as branché la Pixl avant d’avoir l’emplacement normal?

Pour résoudre ton problème il y a des méthodes plus ou moins simple et rapide. De plus je ne sais pas de quel matériel tu dispose…

Méthode rapide : Tu déssoude le régulateur. Il vas te falloir de l’étain un bon fer à souder et de la tresse a déssouder. Ce démontage est plutôt difficile à réalisé, je pourrais te faire une video si besoin. Après cette opération il te faudra alimenter la raspberry par usb et la Pixl avec le Jack, les 2 en même temps.

Méthode plus longue : Tu m’envoie ta carte pour que nous puissions l’examiner et tenter de corriger le problème sur les futures générations. Je t’en renverrais une neuve le plus tôt possible.
Pour le moment nous sommes complètement “out of stock”, nous devrions recevoir une nouvelle production le 22 février.

Ah, ça je ne savais pas j’ai alimenté les deux. je veins d’essayer d’utiliser uniquement mon alimentation sur la carte Pixl, là je n’ai ni voyant vert ni voyant rouge allumé.

Ce que je peux facilement mesurer ce sont les tensions sur les différentes PINS de la carte Pixl relativement à la masse.

J’ai essayé avec un autre transformateur et j’ai essayé d’inverser les polarités des transformateurs, il y a un comportement différent suivant les sens : si le - est à la masse alors le voyant rouge du moteur s’allume puis s’éteint sinon il ne s’allume pas.

Les transformateurs que j’utilise sont des transformateurs universels régulés, j’ai un transfo 25 W ((1,5-12 V) et un 60 W (5 V-12 V par pas de 1V).

Je peux tenter la ** méthode rapide** : où se trouve le régulateur sur la carte ? c’est le gros bloc gris ?

Ce n’est en effet pas un bonne pratique, mais ce ne pose aucun soucis d’alimenter les deux en même temps.

Non, la led rouge du moteur s’allume et s’éteint quand il démarre, c’est la même chose sur tous les moteurs dynamixel, en aucun cas elle ne reste allumée (à moins que tu aies changé sa configuration ou que tu lui dit d’allumer sa led).

C’est “normal”, la raspberry pi alimente tes moteurs avec un courant qui passe en inverse dans l’alimentation à découpage.

Oui, d’abord mettre la pixl sur la raspberry pi, puis ensuite ça n’a pas d’importance dans quel ordre tu alimentes la pixl ou branche les moteurs. Dans tous les cas, il faut mettre ou enlever la pixl de la raspberry pi débranchée.

Finalement, en bricolant Rado et Alex ont réussi à brancher ErogJr sur le port USB du raspberry-pi et à le tester, je posterai des vidéos. Ils vont pouvoir le montrer aux enfants au club robotique de la MJC Nomade et commencer la réalisation d’un scenario pour l’exposition.

Je vais vous envoyer envoyer la carte Pixl pour que vous puissiez faire un diagnostic de sa panne. Je l’envoie à quelle adresse postale ?

Tu peux me la faire parvenir ici :

Nicolas Rabault, flowers team, inria
200 avenue de la vielle tour, 33405 Talence

Je t’ai expédié la carte mardi dernier, tu me tiens au courant quand tu la reçois et si tu réussis à la diagnostiquer.

Merci d’avance.

Bonjour,

As-tu reçu ma carte Pixl ?

Bonjour @lpierron,
J’ai bien reçu ta carte!

Il s’avère en effet que le régulateur est HS. Pas de trace de brûlure ou de dommage autre, je ne sais pas exactement ce qui a pu se passer. Bien évidement c’est le composant le plus complexe à changer à la main, la réparation est difficilement envisageable.

Ton événement au club robotique c’est-il bien passé? Pourrais tu nous décrire ta solution actuelle?

L’évènement au club robotique a lieu demain, je ne pourrai pas y aller.
Je demanderai aux animateurs qu’ils nous fassent un retour.

Je suis en train de tester le pixl avc heol, donc 23 xl 320. Premier obstacle, je pense qu’il y a quelques manipulations à faire sur le raspberry pour ouvrir le port série ?

in : pypot.dynamixel.get_available_ports()
out :

Apparement ça vient de pypot parce que :

import sys
import glob
import serial

ports = glob.glob('/dev/tty[A-Za-z]*')

result = []
for port in ports:
        try:
            s = serial.Serial(port)
            s.close()
            result.append(port)
        except (OSError, serial.SerialException):
            pass 

me renvoit bien :
['/dev/ttyAMA0']

Bon OK, ça m’apprendra à pas avoir la dernière version de pypot, j’ai vu que le port de la pixl était rajouté.

Par contre en cas d’install avec pip, ça marche pas.

Etape suivante :

dxl_io = pypot.dynamixel.Dxl320IO('/dev/ttyAMA0', use_sync_read=False)
motors = (dxl_io.scan(range(60)))
print(motors)

pypot ne trouve pas le moteur :

out : []

pas l’air bien bon ça… :sob:

Je suis descendu à 9600 bauds pour la transmission et là miracle, ça marche :slightly_smiling:
dxl_io = pypot.dynamixel.Dxl320IO('/dev/ttyAMA0', baudrate=9600, timeout=0.5, use_sync_read=False)

Je vais essayer de voir à d’autres vitesse mais à 1000000 de bauds ça passe pas.

A 9600 bauds, il faut 35ms pour retourner la present.position, je m’attendais à pire :
> %timeit dxl_io.get_present_position(motors)

out : 10 loops, best of 3: 35 ms per loop

@Nicolas is this : “We change a pull up resistor to boost the signal current and decrease the switch time (we change the default 500homs output pull-up to a 200homs)” could be part of the problem at 1000000 bauds ?

A 115200 bauds, ça passe mal, le ping fonctionne mais j’ai des erreurs :
DxlCommunicationError: could not parse received data bytearray(b'\xff\xff\xfd\x00"\x06\x00U\x00\xfd\x01\xfc\xfa') after sending DxlReadDataPacket(id=34, address=9472, length=512)

Alors le problème vient de l’envoi de commande très proche (le %timeit) car si je fais ça :

for i in range(100):
    dxl_io.get_present_position(motors)
    time.sleep(0.02)

Ca marche, mais quand je réduit le time.sleep je tombe sur l’erreur parse data. Une sorte de conflit entre les donneés qui partent et celles qui reviennent ?

En effet tes problèmes de vitesse pourrais être due à la résistance de pull-up. En réalité ça dépend du nombre de moteurs que tu as sur ta chaîne.
Attention il faut que les moteurs soit configuré à la même vitesse que celle à laquelle tu envoie, c’est un bus asynchrone.

Par défaut la RPI utilise le port série comme console de debug, a tu bien désactivé cette fonction?

Il y a en fait deux étapes à réaliser avant de pouvoir communiquer avec les ports séries de la Raspberry vers les moteurs:

  • désactiver le log série
  • changer la fréquence de l’UART

Tu peux voir comment faire ici : https://github.com/poppy-project/poppy-installer/blob/master/install-deps/install-hardware-changes.sh

Et en particulier:

# Disable tty over serial
if [[ "$POPPY_BOARD" == "rpi" ]]; then

    if [[ $(uname -a) == *"essie"* ]]; then
        # If it is based on Debian Jessie which use systemd
        # https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=123081
        sudo systemctl stop serial-getty@ttyAMA0.service
        sudo systemctl disable serial-getty@ttyAMA0.service

    elif [[ $(uname -a) == *"heezy"* ]]; then
        # If it is based on Debain Wheezy (still use sysvinit)
        # We have to modify /boot/cmdline.txt and /etc/inittab to remove the ttyAMA0 occurences
        # Taken from raspi-config source code
        sudo sed -i.bak /etc/inittab -e "s|^.*:.*:respawn:.*ttyAMA0|#&|"
    fi

    sudo sed -i.bak /boot/cmdline.txt -e "s/console=ttyAMA0,[0-9]\+ //"

    if ! grep "init_uart_clock=16000000" /boot/config.txt
    then
        sudo su -c "echo \"init_uart_clock=16000000\" >> /boot/config.txt"
    fi
fi

Ok merci.
J’avais bien adapté la vitesse des moteurs et désactiver la console pour mes différents tests mais je pensais que Python changeait la fréquence de l’UART quand on initialise une liaison série avec un certain baudrate.

Je vais refaire des tests en utilisant le script. Pour ma chaine, pour l’instant je n’utilise qu’un seul moteur.
J’ai réussi à capturer des trames et j’observe bien le même défaut que @Nicolas

Par contre, ma fréquence d’échantillonnage est par terrible mais avec un arduino comme oscillo j’arrive pas à faire mieux (je sens que je vais me trouver un Pico2205, c’est bien ça ?) :wink:

Et il y a bien un problème quand j’envoie des commandes en rafale qui retourne un could not parse data de la part de Pypot.
C’est compliqué à changer la résistance de pull-up (elle est où sur la carte ?)

C’est le cas … en général ; cependant sur la Raspberry Pi il faut changer la clock pour permettre un range de baudrate plus élevé. C’est vraiment propre au driver qui gère le port série du mirco processeur.

Si tu as des problèmes de type “could not parse data” alors que tu as moins de 8 moteurs (le max qu’on ai testé sur des XL320), ce n’est vraiment pas normal.

C’est la résistance juste à côté du conncteur du moteur. Pour la désouder, la meilleure technique est de la chauffer en rajoutant de l’etain dessus (c’est contre intuitif mais de loin la meilleure technique).

Si tu veux un analyseur logique pas cher, je te conseille celui d’hobbycomponents

En effet, c’est pas cher un analyseur logique. Mais mais ce type d’analyseur me dira juste si il y a du courant ou pas, hors j’aimerais bien faire aussi de l’analogique pour voir le forme réelle du signal.

Il y a un truc que j’arrive pas à comprendre sur le full duplex vers half duplex. En full duplex, la réception (Rx) et la transmission (Tx) peuvent être simultanées. Alors que ce passe t-il sur la carte Pixl si pendant que les moteurs renvoient une trame de réponse, le Tx du Raspberry envoi une trame en même temps ?

Il me semble pas qu’il y ait un buffer sur la Pixl capable d’enregistrer le Tx en attendant que le Rx soit passé ?

J’ai rajouté init_uart_clock=16000000 à la fin de config.txt et ça marche très bien :slightly_smiling:
Avec 1 xl-320 :

%timeit dxl_io.get_present_position(motors)
out : 100 loops, best of 3: 2.01 ms per loop

Avec 23 xl-320 :

%timeit dxl_io.get_present_position(motors)
out : 10 loops, best of 3: 42 ms per loop

Et en utilisant sync_read=True , c’est 2 fois plus rapide :smile:

100 loops, best of 3: 19.1 ms per loop

1 Like