Re: Petites précisions

Pour voir les posters de l'année 2006, tu peux suivre le lien que j'ai donné plus haut, rubrique posters. Mais c'est vrai que pour atteindre cette page, il faut la chercher.

Gérer des puces qui communiquent à haute fréquence n'est pas facile du tout, et en général ces puces n'existent qu'en packages quasi impossible à souder sans materiel adéquat (et le coup de patte). C'est sûr que ce serait bien d'avoir ces designs à disposition, surtout pour l'industrie, mais la plupart des équipes à la coupe ne pourront pas les réaliser eux même: ils devront le sous traiter. Je ne suis pas sûr qu'on gagne vraiment en prix, et s'il y a un problème sur la carte, cela risque d'être délicat à réparer.

Si tu veux des cartes avec des processeurs assez puissants, il en existe à qqs 100aines d'¤. Par exemple les classiques EPIA, ou des cartes à base de Geode, ARM, Coldfire, Blackfin, ... ou même processeur+fpga. Il suffit de fouiner sur le Net. Et je pense que cette tendance aux cartes avec processeur 32 bits pour l'embarqué à prix raisonnable ne fait que commencer (et un PC embarqué ou un bon DSP permet de gérer la vision).

Il ne reste plus que l'interfaçage avec les capteurs et actionneurs, ou les montages plus spécialisés comme ton exemple, qui doivent être adaptés au cas par cas. Il pourrait effectivement y avoir une bibliothèque de montages classiques gérée par une communauté. Mais pour ces montages classiques, on peut trouver beaucoup de choses sur les datasheets et application notes des constructeurs; et pour les montages spéciaux... il sont spéciaux ;). Il faut trouver quelqu'un qui a eu le même problème et qui l'a résolu.

Une standardisation des solutions est souhaitable du point de vue des performances des robots (et arrivera plus ou moins à terme, vu que les µC standard pourront petit à petit gérer pratiquement tout), et utiliser des protocoles et schémas bien pensés permet de passer à côté de plein d'erreurs potentielles (et très chiantes). Mais je pense que l'esprit de la coupe est d'apprendre en s'amusant, et en comprenant ce qu'on fait plutôt que savoir intégrer des solutions toutes faites (même si les 2 ne sont pas incompatibles), ou de gagner la coupe. Donc l'idéal est d'expliquer ce que l'on fait, comment on le fait, mais pas de donner des schémas "sur étagère": exactement ce que font les contributeurs du forum.

Un autre problème avec l'électronique, qui est moins prononcé en informatique (si on écrit des programmes portables), c'est l'obsolescence des composants, et leur disponibilité chez les revendeurs. Si tu changes un composant sur une carte, il faut que tu fasses attention à ce que tu fais (sauf s'il est clairement compatible pin à pin). Il faut avoir les compétences pour le faire. Je dirais que ça reviendrait en informatique à modifier le code, pas seulement changer la configuration. Donc une base de donnée de cartes utilisant des composants exotiques n'a de valeur que pour des gens capables de le comprendre et de faire les bidouilles éventuelles nécessaires.
Par exemple, la carte bilda pour gérer des lasers sous Linux ( http://www.linux-laser.org/ ) utilise un µC qui se programme directement par USB, mais qui est considéré comme obsolète par le fabricant, et qui risque de disparaître d'ici qqs années. Il faudra modifier la carte en conséquence avec un nouveau µC.
Quant aux composants classiques, celui qui ne sait pas l'utiliser peut regarder sur le Net, ou poser une question sur le forum de PlaSci ou autre site électronique.

Transposer l'Open source au sens strict à l'électronique (hors schémas pour FPGA/ASIC) n'est donc pas aussi simple que cela. Et autant Eurobot permet de former des gens ouverts au Libre, autant je ne pense pas que ce soit là qu'on crée ou qu'on impose des standards ou des designs Open source.

[ Répondre ]