Précision de la caméra de profondeur kinect

• Résolution horizontale: 640 x 480 et 45 degrés FOV vertical et 58 degrés FOV horizontal. La géométrie Simple est d'environ ~ 0,75 mm par pixel x Par y à 50 cm, et ~ 3 mm par pixel x Par y à 2 m.
• résolution de profondeur: ~ 1,5 mm à 50 cm. Environ 5 cm à 5 m.
• bruit: environ + -1 DN à toutes les profondeurs, mais DN à la profondeur est non linéaire. Cela signifie +-1 mm fermer, et + - 5 cm loin.

il y a des spécifications officielles du développeur de capteurs, pas de Microsoft. Pas d'articles scientifiques que je connais encore. Beaucoup d'enquêtes et d'expériences (voir Google). OpenKinect a beaucoup plus de discussions sur ces choses que ce site pour l'instant.

le Kinect pour Windows SDK fournissent quelques constantes que j'ai utilisé et semblent être cohérentes. et résolution, ces valeurs sont les suivantes:

en mode par défaut:

• portée minimale: 80 cm
• portée maximale: 400 cm

Dans près de la mode:

• portée minimale: 40 cm
• portée maximale: 300 cm

pour la caméra couleur, vous pouvez avoir les résolutions suivantes:

• 80x60
• 320x240
• 640 x 480
• 1280x960

pour la caméra de profondeur, vous pouvez avoir l'une des résolutions suivantes:

• 80x60
• 320x240
• 640 x 480

Confrontant les informations de Avada Kedavra (et de la plupart des sources, par la voie), les valeurs de l' champ de vision donné par les API sont les suivantes:

pour la caméra couleur:

• CHAMP de vue Horizontal: 62,0°
• vertical FOV: 48,6°

pour la caméra de profondeur:

• CHAMP de vue Horizontal: 58,5°
• vertical FOV: 45,6°

Source:http://msdn.microsoft.com/en-us/library/hh855368

la vraie question ici était sur la résolution et la précision. Je tiens à participer ici, car je trouve que la résolution et la précision ne sont pas aussi bonnes que ce qui a été dit. La sortie maximale de la résolution de profondeur est en effet 640x480, mais ce n'est pas la résolution effective, et ce n'est pas exactement à quel point elle est précise.

La méthode dans laquelle le kinect est basée sur la projection de lumière structurée. Un modèle de lumière est émis et moulé sur la surface, qu'une caméra voit et puis triangule chaque rayon de l'origine, rebondi de l'objet, à la caméra.

la chose est que ce modèle se compose de seulement 34.749 points lumineux qui peuvent être triangulés (http://azttm.wordpress.com/2011/04/03/kinect-pattern-uncovered/). Si nous relions cela à une résolution de 640x480=307.200 points de données, nous remarquons une grande différence. Demandez-vous si la quantité de données 10 fois la quantité de sources-points de données peut être considérée comme valide, et échantillonné efficacement. J'en doute. Si vous me demandiez Quelle est la résolution effective du kinect, je suppose que c'est autour de 240x180 d'honnête et de données assez bonne.

Selon Kinect tech spec enfin révélé les spécifications pour la profondeur de champ sont (ces match est également confirmé dans l'officiel du guide de programmation posté par Mannimarco):

* Horizontal field of view: 57 degrees
* Vertical field of view: 43 degrees
* Physical tilt range: ± 27 degrees
* Depth sensor range: 1.2m - 3.5m
* Resolution depth stream: 320x240 pixels
* Resolution color stream: 640x480 pixels

0.8m-4.0m, au moins j'obtiens une bonne lecture dans cette gamme. Cette gamme correspond à la fiche de données de Primesense publiée par mankoff dans les commentaires ci-dessous.

Il est également important de se rappeler que la profondeur la résolution est beaucoup plus élevée près du capteur que plus loin. à 3-4 mètres la résolution n'est pas aussi bonne qu'à 1,5 m. Cela devient important si, par exemple, vous voulez calculer les normales de la surface. Le résultat sera plus proche du capteur que plus éloigné.

ce n'est pas difficile de tester la portée vous-même. Le SDK officiel (actuellement bêta) vous donnera une profondeur de zéro (0) lorsque vous êtes hors de portée. Donc, vous pouvez tester cela avec une règle simple, et testez à quelle distance vous obtenez / n'obtenez aucune lecture supérieure à zéro. Je ne sais pas comment le SDK OpenKinect gère les lectures hors de portée.

un commentaire sur le bruit: je dirais qu'il y a beaucoup de bruit dans le courant de profondeur qui le rend plus difficile à travailler. Par exemple, si vous calculez les normales de surface, vous pouvez vous attendre à ce qu'elles soient un peu "sautillantes" qui, bien sûr, auront un impact négatif sur le faux éclairage, etc. En outre, vous avez un problème de parallaxe dans le flux de profondeur due la distance entre l'émetteur IR et le récepteur. Cela peut aussi être difficile de travailler avec car cela laisse une grande "ombre" dans les données de profondeur. Cette vidéo démontre le problème et discute d'une façon de résoudre le problème à l'aide de shaders. Son d'une vidéo vaut la peine de regarder.

je pense qu'il pourrait être utile de mentionner le papier de Khoshelham et Elbernik qui n'proposer théorique erreur aléatoire modèle de la kinects capteur de profondeur en Février '12. Il est appelé "précision et résolution des données de profondeur Kinect pour les Applications de cartographie intérieure". Le papier peut être trouvé ici.

si vous cherchez quelque chose publié par Microsoft, consultez la page 11 du Guide De Programmation Kinect. Il dit à peu près la même chose que tout le monde ici a déjà mentionné.

• portée: 1,2 à 3,5 mètres
• angle D'observation: 43 ° vertical par 57° horizontal
• plage D'inclinaison mécanisée: ±28°
• fréquence d'Image: 30 images par seconde
• résolution, flux de profondeur: 320 x 240 (Il peut en fait aller plus haut que cet)
• la Résolution, la couleur de flux: 640 x 480 (encore une fois, il peut aller plus haut)

Je ne vois rien qui mentionne le bruit, mais je peux dire qu'il est assez minime sauf le long des bords de surface où il peut devenir plus perceptible.

D'après mon expérience, ce n'est pas si exact. C'est assez bien, mais quand vous le comparez à la mesure de bande Il n'est pas de correspondance exacte. J'ai fait un excellent avec des mesures pour chaque 10mm il vient de ne pas holdup, chose en particulier qui sont plus de 2500mm de distance, mais plus proche aussi. Gardez également à l'esprit que la profondeur réelle des pixels est beaucoup plus faible est alors annoncé. L'électronique à l'intérieur remplit les halètements, c'est pourquoi vous voyez des artefacts de petite zone, et pas quelque chose comme des données de pixel. En substance, cela signifie que 320x240 a 1/8 pixels couverts par une mesure" réelle", les autres pixels sont calculés. Donc, vous pouvez utiliser 640x480; mais il ne serait que la ressource CPU/UBS et ne fera pas votre application voir mieux.

Eh bien c'est juste mon 2 cents d'expérience, je programmais la robotique.