[gwion]

Si tu décomptes de 200 à zéro, cela fait 201 pas il me semble bien.

[F6FCO]

Exact, j'ai écris trop vite pour une explication simple, en fait c'est bien 199 la valeur de départ. A la rigueur même s'il y avait eu cette erreur çà ne porterait pas à conséquence puisque la rotation inverse a la même valeur de départ. C'est symétrique, des déplacements égaux, et c'est validé par le fait que tout se passe bien quand le PORTB est débranché.

J'ai même joué sur le courant des drivers en pensant que les pap perdaient des pas dus aux efforts des inversions de sens, pas çà non plus.

[gwion]

C'était juste pour te taquiner
Si le 200 est codé en dur dans la routine de rotation c'est effectivement très curieux. Mais si le nombre de pas est passé par la procédure de communication, peut-être que le message est altéré si la vitesse de transmission est élevée ? Ou alors trame mal décodée ? Mais si tout est bon en debug ça se complique sérieusement.

[F6FCO]

C'était juste pour te taquiner

Mais tu as raison parce que çà aurait pu être une erreur.

Mais si le nombre de pas est passé par la procédure de communication, peut-être que le message est altéré si la vitesse de transmission est élevée ? Ou alors trame mal décodée ?

Ah non, pas du tout. Le 200 (199) est implémenté dans les routines de rotations des pap qui sont codées et restent dans le PIC maître. L'esclave ne gère que les servomoteurs donc ne devrait rien avoir à voir dans cette histoire. Le 200 ne transite pas par le bus // qui relie les deux PIC. Pour çà que je suis paumé pour l'instant, çà sent le Tupapa'u qui se balade dans le code

[F6FCO]

Hello world,
La canicule est enfin partie de ma soupente de bricolage, je peux reprendre le projet. Mais pas de la même façon, j'ai remplacé mes deux petites platines PICduino par la platine I²C que je viens de graver ici. Les pins spécialisées pour servomoteurs sont quand même un plus pour la clarté du câblage.
Et comme j'avais envie de péter dans la soie les deux esclaves ne me suffisant pas, j'en ai rajouté un troisième. Mon protocole parallèle perso étant remplacé par un I²C çà impose de repartir à zéro pour le code mais avec l'expérience acquise je sais maintenant ou aller.
Les trois esclaves sont carrément sous-employés avec seulement deux ou trois pins par pic mais avec un par axe çà devrait fluidifier les mouvements.

Le câblage est maintenant bien touffu qu'avant

P1070027.JPG

[venom]

Bravo en effet. C'est beaucoup plus propre ainsi.

Le fait de faire 1 pic par cerveau tu gagne en temps de rotation ?





@++

[F6FCO]

Pas tellement en temps de rotation mais en temps machine et fluidité d'éxécution parce que je code le PWM en bit bang. J'aurai pu faire sans avec les deux PWM que peut sortir le 2525 mais je n'ai pas encore creusé de ce coté. On ne peut pas être partout non plus
Et puis c'est surtout que çà m'amuse d'avoir trois esclaves.

[F6FCO]

Le projet se reconstruit tranquillement avec la nouvelle carte I²C. Je l'ai modifiée en intervenant sur les pistes, les alims des servos étaient en 5vcc issu du gros 7805 1A, je les ai passées en 7v, les servos sont maintenant plus "gaillards" et répondent mieux.

[venom]

Ah en voilà une bonne nouvelle
Courage F6FC0

Vivement la prochaine vidéo






@++

[F6FCO]

Sauf que je viens de faire une petite connerie, j'avais consulté le datasheet du MG996R (avancée pap) qui accepte 7v mais oublié d'aller voir celui du SG90 (fermeture pinces) qui lui n'accepte que 6v. Il a fallu que j'en fume un avant de percuter , heureusement que j'en ai en stock .
J'ai descendu le LM2596 à 6vcc.