Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
# Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
"La première sécurité est la liberté"