Pilotes Québec

Je les voit les photos

Je les vois aussi

Parlant d'imprimante 3D, voici une application étonnante

https://www.youtube.com/watch?list=PLKf ... 1yQzqR9cu0" onclick="window.open(this.href);return false;

https://www.youtube.com/watch?v=zb3zuk1qNDk" onclick="window.open(this.href);return false;

elles sont toutes visibles pour moi

Christian

Elles sont à la page 4 ses photos ?

Si oui, je ne les vois pas avec mon ordi ni avec mon ipad.

Jacques3012

Jacques3012 wrote:Elles sont à la page 4 ses photos ?

Si oui, je ne les vois pas avec mon ordi ni avec mon ipad.

Jacques3012

Oui page #4, Je les voit avec mon PC et ou mon Ipad

Louis, t'as raison, c'est une autre application fantastique de la technologie. Ingénieux le gars quand même. Y a des chinois qui impriment des maisons avec la même technologie (je me demande qui a copié qui) et la compagnie a même imprimé sa propre usine de 10000 pi. ca. avec sa technologie:

Même si j'attends encore des vis, fils et autres gugusses, je voulais voir de quoi aurait l'air le bidule avec l'écran en fonction (l'arrière du boîtier n'est pas installé). On voit bien le fini de surface sur cette photo. C'est plutôt inégal mais ça suffit amplement pour un prototype. Je vais me payer une impression sur une meilleure machine pour la version finale et je me félicite d'avoir résisté à acheter un Makerbot pour moi-même. Je suis venu à un cheveu...

Super Charles!

Très impressionnant Charle..j'ai hâte de voir sa

Charles,

