Microcontrôleur / CPU pour une trigonométrie rapide en robot?

Cela concerne le matériel qui pèse peu, car un robot de marche (gros chat, 6 jambes avec 3 DOF) devrait le transporter. À cause de cette marche, il faudra faire beaucoup de trigonométrie (en utilisant ou non des mathématiques matricielles), et c'est de là que vient cette question.

PIC, Arduino ou AVR bon marché ne sont pas assez rapides pour tout calculer 100 / seconde et garder à l'esprit des choses comme l'inertie et l'évitement d'obstacles, ou même des chemins / allures de force brute.

• Le plan A consiste à porter le cerveau sur le robot. Que ce soit un microprocesseur, un micro ITX, un nettop ou autre; Qu'est-ce qu'un matériel efficace pour faire de la trigonométrie / des mathématiques matricielles rapidement?

  J'ai cherché en ligne et je m'attendais à découvrir des microcontrôleurs AVR, x86 ou ARM spécialisés dans ce domaine, mais pas de chance là-bas.

• Le plan B est d'avoir une machine x86 connectée via WiFi pour faire le gros du travail. Idéal pour le prototypage également, mais j'aimerais que cela migre vers le plan A éventuellement lorsque le matériel se miniaturise. Mais même dans ce cas, quel processeur de bureau peut faire la trigonométrie le plus rapidement?

• Le plan C est de répartir la charge et d'avoir un microcontrôleur / noyau économe en énergie pour chaque jambe, bien que ce ne soit pas la meilleure solution pour de nombreuses raisons j'aime sa capacité d'extension.

Je n'ai pas encore décidé du langage et / ou de la bibliothèque utilisés, mais je préfère Pascal et C ++.

(suggestions de balises plus adaptées bienvenues, je suis nouveau ici)

Il ne semble pas que votre application soit vraiment tout ce qui demande beaucoup de calcul. Un dsPIC, par exemple, peut exécuter une instruction de 400 k pour chacune de vos itérations. C'est beaucoup. Il sera cependant utile d'avoir de bonnes capacités d'E / S de bas niveau, des générateurs PWM, des temporisateurs, etc.

Sinus et cosinus n'est vraiment pas si difficile à faire dans une machine entière comme un dsPIC. Je l'ai fait moi-même quelques fois. L'astuce consiste à choisir la bonne représentation des angles. Les radians peuvent être agréables d'un point de vue théorique, mais cela n'est pas pratique sur le plan informatique. La dégressivité est artificielle et tout simplement idiote. Utilisez la plage complète de l'entier de la taille de votre machine pour représenter une rotation complète. Par exemple, sur un dsPIC, qui est un processeur 16 bits, une rotation complète est de 65536 comptes, ce qui est bien plus précis et résolution que nécessaire pour contrôler un robot ou que vous pouvez mesurer de toute façon.

Un avantage de cette représentation est que tout l'encapsulage se produit automatiquement simplement en raison de la façon dont les entiers non signés ajoutent et soustraient le travail. Un autre avantage significatif est que cette représentation se prête particulièrement bien à l'utilisation de tables de recherche pour le sinus et le cosinus. Il vous suffit de stocker 1/4 de cycle. Les deux bits supérieurs de l'angle vous indiquent dans quel quadrant vous vous trouvez, ce qui vous indique si vous souhaitez indexer le tableau vers l'avant ou vers l'arrière, et si vous devez annuler le résultat ou non. Les N bits inférieurs suivants sont utilisés pour indexer dans la table, la table ayant 2 ^N segments (2 ^N +1 points). Notez que l'indexation dans le tableau vers l'arrière complète alors simplement les bits d'index du tableau.

Vous pouvez donner au tableau suffisamment de points pour que la sélection de la réponse la plus proche soit suffisante. Par exemple, si la table contient 1024 segments, le sinus et le cosinus seront calculés au 1/4096 de cercle le plus proche. Cela va être suffisant pour contrôler un robot. Si vous souhaitez plus de précision, vous pouvez soit agrandir la table, soit utiliser les bits inférieurs restants de l'angle pour interpoler linéairement entre les entrées de table adjacentes.

Quoi qu'il en soit, le fait est qu'il semble que vos exigences pour ce processeur ne correspondent pas au problème indiqué. J'utiliserais probablement un dsPIC33F. Il est certainement petit, léger et beaucoup plus économe en énergie qu'un processus informatique à part entière comme un x86 sur un ordinateur à carte unique.

Vous allez gérer de nombreux signaux d'entrée. Vous n'avez pas nécessairement besoin d'un processeur à haut débit; beaucoup de signaux peuvent être traités en parallèle. Il s'agit d'un territoire DSP typique. Bien sûr, vous voulez également des fonctionnalités générales du processeur. Ce n'est pas un problème. Il existe de nombreux processeurs avec DSP intégrés.

