Étape 8: Architecture et programmation
Si je pouvais ont chassés LEDs chaque Conseil de microcontrôleur local, l’architecture, que j’ai choisi a la chaîne de LED et les capteurs complètement séparés. C’était pour une raison très pragmatique : si pour une raison quelconque, je ne pouvais pas les capteurs ou multiprocesseur communication travail, Eh bien, j’aurais encore un écran sphérique parfaitement grand ! En tout état de cause, tout a fonctionné bien. Un inconvénient de cette architecture, c’est qu’il a besoin d’un ordinateur central pour conduire les LEDs en réponse aux événements de capteur (par opposition à une architecture locale où microcontrôleur chaque Conseil pourrait voyants le local avec aucune communication de données nécessaire). J’ai choisi un Pi framboise car je savais que les pilotes de la série gérer ma communication haut débit et non-standard 250 kbaud Eh bien, ce n’est pas le cas avec la plupart des systèmes Linux. Contrairement à la BeagleBone il a aussi 4 ports USB, donc j’ai pu connecter l' interface série RS-485 et le Conseil de Fadecandy qui anime les LED, ainsi qu’un dongle USB wifi sans une plaque tournante. Cela est crucial car ce type d’engin finalement doit s’intégrer à l’intérieur évidé de la base.
Ainsi, l’architecture générale fonctionne comme ceci : l’ordinateur hôte (Raspberry Pi) à plusieurs reprises interroge chaque PCB pour ses valeurs de capteur de manière alternée. Parce que chaque PCB s’allume uniquement de son capteur IR LEDs en réponse à une requête, les optiques Diaphonie entre canaux est éliminé. Après que l’état de tous les capteurs sont lus, le modèle de LED est calculé en réponse et expediee OPC au Conseil de Fadecandy.
J’ai encore beaucoup de travail à faire sur la programmation et l’interactivité : en ce moment le Ommatid s’exécute un programme de test glorifié écrit en Python. À l’avenir je vais mettre la requête de capteur et code de génération de LED dans des processus séparés afin d’améliorer les temps de latence et je pourrais mettre dessus et séparent les sphères du bas sur bus RS-485 à double débit. J’ai aussi des idées courageuses (et certains progrès dans la simulation) sur la détection des gestes plus sophistiqués tels que pincement et globe-filature (pour la réactivité de type trackball) ainsi qu’en utilisant le graphique de connexion permettant de simuler des schémas réactifs. Si je peux calculer le laplacien sur le maillage triangulaire, je peux simuler l’équation d’onde et les modes de réaction-diffusion en réponse au toucher. Je voudrais également enquêter sur faire la Ommatid génère des événements de la CVMO donc il peut être utilisé comme un contrôleur de musique. Imaginez un spectacle où Ableton est contrôlée avec un Ommatid plutôt qu’un ordinateur portable !