Comment se fait la mise à zéro de l'horizon? Je suppose qu'en vol en palier il y a un reset(mise à l'horizon) qque part?
Même chose pour le calage, on entre la valeur comment? Y'as-tu un genre de menu que tu peux appeler à l'écran?

Bravo pour le projet.
Martin (FJAR)

L'écran est tactile. Si on clique sur le calage altimétrique, un menu apparaît pour entrer le nouveau calage (photo) avec des boutons + et - pour simplifier l'entrée. Pour ajuster les offsets de l'horizon si le boîtier n'est pas perpendiculaire à l'axe de l'avion par exemple, il y a une zone sensible sur l'écran qui fait l'équivalent d'un "caging" quand on la clique, c'est-à-dire qui cale l'horizon sur l'attitude actuelle au moment où on clique. Ça applique des offsets sur l'attitude mesurée naturellement par le machin. Si on appuie une deuxième fois sur l'endroit sensible de l'écran, les offsets sont annulés immédiatement (au cas où on aurait appuyé par erreur) -- mais faudrait plutôt que les offsets reviennent à la valeur antérieure, ça serait mieux. D'ici 10 ans, ça sera au point.

L'écran est en anglais, désolé, c'est une déformation professionnelle.

Merci Charles, c'est vraiment extra
Je serai très intéressé à m'en assembler un lorsque tu partageras ta recette si tu le veux bien.
Je suis plus dans la programmation et l'administration UNIX comme avant, mais mes connaissances devraient être suffisantes. Surtout que tu t'es tappé tout le travail.

Martin FJAR

Au fait, s'il y en a qui seraient intéressés à taponner avec un setup similaire, j'ai documenté la procédure de configuration et elle est disponible ici (désolé, c'est en anglais, déformation professionnelle): https://docs.google.com/document/d/1em5 ... sp=sharing" onclick="window.open(this.href);return false;

Charles pourquoi t'excuser de travailler dans un environnement anglais...
Pierre C.

Finalement, les câbles internes sont un problème. Même avec les plus petits connecteurs HDMI que j'ai trouvés, ils sont trop gros et je dois éloigner deux boards de quelques millimètres l'un de l'autre. Je vais en profiter pour utiliser un connecteur mâle-mâle entre les deux board à la place d'un fil. Pas dramatique me direz-vous, sauf que pour faire ça, il faut aligner les connecteurs HDMI des deux boards et les espacer de la largeur du connecteur. En faisant ça, il faut élargir le boîtier de quelques millimètres également. Là, ça se complique et ça va demander pas mal de temps pour repenser le boîtier. Je ne m'attendais pas à ce que tout marche parfaitement du premier coup mais bon, on peut toujours espérer.

Dans le département des bonnes nouvelles, j'ai finalement réussi à calibrer le compas interne et il est maintenant très précis. C'était beaucoup plus compliqué que ce à quoi je m'attendais, ça aussi. Pour ceux qui ont un intérêt pour la chose, la procédure est expliquée à la section 3 et aux annexe À.2 et C de ce document: https://www.pololu.com/file/0J434/LSM30 ... p-note.pdf" onclick="window.open(this.href);return false;

martind2112 wrote:À quel FPS pourrais-tu rouler si tu enlevais tout le number crunching pour ne laisser que l'affichage? 20 FPS me paraît très bas pour la simplicité de l'affichage.

Quel est le graphics API: OpenGL?

Une chose qui tue la performance graphique, c'est les appels DrawPrimitives() qui occasionne du trafic coûteux sur le bus entre le CPU et le GPU. Il est très avantageux de regrouper les primitives semblables (points, line strips, line lists, triangle strips, triangle lists) dans un seul et même vertex buffer.

En attendant mon connecteur HDMI qui est en route de Chine ( http://www.dx.com/fr/p/hdmi-male-to-mal ... FVT5ogrLvs" onclick="window.open(this.href);return false; ), je reviens sur le software. Une des choses que j'avais mises de côté l'an dernier était la question de l'accélération graphique. Il y a 2 microprocesseurs dans le Pi: un CPU d'usage général pour exécuter des programmes et un GPU qui est spécialisé pour générer des graphiques. Le problème était que l'affichage à l'écran n'était pas généré par le GPU comme ç'aurait dû être le cas mais par le CPU, ce qui est très inefficace. En plus de surcharger le CPU, ça donne une performance d'affichage médiocre de 20 images par seconde.

En relisant ce vieux thread, le message de Martin m'a fait allumer. Mon objectif est effectivement de faire du OpenGL mais à travers les API de Qt pour la simplicité donc je ne peux pas être certain de ce qui se passe en-dessous des couvertes (OpenGL ou autre chose?). En lisant davantage, j'ai compris le problème: je dérivais une classe de QWidget, qui utilise toujours le CPU pour générer l'affichage. Il fallait plutôt dériver la classe QOpenGLWidget, qui est essentiellement identique mais elle va utiliser le GPU.

Voilà, problème réglé, je suis à 50 images/seconde ce qui est amplement suffisant. Par comparaison, je suis à 62 fps dans un VM Linux avec un GPU GTX970 alors 50 sur le Pi, c'est excellent.

J'ai essayé d'utiliser un vertex buffer pour voir l'effet sur la performance et ça la dégrade considérablement. Au lieu d'utiliser les fonctions de QPainter, la vraie solution à ça sera éventuellement d'utiliser un programme de shader OpenGL pour dessiner une sphère bleue et brune avec les graduations à l'intérieur et simplement changer l'orientation d'une caméra située au centre de la sphère pour afficher la bonne attitude sur l'écran.

Merci pour la piste Martin, c'est ça qui a fait le déclic.

Louis_greniier wrote:Parlant d'imprimante 3D, voici une application étonnante

https://www.youtube.com/watch?list=PLKf ... 1yQzqR9cu0" onclick="window.open(this.href);return false;

https://www.youtube.com/watch?v=zb3zuk1qNDk" onclick="window.open(this.href);return false;

J'en veux une imprimante de même !!! La cartouche "d'encre" doit être queq'un !!!

toxedo_2000 wrote:

Louis_greniier wrote:Parlant d'imprimante 3D, voici une application étonnante

https://www.youtube.com/watch?list=PLKf ... 1yQzqR9cu0" onclick="window.open(this.href);return false;

https://www.youtube.com/watch?v=zb3zuk1qNDk" onclick="window.open(this.href);return false;

J'en veux une imprimante de même !!! La cartouche "d'encre" doit être queq'un !!!

Moe j.m'imprime une IMA

Theo007 wrote:

Moe j.m'imprime une IMA

Tu devais être scotché sur "Les Dieux de la danse"!!?!