Continuando la carrellata di ciò che è cambiato nel nuovo SDK del Kinect rispetto alla beta2, eccoci all’uomo vitruviano (vedi post).
E’ oramai noto che uno degli aspetti più interessanti del Kinect è il fatto che il suo SDK è in grado di fornirci la posizione di alcuni punti ben determinati dei player inquadrati e riconosciuti dal sensore.
L’insieme di questi punti (20 per la precisione) per ogni player è detto Skeleton e i punti sono mostrati in figura:
L’SDK è in grado di ritornare una collection di oggetti di tipo Joint, ognuno dei quali rappresenta i dati spaziali del singolo punto.
Cominciamo dal vedere come accedere al sensore Kinect e attivare il riconoscimento dello scheletro (Skeletal Tracking).
Come già visto nei precedenti due post della serie, il meccanismo per accedere al Kinect è quello di passare dalla collezione KinectSensors della classe KinectSensor, registrare l’opportuno gestore di evento e abilitare lo stream che ci interessa:
- If KinectSensor.KinectSensors.Any() Then
- Sensor = KinectSensor.KinectSensors(0)
- If Sensor.Status = KinectStatus.Connected Then
- AddHandler Sensor.SkeletonFrameReady, AddressOf SkeletonFrameHandler
- Sensor.SkeletonStream.Enable()
- Try
- Sensor.Start()
- Catch ex As Exception
- End Try
- End If
- End If
L’evento SkeletonFrameReady viene sollevato dall’SDK del Kinect ogni volta che un nuovo frame contenente gli Skeleton è pronto.
La figura seguente mostra la struttura delle classi coinvolte nell’argomento dell’evento SkeletonFrameReady:
Come già visto per il video e la profondità, anche in questo caso, l’effettivo frame viene ottenuto utilizzando il metodo OpenSkeletonFrame.
Osserviamo che, a differenza della Beta2, la classe SkeletonFrame non ha più le proprietà NormalToGravity e Quality (poco significative) e la proprietà FloorClipPlane è di tipo Tuple(Of Single, Single, Single, Single) anziché Vector.
La proprietà FloorClipPlane fornisce i coefficienti dell’equazione del piano di terra (pavimento) stimata dall’SDK. L’equazione ha la forma:
Ax+By+Cz+D=0
dove:
A = FloorClipPlane.Item1
B = FloorClipPlane.Item2
C = FloorClipPlane.Item3
D = FloorClipPlane.Item4
L’equazione del piano è normalizzata, quindi D rappresenta, di fatto, l’altezza della camera rispetto al pavimento. Anche in questa versione dell’SDK, come nella versione Beta, il vettore è sempre nullo.
Una volta ottenuta l’istanza dello SkeletonFrame, possiamo utilizzare il metodo CopySkeletonDataTo per recuperare gli effettivi dati degli scheletri:
- Private Skeletons() As Skeleton = New Skeleton(6) {}
- Private Sub SkeletonFrameHandler(sender As Object, e As SkeletonFrameReadyEventArgs)
- Dim skeletonFrame = e.OpenSkeletonFrame()
- If skeletonFrame IsNot Nothing Then
- skeletonFrame.CopySkeletonDataTo(Skeletons)
- '
- ' gestione degli skeleton recuperati
- '
- End If
- End Sub
La classe Skeleton (nella Beta2 si chiamava SkeletonData) contiene i dati essenziali degli scheletri e il diagramma delle classi coinvolte è il seguente:
Ogni Skeleton ha un suo TrackingId che lo identifica univocamente, un TrackingState che ci dice se è tracciato o meno (ricordiamo che su 6 scheletri disponibili, solo fino a 2 sono tracciati contemporaneamente), una posizione (proprietà Position) che dovrebbe rappresentare il baricentro e una collezione di Joint (proprietà Joints).
Possiamo recuperare i singoli Joint a partire dal loro tipo (enumerazione JointType).
Questa enumerazione era già presente nella Beta2 ma il suo nome era JointId (ora è decisamente più chiara) così come la proprietà del Joint che la contiene si chiama JointType (si chiamava JointID nella Beta2).
Altri cambiamenti sono stati introdotti nelle Position (sia dello Skeleton che del Joint): nella Beta2 queste erano di tipo Vector, mentre ora sono di tipo SkeletonPoint. La SkeletonPoint non ha più la proprietà W (presente nel Vector) e non significativa nella Beta2.
Come abbiamo già visto quando abbiamo parlato del sensore di profondità, il Kinect for Windows (e, quindi, l’SDK) ha la modalità “Near Mode”.
Questa influenza non solo la minima distanza di riconoscimento di un player (come già visto nel precedente post) ma anche il numero di joint rilevati, come mostrato nella seguente tabella:
La tabella va necessariamente spiegata perchè fuorviante: nel caso di Near Mode, la classe Skeleton valorizza la sola proprietà Position (e solo se l’intero scheletro è tracciato), quindi il punto denominato “Center Hip Joint” non è il Joint “HipCenter” (uno dei 20 a disposizione) anche se, in prima approssimazione, possiamo pensarli coincidenti.
Per poter passare nella modalità “Near Mode” si deve intervenire sulla proprietà Range del DepthStream esposto dal KinectSensor impostandola a KinectRange.NearMode.
Se si imposta la proprietà Range del DepthStream quando questo non è stato abilitato tramite il metodo Enable, non si ottiene alcun errore, ma il sensore non va il modalità near mode.
L’applicazione proposta in allegato mostra, istante per istante, le posizioni dei 20 punti sensibili dello skeletal tracking, come mostrato in figura:
Commenti