La version 4.0 du « Projet Armadeus » a vu le jour ce samedi 9 Juillet 2011. Pour rappel, le « Projet Armadeus » a pour objectif de faciliter le développement de systèmes embarqués à base de Logiciels Libres. Il est basé sur la combinaison logicielle suivante : U-Boot, Linux et Buildroot / Busybox / µClibc.
Le projet est « alimenté » par deux entités :
- l'association Armadeus Project, qui fournit un support bénévole aux particuliers et aux écoles / universités ;
- la société Armadeus Systems, qui conçoit la majorité des cartes électroniques utilisées par le projet et fournit un support commercial aux entreprises désirant développer des solutions embarquées sur base Linux.
Les modules embarqués (APFxx) pris en charge par le projet sont sur base architecture ARM + FPGA, permettant à ceux qui le souhaitent d'améliorer leurs compétences, aussi bien en développement logiciel, qu'en développement matériel (conception électronique numérique).
Les nouveautés majeures de la version 4.0 sont :
- l'ajout de la prise en charge du module APF51 (i.MX51 @ 800Mhz + Xilinx Spartan6) et sa carte de développement APF51Dev (écran tactile, Bluetooth/WiFi, Ethernet, USB High Speed Host/Device, Ethernet, Audio In/Out, RS-232, HDMI, ADC/DAC, bus CAN ; GPS et MoDem 3G en options) ;
- le support de Buildroot 2010.11 ;
- des corrections de bogues.
Aller plus loin
- Le wiki du projet (540 clics)
- La version armadeus-4.0 sur SourceForge (127 clics)
- Le module APF51 (268 clics)
- Annonce de la version 3.4 sur Linuxfr (37 clics)
# Robotique ?
Posté par Nicolas Boulay (site web personnel) . É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é"
[^] # Re: Robotique ?
Posté par Fabrice Mousset (site web personnel) . Évalué à 5.
C'est dans ce cas de figure que l'utilisation du FPGA est intéressante.
Il suffit de créer les modules VHDL/Verilog (selon les affinités) pour réaliser les opérations courante:
- un module pour réaliser la lecture des CAN
- un module pour réaliser le filtrage des mesures (par exemple moyenne glissante ou éjection des valeurs min et max)
- un module pour la sortie en PWM
- un module qui va créer autant d'instance du module CAN + Filtrage qu'il y a de voie à lire et de modules PWM qu'il y a de moteurs à commander.
La magie de la logique programmable faisant que le tout se fera en parallèle et sans consommation de ressources CPU.
De plus, il existe, pour le projet Armadeus, un module VHDL standard qui permet de lire et d'écrire dans valeurs entre l'iMX et le FPGA.
Ainsi toutes les mesures des capteurs sont présentes à chaque instant pour le traitement informatique des données.
Bien entendu, tout cela c'est du travail, ça ne se fait pas en 5 minutes. Cela demande de l'investissement et des compétences VHDL/Verilog et informatique, mais c'est tout à fait envisageable. Et les compétences peuvent s'acquérir ;-)
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Fabrice Mousset (site web personnel) . Évalué à 4.
Je crois qu'on s'est pas compris, je vais être moins synthétique dans ma réponse.
Pour moi, la carte APFxx avec sa combinaison processeur ARM + FPGA peut très bien répondre à ton besoin (désolé je me permet de te tutoyer, c'est plus fort que moi ;-) ).
Je m'explique:
1. Les CAN (Convertisseurs Analogique/Numérique)
En général, ces composants disposent d'interface de communication logique (I2C ou SPI). Pour gagner en temps de traitement, je suggère de brancher le lien SPI/I2C sur le FPGA et de créer les modules VHDL suivants:
- un module qui va gérer le dialogue SPI/I2C (envoi/réception de trames), le plus simple étant aussi de voir ce qui existe sur OpenCores (www.opencores.org)
- un module qui va gérer le dialogue avec le circuit CAN (lecture/écriture des registres du CAN)
- un module qui va gérer la lecture en continu des résultats de conversion
- un module qui va filtrer les mesures brutes pour les rendre exploitable du point de vu logiciel
2. La commande moteur (PWM)
Pour cela, il suffit de créer un petit module VHDL qui va gérer la sortie PWM sur un GPIO, et puis faire l'adaptation électronique derrière (MOS de puissance par exemple) et d'attaquer le moteur avec cela.
3. Traitement logique
Là c'est le processeur ARM qui va entrer en jeu, c'est lui qui va, faire tout le traitement informatique, pour cela, il a juste à récupérer les données du FPGA via un module VHDL et un peu de soft.
Pour simplifier cela, il existe le projet POD (Peripherals On Demand) regarde ici pour plus de détails => http://www.armadeus.com/wiki/index.php?title=Using_FPGA
En bref, le FPGA va s'occuper de lire/filtrer les mesures CAN en continue et il va également s'occuper de gérer la commande des moteurs. Il suffit de créer autant d'instance des modules CAN et PWM que nécessaire.
Le processeur ARM va lui s'occuper de gérer les interaction à l'aide des différentes données récupérées par le FPGA.
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le problème c'est fabriquer la carte fille qui va avec, la fabriquer soi-même n'est pas simple.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Fabrice Mousset (site web personnel) . Évalué à 1.
Ca c'est un tout autre débat.
Quelque soit la solution retenue, il faut passer par une carte d'adaptation pour faire le lien entre la partie CPU et les actionneurs.
Dans le cadre du projet Armadeus, tu disposes d'une carte CPU relativement souple et musclée, il ne reste plus qu'à s'attaquer la partie adaptation.
Le plus gros problème étant les connecteurs intercartes parce que relativement dense, mais pour le reste, toute la partie sensible (CPU + DDR + Flash + FPGA) est déjà opérationnelle, il manque qu'une alimentation 5V pour faire fonctionner tout ça.
C'est pas forcément à la portée de tout le monde, mais si tu t'attaques à un projet de robot, je pense que tu disposes d'outils en conséquence?!?
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Disons qu'une tel carte n'est pas aussi simple que ça du tout. Je voulais signaler aux auteurs du potentiel d'une tel carte fille, en plus si il y a des drivers linux, c'est encore mieux :)
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Fabrice Mousset (site web personnel) . Évalué à 3.
Là je suis perplexe!
Je ne comprends plus ce que tu recherches... Tu cherches à construire ton robot toi même où est-ce que tu cherches quelqu'un qui va te construire un robot?
L'association Armadeus compte actuellement presque 300 membres, je pense qu'il est tout à fait envisageable de réaliser ton projet de robot à l'intérieur de l'association. De monter en quelque sorte un "groupe de travail".
Dans l'association, il y a aussi bien des "softeux" que des "hardeux", il ne tien qu'à toi de fédérer une partie de ce monde là pour mener ton projet à bien.
Ca veut dire créer un cahier des charges / synoptique avec ce que tu cherches à réaliser. Tu peux utiliser pour cela le Wiki d'Armadeus pour présenter ton projet et le canal IRC + la mailing list pour recruter des personnes pour t'aider à mener à bien ton projet.
A coté de Armadeus Project, il y a également la société ARMadeus qui peut apporté un peu de soutien pour la conception de la carte électronique (à voir avec Nicolas Colombain ou Julien Boibessot), mais il ne faut pas non plus aller imaginer qu'elle va tout faire pour toi. Elle mets déjà à disposition l'ensemble du BSP Linux, les schémas électronique des cartes et des outils pour le FPGA, c'est déjà beaucoup, sans parler des cartes elles même à prix coutant!
Bref, le potentiel est là, c'est à toi de savoir l'exploiter et de t'investir pour le mener à bien.
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je n'ai pas le courage de me lancer dans ce genre de projet. Je voulais juste signaler qu'une telle carte pourrait intéresser beaucoup de monde: Tout ceux qui veulent faire de la robotique un peu costaux (nao, c'est un pc via connecté à un µp pour contrôler les servo-moteur).
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Ph Husson (site web personnel) . Évalué à 1.
Euh ... Un groupe qui a les moyens de se faire un nao du point de vue mécanique, ont les moyens de se faire une carte avec un bon gros FPGA avec 1000 I/Os
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu sais combien ça coute un FPGA avec 1000 ios ? Et le prix de la carte pour le poser dessus ?
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Ph Husson (site web personnel) . Évalué à 1.
Et tu sais combien coùtent les 50 moteurs de nao ?
[^] # Re: Robotique ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Les cartes ARMadeus sont composées de deux parties, la partie proc+fpga (apf9328, apf27 et apf51) et la partie carte d'accueil.
Pour ceux qui on les moyens techniques de fabriquer des cartes, la carte cpu+fpga est très intéressante car ils disposent d'une base avec une distribution linux fonctionnelle et peuvent l'adapter à leur besoin en réalisant une carte d'accueil.
Sinon, ARMadeus propose des cartes d'accueil de développement avec tous ce que tu recherches (CAN, IO, spi, i2c, PWM, uart) et si tu manques de PWM ou d'uarts elle peuvent être ajoutée dans le fpga sans problème (je ne m'aventurerais pas à dire que l'ajout du CAN dans le fpga se ferait sans problème, je n'ai jamais testé, mais ça doit pouvoir fonctionner).
Le FPGA est un outils royal pour faire de la génération de signaux temps réel, notamment pour générer les pulses de contrôle de servomoteur, les timings peuvent être réglé avec une précision de l'ordre de la dizaine de nanosecondes avec un vrai temps réel puisque les process s'exécutent en parallèle.
J'ai plus qu'une balle
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je me doute bien qu'il y a des cartes filles, je me demandais si il y avait une carte fille avec ce genre d'IOs, car faire ce genre de carte avec des pas fin n'est pas facile du tout.
Les CAN ne s'ajoutent pas à un FPGA, bien qu'il soit possible d'en faire un avec un comparateur externe en plus, ce n'est pas si précis.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par SebastienV . Évalué à 0.
Si tu peux les connecter au FPGA. Un convertisseur A/D série SPI marche nickel.
C'est un FPGA, pas un microcontrôleur. Rien ne t'empêche d'avoir une fréquence d'horloge pour le convertisseur très élevée, genre 50 MHz pour des convertisseurs 2x1MSPS.
Tu fais les conversions avec un ADC SPI connecté au FPGA, et tu génères les PWM avec le FPGA.
Si nécessaire, tu mets les régulateurs dans le FPGA ça te permet de réduire la latence au niveau de la régulation et le CPU ne te sert plus qu'à échanger des consignes et à la communication...
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
je crois qu'il existe des CAN à bus parralèles avec plein d'entrés, cela serait plus simple pour les lires. Je ne suis pas sur qu'une sorte de DMA pour SPI soit si simple et suffisamment petit pour en mettre plein.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par SebastienV . Évalué à 1.
Oui, parallèle ou série, même combat. Quant à la taille du composant dont tu parles c'est quelques centaines de portes... Pas de quoi fouetter un chat...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.