- Ce sujet contient 13 réponses, 3 participants et a été mis à jour pour la dernière fois par , le 20 Oct. 2015, 08:46.
-
Messages
-
Bonjour. Je vais m’attaquer à l’animation (pour faire le show) de mon R2. On le sait, il ne faut surtout pas utiliser l’instruction “delay”
J’aimerai savoir s’il y a une pseudo norme pour le stockage de la séquence de l’animation ? Je n’ai rien vu sur le sujet mais j’ai peut-être raté un truc.
Avez-vous un hommage particulier de vos différents éléments participants à une animation ? (PSI avant off, panel 5 à 30%, LDP full blue, etc…)
Est-ce que dans vos séquences, vous pouvez appeler une autre séquence ? Genre : à 830 ms jouer la séquence pin-pon.
Autre sujet : le stockage de ces animations. Tout en mémoire dans le sketch arduino ? Utilisation d’une carte SD avec des fichiers ascii ou binaire ?
Attention : écriture en même temps que la réflexion… donc s’il manque des mots ou que ça n’est pas compréhensible, bah c’est normal
😆 J’imagine déclencher une animation, genre la 12. (via radiocommande ou smartphone)
DEBUT
Un arduino qui reçoit cet ordre lit le fichier “animation##.bin” sur une carte SD.
Puis il décortique l’animation en lisant le fichier au fur et à mesure. Une animation = un ensemble de séquences, chaque séquence s’exécute à un timing donné. (les séquences sont dans l’ordre)
Lecture de la premier séquence depuis le fichier
BOUCLE
attente du délai pour déclencher la séquence (sans l’instruction delay
Pour chaque séquence de l’animation, cet arduino envoi sur un réseau I2C (broadcast) propre à R2 ce qu’il faut faire (la séquence).
Il exécute alors lui-même la séquence s’il est concerné.
Cet arduino lit alors la séquence suivante… si on est pas à la fin du fichier, boucle à “BOUCLE”.
Cet arduino peut éventuellement recevoir le déclenchement d’une autre animation pendant que l’animation 12 est en cours. Auquel cas il arrête la séquence en cours et va à “DEBUT”.
Un autre arduino reçoit une séquence via I2C
Il exécute alors lui-même la séquence s’il est concerné.
Autre question, le timing : vous tournez à la ms, à 10 ms, à 50 ms ??? (genre la séquence 12 s’exécute 3 x 50ms plus tard que la séquence précédente)
Sujet ouvert, je suis preneur de vos l’ensemble de vos trucs & astuces ! (éventuels liens si vous en avez, ou exemple de codes)
Mes strokes sont tous stockés sur la SD de ma carte Mp3. Je voulais être capable de “reprogrammer” le comportement de mon droide à la volée en ayant juste un éditeur de texte sous la main.
J’ai un fichier texte comportant une rubrique par stroke contenant le code d’enchainement des commandes définissant le stroke (un peu comme les .ini à l’ancienne…).
J’ai défini un pseudo langage de description des commandes : tourner dome, jouer son, pause, déclencher séquence lumineuse, etc…
Cela marche bien dans le cadre de mon utilisation, ce n’est clairement pas aussi évolué que le pseudo langage “JEDI” de Scott, mais ça pourrait te faire une base de départ si tu veux que je te passe le bébé
Appelle moi quand tu as un créneau, je déterrerai mon code, ce qui ne me fera pas de mal Pour le déclenchement des séquences, de mémoire je triche un peu puisque le code qui pilote les displays est issu du code de BHD…
J’ai simplement ajouté à son code l’échange I2C nécessaire au déclenchement des séquences depuis l’arduino maitre situé dans le corps… (+ gestion des trappes)
Il faut que je mette à jour mon code avec le dernier code de BHD, notamment pour ce qui est du pilotage des trappes car j’avais écrit à la va-vite un code destiné à contrôler la vitesse des servos, mais ça ne vaut pas les librairies spécifiques qui existent…
Bien reçu Entre ça, le code de BHD et le code de curiousMarc et d’autres, j’ai de quoi m’occuper (comme si je manquais d’activité…)
Merci.
OK, j’attends que tu aies fini 🙄 Bonjour Xoff, Je suis aussi intéressé par ton code (et surtout par ton pseudo language) juste pour analyser ce qui existe à côté.
Tchao,
Mike
je te (vous) propose qu’on y réfléchisse un peu avec Boris, on aura sûrement quelques idées d’amélioration et nous mettrons le tout à disposition de la communauté Quelques références sur le sujet: * Code arduino de BHD (Big Happy Dude)
https://drive.google.com/folderview?id=0B5B8A65frsBgZDJaSlFYSW1CR0U&usp=sharing ” class=”bbcode_url”> https://drive.google.com/folderview?id=0B5B8A65frsBgZDJaSlFYSW1CR0U&usp=sharing * Command reference par CuriousMarc
http://www.curiousmarc.com/dome-automation/marcduino-firmware/command-reference ” class=”bbcode_url”> http://www.curiousmarc.com/dome-automation/marcduino-firmware/command-reference * Proposition de convention de nommage par Lord Hotwing
http://astromech.net/forums/showthread.php?23920-Code-Naming-Convention-Standards ” class=”bbcode_url”> http://astromech.net/forums/showthread.php?23920-Code-Naming-Convention-Standards Avec une feuille excel :
https://docs.google.com/spreadsheets/d/1jU59gMMt6kwzYjs1u39qM50ZO2a2uKEcanWTolG2awY/edit#gid=0 ” class=”bbcode_url”> https://docs.google.com/spreadsheets/d/1jU59gMMt6kwzYjs1u39qM50ZO2a2uKEcanWTolG2awY/edit#gid=0 Et une numérotation “officielle” concernant le dôme :
[img]http://astromech.net/droidwiki/images/a/a0/Dome-Panels.jpg [/img] Perso je pense qu’il faut faire “compact”. Je ne suis pas trop pour le format texte… ou au plus en version ‘char’, c’est à dire sur 1 octet / 8 bits. Un peu comme Curious Marc avec ‘:’=pie panel ou ‘*’=HP et de l’hexa quand on doit mettre des nombres.
Compact car :
– permet de courts messages lorsqu’il y a de la communication (I2C ou autre)
– nos Arduino n’ont pas beaucoup de mémoire
Côté communication, je pense que cela est totalement négligeable J’avais par contre également codé les commandes sur un nombre minimal de caractères à cause de la capacité mémoire réduite des arduinos (ça fait d’ailleurs longtemps que j’ai abandonné les arduinos de base au profit du méga…)
Mais j’ai préféré coder avec les initiales des accessoires à commander (par exemple D pour dome), car des caractères alphanumériques style * ou : ne sont pas au top niveau mémotechnique…
je ne suis pas allé jusque là les séquences lumineuses du dome sont déjà codées dans le code de BHD, donc j’ai une simple commande H pour envoyer une commande à l’arduino du dome
puis cette commande prend un paramètre comme suit :
ob : open dome bottom panels
ot : open dome top panels
cb : close dome bottom panels
ct : close dome top panels
wb : wave dome bottom panels
wt : wave dome top panels
d1 : display Pacman
d2 : display Love
je n’ai pas poursuivi, mais l’idée est là, après on peut aller plus loin comme tu proposes, pourquoi pas, mais dans tous les cas il te faudra des primitives codées en dur, il faut déterminer jusqu’à quel niveau de contrôle tu veut le placer dans le fichier de config…
tu peux aussi jeter un oeil au langage JAWA des JEDI Display, je suis certain qu’il doit y avoir des idées intéressantes.
dans les exemples que tu donnes, on est carrément plus dans le mémo technique. ob, d1, … du coup que ce soit lisible n’est plus forcément vrai.
Je me dis que ce qu’il faudrait c’est un programme qui génère ce code, un programme graphique, visuel… noooooonnnn, je n’ai pas le temps !!!!!
je t’ai donné juste l’idée du concept, l’implémentation que j’ai faite était à une semaine de CE2 dans l’urgence, donc effectivement pas forcément super adaptée mais c’est un détail
- Vous devez être connecté pour répondre à ce sujet.