J'ai pas du tout pigé comment fonctionnait le core xy.... Quelqu'un pourrait m'expliquer ?

Je viens de finir de lire les 37 pages du topic, je suis franchement impressionné par le boulot effectué !

Oui c'est juste une incrémentation.

C'est à vide et effectivement la chute de vitesse est conséquente en charge.

Et j'ai reprise le calcul différemment, ça fait 1750Hz face à un processeur qui tourne à 16MHz. Donc c'est ridicule pour l'uc ^^

Néanmoins, j'ai 2 fiches sur le codeur, sig A et sig B (ca a l'air d'être comme ça sur tous). C'est quoi la différence entre les deux ? ^^

Bonjour à tous,

Je suis en train de me pencher sur les encodeurs pour moteurs.

Admettons les infos suivantes :

Moteur CC à 15 000 rpm

Encodeur à 7 pulses par tour.

Ca me fait du 250 tours par secondes * 7 pulses = 1750 pulses / secondes.

Si je branche ça sur une pin interrupt de l'arduino ça veut bien dire que mon code va être interrompu toutes les 57µs. Et ce par moteur.

Ca me parait un intervalle très court. Est-ce que j'ai loupé quelque chose ? Vu la taille des variables float sur arduino une telle précision n'est pas pertinentes.

Merci beaucoup, le tuto est super clair

Merci Ashira

J'en profite pour venir compléter avec les cours de méca que j'ai eu en DUT et Ecole d'ing.

Le site est pas complet de mémoire, mais il y a l'essentiel de son support de cours.

Ca peut servir en particulier sur la partie cinématique du point et du solide qui est franchement bien

http://www.lem3.univ-lorraine.fr/faure/crbst_13.html

C'est un peu comme ça que l'on faisait pour la communication entre les différents appareils sur mon projet de BTS (il y a un bail ).

Par contre la seule chose que je peux te dire actuellement c'est que pour ton octet 2, n'utilise pas la valeur jusqu'à 255, il vaut mieux envoyer plusieurs petite message (ou trames) qu'un grand message donc il faudrait peut-être ajouter un octet indiquant le numéro de trame et un autre pour indiquer le nombre total de trames pour avoir le message complet. Ceci-dit quand je regarde ton type d'information (octet 1) les messages ne seront jamais très longs.

C'est bien noté pour la longueur des messages. Après, a par envoyer un tableau de mesures complet je vois pas ce qui m’emmènerait à 255.

Oui c'est très bien résumé =) 

 

Il y a ensuite différentes méthodes utilisée pour : 

"Organiser la trame envoyée"  parser,  trame de taille fixe, indicateur de longueur de trame en début de trame, données en Byte ou "lisible"  ...
"S'assurer de la qualité de la trame" byte de start et de stop checsum
"Utiliser les données envoyées" machine à état, banque de donnée, fonction bloquante et indicateur de disponibilité ...

Merci =)

Pour le byte de stop ce qui m'inquiète c'est que nécessairement une valeur qui peut être dans le message et donc mal interprétée. Sur mon schéma papier il y était mais je l'ai enlevé ^^

Je vais jeter un oeil aux pistes que tu me donnes

Bonjour bonjour,

Après avoir lu attentivement le topic d'Oliver17 et ayant moi même pour objectif de mettre en place le même type de com, je poste ici pour pas polluer son topic ( http://www.robot-maker.com/forum/topic/11890-gcom-communication-pi-arduino/?p=92084).

Je me suis documenté sur l'UART et j'ai des idées que je voudrais partager avant de me lancer dans le code ^^. Ca me permettra aussi de vérifier que j'ai bien compris le principe.

Grosso modo les liaisons UART ne sont pas réellement structurées (par opposition à l'i2c par exemple). La ligne est à 1 au repos, quand quelqu'un prends la parole il fait un silence et ensuite transmet un octet.

A l'autre bout de la ligne on va donc recevoir un octet qu'on va stocker dans un buffer que le programme va traiter dans un second temps. Le hic c'est qu'on ne sait pas ce que cet octet représente (ni même le type de variable). Dans le cas d'une info sur plusieurs octets on se sait même pas où est la fin de l'information.

Ceci dit, l'intérêt de l'UART c'est qu'on en fait ce qu'on veut ( ou presque, l'UART cuira pas ma pizza).

Du coup est il imaginable de structurer mes messages de la façon suivante :

Octet 1 : integer de 0 à 255 indiquant un type d'information :

A la façon d'une ENUM on a une table de correspondance dans le soft, par exemple :

001 : commande de déplacement

002 : information du sonar

003 : angle du servo tartampion

Octet 2 : Integer de 0 à 255 indiquant le nombre d'octets qui vont suivre...

Octet 3 à i : l'information en elle même.

Comme ça quand je lis le buffer, je sais ce que je lis. Qu'en pensez vous ?

Cool, je vais suivre ton post, ça m'aidera surement

Même si nos projets sont différent on utilise le même matos et on rencontre les même problématiques ^^

Bonjour,

Je me penche depuis quelque temps sur la fabrication d'un modeste robot. Néanmoins, une question m'inquiète.

Les chats sont agressés par les ultrasons. Les robots se repèrent grâce aux ultrasons (en tout cas c'est le moyen le plus répandu).

Ayant un chat à la maison, comment va-t-il réagir aux ultrasons du robot ? Sont-ils assez puissant pour le déranger ? Ou est-ce que c'est suffisamment léger pour qu'il ne s'en rende pas compte ?

Merci à tous de vos réponses

J'adore le projet xD mais je tiens à ma vie... Madame me tuerait sur un coup comme ça xD

Merci beaucoup pour le retour d'expérience ^^ De prime abord je pensais comme arobasseb ^^

Note pour moi même : faire le premier test quand madame sera absente ^^ des fois que le chat s'enfuirai en courant xD

J'avoue que tu t'es bien fait ***** sur les engrenages

Tu peux toujours lui envoyer en format step ? Même si il perds l'arbre de conception solidworks ca pourra toujours lui servir pour redessiner les pièces non ?