Bonjour,
Je viens d'installer sur mon MACOSX 10.9 le nécessaire pour pouvoir utiliser une kinect (modèle 1473).
Pour l'installation de la kinect et des différentes bibliothèques , j'ai suivi les instructions indiquées sur ce blog : http://blog.nelga.com/setup-microsoft-k … mavericks/.
Cela marche nickel.
Cela se complique un peu lorsque je tente d'utiliser la reconnaissance du squelette avec openni. Cela marche bien pendant 10-20 secondes, ensuite puredata se fige et j'ai le message suivant en console :
Une idée de ce qui pose problème ?
Merci d'avance
version puredata : pd-extended 0.43.4 32 bits
Dernière modification par Système Friche (2014-07-15 08:38:25)
Hors ligne
Salut,
je suis déjà tombé sur ce genre de bug au niveau TclTk, et j'ai pas trop trouvé d'explication.
J'avais pas beaucoup cherché non plus, parce-que j'avais trouvé un contournement : utiliser pd vanilla.
Il faut juste reconfigurer le .pdsettings pour retrouver tes libs.
J'espère que ça peut marcher pour toi...
Hors ligne
OK merci.
Je vais explorer cette solution.
Je vous redonne des news... suite au prochain numéro...
Hors ligne
j'ai désinstallé pd-extended
installé vanilla
juste installé et chargé la librairie GEM
la librairie openni était déjà installée
conclusion :
je n'ai plus le message indiqué dans mon post initial... cool.. merci pour le tuyau ant1r
pour le reste j'avais le même problème : au début j'ai bien mes messages OSC sur la position des différentes éléments du corps (je branche un [print] sur la sortie tout à droite de pix_openni), j'arrive à afficher dans la fenêtre gem la position des différents éléments du corps, mais ensuite plus de message OSC et je perds la main sur puredata plus moyen de basculer en mode édition et lorsque je clique sur un interrupteur l'affichage ne se rafraîchit pas, par contre la position des éléments du corps est toujours affichée dans la fenêtre gem, seule façon de quitter puredata -> forcer à quitter...
et en fait en débranchant le print, tout fonctionne normalement (enfin a priori je n'ai pas testé pendant 3 heures)... bizarre bizarre... par curiosité si quelqu'un(e) a une explication, merci d'avance.
Hors ligne
c'est peut être parce que le print reçoit trop d'infos, pix_openNI envoie toutes les positions de toutes les articulations ...
tu peux filtrer les différentes infos avec l'objet route . par ex ( route l_shoulder l_elbow l_hand ) te sortira les valeurs de l'épaule gauche sur la première sortie, du coude gauche sur la seconde, de la main gauche sur la troisième, et tout le reste sur la 4ème ...
Hors ligne
Je rencontre le même problème quelques années plus tard sur pd vanilla 0.46-2 au moment de relancer un vieux projet...
Je pense à un bug de l'objet pix_openni compilé pour OSX (le bug survient à un moment ou un autre).
https://github.com/kronihias/pix_openni/issues/5
Dommage, ça aurait été bien pratique, d'autres solutions?
Dernière modification par mrpropre (2016-01-15 01:54:40)
Hors ligne
Merci, dans ce cas je vais surement utiliser le serveur OSCeleton très léger lancé par l'objet shell... mais j'aurais bien voulu récupérer le flux rgb pour avoir un retour directement dans gem et monitorer...
Un retour en syphon pourrait m'aller, si quelqu'un a une idée d'un soft léger avec cette possibilité?
Hors ligne
Salut,
moi je l'utilise sans problème avec la version extended 0.42...
Plusieurs jours sans plantage....
Mais je sais qu'il a recompilé pix_openni plusieurs fois, et certaines versions étaient moins stable que d'autres.
Au pire j'en ai une stable pour 0.42 donc.
Dernière modification par nononononono (2016-01-16 18:18:34)
Hors ligne
Merci je veux bien jeter un oeil à ton binaire...
Pour info voici mes erreurs:
https://github.com/kronihias/pix_openni/issues/5
Hors ligne
Okay, je viens de regarder les sources;
Dans pix-openni.cc, ligne 1177, apres
case 24: SETSYMBOL (ap+0, gensym("r_foot")); break;
tu peux mettre par exemple
default: SETSYMBOL (ap+0, gensym("unknown")); break;
puis tu recompiles
cela évitera ce genre d'erreurs...
Sinon au vu des sources, je pense qu'avec le style osc cela passe, non? (pas de kinect pour tester là...)
l'objet compilé en pj a tester du coup
Dernière modification par nononononono (2016-01-21 18:21:37)
Hors ligne
Salut, merci beaucoup pour l'external compilé. J'ai testé et ça semble plus stable en effet.
Cependant je trouve OSCeleton un peu plus juste sur la détection, notamment sur le haut du corps qui a tendance à décrocher un peu dans l'external de Matthias Kronlachner, donc je reste dessus pour l'instant...
Hors ligne
Tiens, étrange, il me semblait que openni et osceleton étaient issus de la même librairie...
Bon à savoir en tout cas.
Hors ligne