Here, this post is going to deal with the new option fWIIne(6) and the variable "t" for the S-function sfwiine (Simulink) from the current release of fWIIne (0.2).
1. S-function : variable "t"
A new variable "t" is defined as the time between reception and record of 2 frames from the wiimote.
[As a result of simulation, "tout" is the simulated time (Here, this variable is relevant for simulink because sfwiine is not compatible with RealTime Workshop Libraries]
[The sum of "t" can be used for time measurements ]
2. Roll and pitch
Option number 6 for fWIIne returns pitch and roll under some conditions.
% [aX,aY,aZ,Pitch,Roll]=fWIIne(6); (Matlab & WinXP)
// [aX,aY,aZ,Pitch,Roll]=fwiine(6); (Scialb & Linux)
Both angular values are given in degrees. But angular limitations are different between both applications :
-> from -45° to +315° for fWIIne for Matlab and WinXP.
-> from -180° to +180° for fwiine for Scilab and Linux.
The wiimote must be in a steady-state (i.e. no motion during pitch and roll acquisitions and for a basic use) in order to record valid measurements.
A comparison between roll measurements from raw values of accelerometer and IR sensor illustrates the mismatch.
(Pre-requisite : 1 sensor bar or 2 IR sources. fWIIne is installed on the computer)
The wiimote is set on the table. The sensor bar is located in front of the wii controller. The angle is increased and then the wiimote is released.
[Basic experiment - Animated picture (repeated 10 times inside animation)] | "Raw" measurement from wiimote sensors: [Basic experiment - Unfiltered values from data acquisition ] |
Inside the Wiimote's reference, the following motion has been recorded :
[Basic experiment - Data inside the Wiimote's reference]
Then, the following graph describes the difference of roll computation :
[Basic experiment - difference between roll computation from both wiimote sensors]
As a conslusion, there is a restrictive use of the feature fWIIne(6) for pitch and roll computation (compared with other options) : the wiimote has to be static - in steady-state - to avoid overshoot. As a workaround, IR sensors can also provide information for computation of pitch and roll (unimplemented functions for the current release) and for angular measurements.
------------
------------
[version française]
La version 0.2 de fWIIne a introduit quelques évolutions et une fonctionnalité supplémentaire.
Dans un premier temps, il s'agit ici d'expliciter la définition de la variable "t" de la S-fonction sfwiine pour Simulink. Puis, une expérimentation basique sera présentée en vue d'illustrer la nouvelle option fWIIne(6).
1. S-fonction : la variable "t"
Une nouvelle variable "t" est disponible et représente le temps écoulé entre l'acquisition de deux trames en provenance de la wiimote.
["tout" est le temps simulé utilisé par simulink mais non représentatif du temps réel (l'option n'étant pas implémentée)]
["t" est le temps entre la réception de deux trames de données. La cumul de cette variable peut être utilisée dans les mesures]
2. Roulis et Tangage
L'option numéro 6 de fWIIne retourne les valeurs de roulis et tangage sous certaines conditions.
% [aX,aY,aZ,Pitch,Roll]=fWIIne(6); (Matlab & WinXP)
// [aX,aY,aZ,Pitch,Roll]=fwiine(6); (Scialb & Linux)
Les valeurs des angles sont retournées en degré. Toutefois, les limitations angulaires sont différentes entre les deux applications :
-> de -45° à +315° pour fWIIne pour Matlab et WinXP.
-> de -180° à +180° pour fwiine pour Scilab et Linux.
L'absence d'accélération subie par la wiimote est une condition de validité de la mesure des angles (autrement dit la wii remote restera immobile pour une utilisation basique sur une table).
Une comparaison entre les angles de roulis mesurés à partir des valeurs "brutes" (non filtrées) de l'accéléromètre et du capteur infrarouge montre un décalage entre les valeurs :
(Pré-requis : 1 sensor bar ou 2 sources infrarouge. fWIIne est opérationnel sur le PC)
La wiimote est posée sur la table. La sensorbar est située en face. La manette Wii est inclinée puis relachée.
[Experimentation basique - image animée (répétée 10 fois dans l'animation)] | Mesure "brute" des différents capteurs de la Wiimote : [Experimentation basique - Valeurs sans filtrage" de l'acquisition obtenue] |
Dans le référentiel de la Wiimote, les mouvements observés sont les suivants :
[Expérimentation basique - Interprétation des données dans le référentiel de la Wiimote]
Enfin le graphe ci-dessous montre la différence de comportement entre les deux calculs :
[Expérimentation basique - différence de calcul du roulis à l'aide des deux capteurs de la Wii Remote]
En conclusion, l'option fWIIne(6) pour l'évaluation du roulis et du tangage est plus contraignante que les autres options : la wiimote doit être statique afin d'éviter les dépassements. Cependant les capteurs IR de la wiimote sont une option supplémentaire (non implémentée pour le moment) pour déterminer les mesures angulaires.
1 comment:
Trackback :
See also the following part of project report :
Head Angle Detection (polish language vers.)
Sebastian Bełczyk,Michał Szylar,Piotr Borzęcki
from
Akademia Górniczo-Hutnicza
Im.St.Stanisława Staszica
WEAIiE, Katedra Automatyki
Laboratorium Biocybernetyki
Kraków, Poland
Post a Comment