Au programme et à compléter : une approche de l’Objective-C pour IPhone en comparaison avec l’AS3… c’est ici

Comme beaucoup l’ont découvert, le petit bijoux de Nintendo, sa console Wii, est une mine d’inspiration technologique, et démocratise des éléments qui jusqu’alors n’étaient que confidentiels. Par exemple, les interfaces de déplacement, utilisent des capteurs infrarouges et des accéléromètres, qu’il est tout à fait possible d’exploiter. Résultat, pour 19 euros environs, vous pouvez acheter un “Nunchuck”, une des manettes de la console, et vous vous obtenez : un accéléromètre 3 axes, un microswith, un micro joystick, le tout sur une interface avec codage I2C et éventuellement si vous la conservez, une coque à l’ergonomie remarquable.

Le plus intéressant dans mon cas, se sont l’accéléromètre, et la possibilité de sortie du signale en I2C. I2C, signal inventé par Philips (1²C pour Inter Integrated Circuit Bus) pour ces utilisation domotique, utilise deux câbles pour sérialiser l’information : un câble avec le flux Data, est un câble pour l (horloge de référence.

Pour un Nunchuck par exemple, nous avons donc 4 câbles :

Rouge pour le +3V;

Blanc pour la masse;

Vert pour le bus Données;

Jaune pour le signale horloge de référence.

A partir de cela, est sachant que l’arduino et capable sans problème de gérer ce genre de signale (il existe même une librairie pour l’I2C spécial, issue des source pour la carte WIRING)…récupérer le signal de l’accéléromètre est un jeu x d’enfant.

Je pense que c’est ce type, qui le premier à utilisé cette solution, est il explique en détail sa procédure sur ce site, et donne également des exemples de code pour l’arduino.

Je posterais un peux plus tard le code que j’utilise actuellement pour le traitement des données de l’accéléromètre.

Malheureusement, l’accéléromètre n’est réellement efficace que sur l’axe des X et Z. Si l’on prend comme référence ce système d’orientation :

Dommage pour nous, ce qui nou interesse, c’est justement l’axe Y en priorité, et l’axe X. Le Z ne sera exploité que dans une version ulterieur, exploitant les 3 axes ( l’inclinaison gauche/droite, qui utilise l’axe Z, est moin indispensable que la rotation gauche/droite pour se situer dans un environnement…)

La solution, est donc d’adjoindre à l’accéléromètre du Nunchuck, un gyroscope basique pour récupérer l’axe Y. Le gyroscope référencé sur un Nord magnétique hypothétique, a lui, toutes les capacités pour récupérer les données d’orientation par apport à un point de référence. J’avais, dans un premier temps, pensé utiliser les petits gyroscope que l’on trouve sur les modèles d’hélicoptère RC, car dans les sous produit chinois, certains sont accessibles à des prix réellement bas (on trouve pour moins de 15 euros des gyros acceptables). Malheureusement, après des tests, il s’avère que ce genre de gyro, possède un fonctionnement particulier, adapté à leur fonction, c’est à dire la correction de cap, et ne réagissent qu’à l’impulsion et retourne au point central après détection de la variation….

Donc, au final, un petit gyroscope de ce type, Module boussole “CMP03″, commercialisé par exemple par Lextronic règle le problème….malheureusement avec un grève ment du budget non indolore…..

Si l’on fait le compte : 19 euros pour l’accéléromètre du nunchuck, plus 45 pour le module MS03….64 euros pour le module de tracking. C’est encor raisonnable mais on se retrouve à la limite des ambitions de matériels prix plancher….

Le Nunchuck fournira également, le micro switch pour l’initialisation du modul de tracking. Chaque initialisations devrait pallier au problème de dérive et de choix de la position initiale de l’utilisateur.

L’arduino est utilisée pour traiter le signale et ainsi il reste toujours la possibilité de changer l’interfaçage. Le signale en sortie peux être maintenant codé sur des trames différentes : une sortie des données en série sur 8 bits (par exemple pour un driver sur un périphérique physique…joystick, pad,….), une sortie ppm (pour un codage type télécommande RC,….un post-traitement sur une trame propriétaire…..

Dans le cas présent, et pour une interface délivrée des contraintes de câblages, le choix d’une solution de codage en ppm s’impose pour l’efficacité et la praticité des télécommandes RC. Une solution de type Xbee, pour une transmission radio aurait pue être envisagé, mais l’utilisation du transfert du signal vidéo en 1.2 ou 2.5 GHz pose quelques problèmes de brouillage potentiels.

Le principe est donc de découper le signal en pulsations compatible avec les systèmes des télécommandes RC, pour mixer le signal. J’ai à ma disposition, deux télécommandes 6 canaux, de marques connues et possédant chacune une prise pour l’écolage)

Une FUTABA T6EXP :

ainsi qu’une SANWA RD6000Sport :

Grace à ces deux sites, j’ai récupéré beaucoup d’informations pour le mixage des données d’écolages des télécommandes :

Sur ce site des tas d’information concernant le cablage des télécommandes ->

sur le forum arduino, cet utilisateur à mixé un signal en ppm sur une télécommande Multiplex ->

Pour simplifier, les signaux ppm des télécommande sont sont constitués d’impulsions réparties sur environs 22 m-secondes, avec 2ms environ par voie. par exemple une impulsion d’1ms indique un positionnement minimum, 1.5ms est la valeur médiane, 2ms la valeur maximum (en fait chaques constructeurs semble avoir ses propre durées et référence : par exemple pour futaba, la norme semble plutôt être 0.7, 1.2, 2.4 ms…). après les 22ms une pause et effectué, pour indiquer le changement de trame.

Voila pour la théorie.

Dans la pratique,…..je n’arrive pas à réaliser la connection !!

Les deux télécommandes ont des connections totalements différentes :

la Futaba utilise un format propriétaire de fiche carré :

et la Sanwa une Dine standard, avec la masse sur la partie métallique externe :

Sur le cite précédent, les chémat de cablage sont données pour les deux télécommandes :

et sanwa :

Brochage de Sanwa vu du coté d’accouplement de la fiche femelle :

1 = ??
2 = Ground
3 = OUT
4 = +V switched
5 = IN

——

——————-

Le problème :

Après plusieurs tentatives, impossible de faire communiquer les deux télécommandes, ou de mixer un signal en entrée !!!

Dans le cas d’un signal en entrée, j’ai réalisé des tests avec ce code minimal, à partir de l’arduino, qui envois en sortie un des impulsion sur une voix, pour déplacer un servo d’une valeur donnée.

la solution d’envois d’impulsions via l’arduino :

Le code C / arduino :

////////////////////////////////////////////////////////////
////////// CODE TEST ////////////////////////////////
////////////////////////////////////////////////////////////

int servoPin = 3; // Control pin for trainer interface

int pulseStart = 800; // pulse start width in microseconds
int pulseMin = 500; // pulse minimum width minus start in microseconds
int pulseMax = 2500; // pulse maximum width in microseconds
int conversionFactor = (pulseMax – pulseMin – pulseStart)/180;

int frameLength = 20; // The duration in millisecs of a frame

long lastFrame = 0; // The time in millisecs of the last frame
int channelNumber = 3; // Number of channels to send
int servo[3]; // Values to set for the servos in degrees
int channel[3]; // Values to send on channels (duration of pulse minus start, in microseconds)
int i; // Counter in for loop
int j = 0; // Counter for servo updates

void setup() {
pinMode(servoPin, OUTPUT); // Set servo pin as an output pin
Serial.begin(9600); // connect to the serial port
for ( i = 0; i < channelNumber; i = i + 1 ) {servo[i] = 0;}
for ( i = 0; i < channelNumber; i = i + 1 ) {channel[i] = pulseMin;}
Serial.println(“Trainer_PPM_Interface ready”);
}

void loop() {

// Save the time of frame start
lastFrame = millis();

// This for loop generates the pulse train, one per channel
for ( i = 0; i < channelNumber; i = i + 1 ) {
digitalWrite(servoPin, LOW); // Initiate pulse start
delayMicroseconds(pulseStart); // Duration of pulse start
digitalWrite(servoPin, HIGH); // Stop pulse start
delayMicroseconds(channel[i]); // Finish off pulse
}
digitalWrite(servoPin, LOW); // Initiate synchronisation pulse
delayMicroseconds(pulseStart); // Duration of start of synchronisation pulse
digitalWrite(servoPin, HIGH); // Stop synchronisation pulse start

// wait for the next frame
while (millis() – lastFrame < frameLength) {
delay(1);
}
}

////////////////////////////////////////////////////////////
///////////////////////////FIN DU CODE /////////////////////

///////////////////////////////////////////////////////////

Avec l’arduino, je pilote directement les servo avec ces systèmes d’impulsions et ce type de code, donc pas de doute de ce coté, le signal est bon, compatible et bien étalonné. (J’ai d’ailleurs vérifié avec un oscilloscope basique, la forme du signal, et tout semble parfait, dans la norme des 22ms..)

pour simplifier après avoir tester des solution avec envoie d’impulsions via l’arduino, jai tenté de réaliser une simple connection type écolage entre les deux télécommandes…dans le paragraphe suivant->

la solution de liaison écolage entre les deux télécommandes :

Pour faire des tests et repartir du problème à la base, j’ai tenté de raccorder les deux télécommandes en écolage, avec les deux options possibles : soit la Futaba en maître, soit la Sanwa en maître….

les solutions cablâge testées :

Sans succès ! Aucune réaction dans tout les cas. Pas la moindre réaction de mixage sur la voix. Les deux marques peuvent, il est vrai être incompatibles. J’ai, il me semble vu quelques réserves sur la futaba FX6, qui ne serait pas normalisé au niveau des pulsations, et ne serait compatible qu’avec une autre futaba.

L’idéal serait bien sûr, d’avoir deux télécommandes identiques pour tester….

…….. à suivre

Cette vidéo illustre l’éfficacité du filtrage. :

Finalement, après de multiples hésitations, comparaisons, recherches, il semblerait que ce modèle de lunettes vidéo se prête tout à fais à une utilisation de type immersive : une résolution relativement élevée de 640X320 px pour un prix très faible d’environs 120 euros.

Le référence : EGV920V 80″.

Toujours pareilles, les caractéristiques semblent élogieuses, mais sont largement à relativiser. Entre autres, la notion de taille d’écran virtuel est complètement suggestive, et la première déception peux venir justement de l’angle de vision, qui bien sûr n’est pas totalement celui de l’oeil humain. Même si la sensation de taille d’image peut être là, la perception de la zone noire peut fortement nuire à la tentative d’immersion. Heureusement, ce sentiment est fortement accentué en perception active (avec une caméra, physique, ou virtuelle), contrairement par exemple à la contemplation passive d’une image vidéo, ou le regard peut continuellement se perdre ou se laisser aller à des va et viens entre la “bordure écran” et la zone image.

aractéristiques :

Taille virtuelle de l’écran: 80 “ (203cm)

Résolution: 640 x 480 (VGA)
Angle de vue : 35° en diagonale

Couleur : 24 bits

Entrée signal vidéo: Composite AV commutation automatique Pal / Ntsc / Secam

Son stéréo – Volume réglable
Batterie lithium intégrée 1000mAh (batterie standard mobile Nokia)

Faible consommation d’énergie

4 heures d’utilisation en continu après une charge complète
Adaptateur secteur: 5V DC / 500mAh

Certes….ça n’évoque pas particulièrement l’intelligence, mais bon……..

Pour test et avant d’investir sur des systèmes plus performants, mais dont les prix montent de façon exponentiels, j’utilise un modèle bas de gamme de caméra disponible sur Ebay :

TV Color System: NTSC/ PAL
Validity Pixel: NTSC – 510×492, PAL – 628×582
Horizontal Definition: 380 Lines
Operation Frequency: 2.4GHz
Minimum Illumination: 3 Lux
Focus: Manual adjustable from 30 mm to Infinity
Horizontal Viewing Angle: 50 Degree
Effective Range (line of sight): 300 ft to 1,000 ft
Voltage: 9 -12V DC
Output: RF
Size: 25x35x15mm
RF Power: 200mW
Receiver Specifications 2.4Ghrz

Les caracteristiques sont largements sur – évaluées, et on ne doit pas attendre un résultat satisfaisant avec ce genre de matériel, mais pour moins de 30 euros, et pour une évaluation c’est parfait.

Ce type de caméra n’atteint pas les capacités de caméra ccd, mais avec le système d’immersion la résolution peux passer. Ce qui pêche à mon avis, c’est plutôt les capacités de réceptions et de transmission. Pas encore testé en grande envergure, mais pour sûr, la distance des 150 m.…c’est à voir.

La rotule d’orientation :

Un système “bidouille” de fixation. Ici le système est arrimé à un petit châssis fait à partir de matérièl de récupération, qui me sert pour mes tests de déplacements autonomes en programmation. La rotule utilisée est une version économe, jouant uniquement sur 2 axes. Le 3ème axe est à mon avis secondaire à ce niveau d’avancement du projet.

2 servos RC basiques, montés à 90°, avec des cornières en alu et des petits roulements, pour un peu plus de souplesse. Ca fonctionne pas mal, si ce n’est une élasticité imprévue des cornières alu, qui peux parfois amplifier les micro – déplacements des servos… et créer un problème de tremblements. A régler.

Le suivi est lisible ici ->

Comme le démontre continuellement, et depuis maintenant longtemps Patrick Blanc, star en la matière, la culture hors sol et dans des substrats artificiels et sur des zones verticales, de végétaux, et chose plutôt simple et facile à gérer.

Partant de cette idée j’ai décidé de créer “mon petit mur” intérieur avec des matières basiques….le problème, c’est que je suis loin d’avoir l’once d’une parcelle de connaissance en botanique. Donc au petit bonheur la chance pour cette tentative.

Le principe :

Un support en pvc recouvert de deux couches de tissus à base de filaire synthétiques jouant le rôle de substrat, un circuit d’eau fermée avec programmation des temps d’irrigation.

Arduino, petit module à base de micro-processeur type AVR 128 avec interface de programmation en C et connection usb. Avec un prix de revient très faible, et un environnement Open-source, il permet de jouer le rôle d’interface (gérer…) entre les élément physique et les gestion programmées. Une batterie de capteurs peuvent donc être utilisés.

De base, une carte type Arduino avec inteface usb peut être obtenue pour environ 23 euros.
Le processeur AVR Atmega (avec le boot intégré) peut lui obtenue pour seulement 5 euros environs.

Des version minimales de clone de l’Arduino peuvent donc être envisagées (pour des version multiples ?) sans investissement consequents. cf. freeduino et autre clones...

Plus besoin de programmation en bas-niveau type assembleur ou d’interface de programmation propriétaires couteuses pour micro-pic.