Une conception de puce typique pour de telles applications est un Cortex-M4. Cela vient avec un DSP intégré, et les versions -M4F ont également un FPU. Cela peut ne pas être nécessaire, la trigonométrie peut facilement être effectuée en mathématiques à virgule fixe.

Quelques remarques:

1. Vous n'avez pas besoin de traiter les opérations de trigonométrie sur le même processeur qui exécute l'évitement d'obstacles. Vous pouvez répartir les tâches entre deux microcontrôleurs et utiliser un protocole de communication pour les faire parler.

2. Pour une expérience, j'ai implémenté un algorithme AHRS avec un filtre de Kalman dans un microcontrôleur ARM Cortex M0 (c'était un STM32, je ne me souviens pas exactement du reste mais je pense que c'était 32 MHz), et en utilisant des mathématiques à virgule fixe, je pouvais exécuter à environ 40 échantillons / seconde. Avec un contrôleur plus rapide, vous devriez pouvoir le transporter facilement, et bien sûr, vous pouvez essayer la méthode FPGA ou DSP.

3. Je dirais que le contrôle des jambes n'est pas gourmand en CPU et vous pouvez contrôler toutes les jambes ensemble, peut-être séparément des opérations de trigonométrie et d'évitement d'obstacles (voir 1)

La trigonométrie est délicate, mais il existe des raccourcis. Si vous êtes léger sur la puissance de traitement, considérez l'algorithme CORDIC.

Il s'agit essentiellement d'une table de valeurs pour [par exemple] sinus. Les angles peuvent être en degrés, radians, comme vous voulez. Le fait est que le SINE de ces valeurs est 1/2 (0,5), 1/4 (0,25), 1/8, 1/16 ..... à n'importe quelle fraction de degré que votre robot peut utiliser.

Entrez votre angle, soustrayez la première valeur du tableau, définissez votre résultat sur le premier résultat (0,5). Si, en soustrayant, votre angle devient négatif, alors AJOUTEZ la valeur suivante (et soustrayez 0,25). Sinon, continuez à soustraire les angles et à ajouter des résultats.

Lorsque vous arrivez à la fin du tableau, tout ce que vous avez fait est d'ajouter et de soustraire, mais vous êtes très proche. Il y a un dernier "facteur de violon" à multiplier.

La précision [et la vitesse] du résultat dépendent de la taille [et de la résolution] de la table de recherche.

Vous pouvez envisager d'utiliser une carte Raspberry Pi qui exécute un système GNU / Linux à usage général. Le Raspberry Pi possède plusieurs broches GPIO qui peuvent être utilisées pour connecter des servos de robot ou des cartes d'extension.

http://www.youtube.com/watch?v=RuYLTudcOaM

Le modèle A Raspberry Pi peut effectuer jusqu'à 24 GFLOP de calcul à virgule flottante à usage général en utilisant son GPU utilisant OpenGL ES 2 tout en restant sous un budget de puissance de 2,5 W.

http://elinux.org/RPi_Hardware

Exemple: une configuration de robot alimentée par batterie implémentée à l'aide du Raspberry Pi.

http://www.homofaciens.de/technics-robots-R3-construction_en_navion.htm

Exemple 2: un robot à 6 pattes contrôlé par un Raspberry Pi:

http://www.youtube.com/watch?v=Yhv43H5Omfc

Exemple 3: un robot à pendule inversé à 2 roues auto-équilibré contrôlé par un Raspberry Pi:

http://www.youtube.com/watch?v=n-noFwc23y0

Pour le robot à pattes, vous pouvez créer des séquences de mouvements de jambes prédéfinies et les "jouer". L'évitement d'obstacles en temps réel peut être fait avec une fuzzy logicimplémentation légère où tout est à nouveau sous forme de tableau et tout ce que vous devez faire est de choisir la bonne valeur et de l'utiliser pour le defuzzyficationprocessus.

Tout peut être fait en C sur un processeur plus rapide comme ARM7. Je l'ai essayé AVRet j'ai échoué, après avoir passé beaucoup de temps à tout transformer en fixed point arithmetics.

La plate-forme Texas Instruments Stellaris a une unité à virgule flottante intégrée par défaut. Je ne sais pas si le contrôleur ARM cadencé à 80 MHz est assez rapide pour votre application, mais une carte de développement LaunchPad est assez bon marché: http://www.ti.com/ww/en/launchpad/stellaris_head.html

Il est programmable via USB, des chaînes d'outils gratuites sont disponibles pour au moins Windows et Linux, mesurent environ 4 × 6 cm et ont plus de 30 broches GPIO (si je compte correctement).

Vous pouvez intégrer la carte CPU x86 power pc dans votre application robotique à l'aide de l'AVR pour contrôler les lecteurs du robot en tant que carte d'interface. La solution la plus rapide et la moins chère de votre problème. Mais oui, vous devez gâcher beaucoup de codage dans l'architecture x86, mais heureusement, vous pouvez saisir beaucoup de codage à partir de codes de système d'exploitation open source. (Si votre construction mécanique peut supporter ce poids)