[Flii] New version of FWiidom in svn
Pete Hobson
pete at freesome.com
Tue Apr 3 07:06:14 EDT 2007
I believe its part of the process when you first connect the wiimote
to the actual wii console.
The wiimote is then calibrated and these values are stored in the
wiimote non-volatile ram.
I.e its a one time process per wiimote. I *think* it would only need
to be done again if we transported our wiimotes somewhere such as
mars or the moon (unlikely right now unfortunately ;)
Then once you connect the wiimote to *our* frameworks these values
are transmitted back to us for use.
Im pretty sure this is the process, and it does perhaps cause a
possible issue for how we deal with wiimotes that have never been
calibrated via a wii. Perhaps there are sensible defaults in these
values in this case, or perhaps the wiimote is actually pre-
calibrated - certainly needs testing
By the way the nunchuck controller has an identical set of
calibration values, so any calculations we can develop will apply to
both wiimote and nunchuck.
On 3 Apr 2007, at 11:42, Rob Bateman wrote:
> so the wiimote calculates them automatically? Does it do this when
> the wiimote is switched on, or at regular intervals? Or am i
> missunderstanding and are you calculating them in the c# app, and
> then storing them in the wiimote?
>
>
> On 4/3/07, Pete Hobson <pete at freesome.com> wrote:
> Hi Rob,
>
> Yes, we have three values to work with per accelerometer.
>
> 1) the current acceleration (a1)
> 2) the Zero point calibrated value (a2)
> 3) the 1g calibrated value (a3)
>
> a2, and a3 will be available as constants per wiimote (they are
> stored in the wiimote memory) .
>
> On 2 Apr 2007, at 23:49, Rob Bateman wrote:
>
>> yes, i was in a bit late today :)
>>
>> reading the wikipedia article it becomes clearer how acceleration
>> can be estimated from the three accelerometer (i'll stop calling
>> them gyroscopes now) outputs. One interesting point i noticed was
>> that as the outputs from the accelerometers increase (in the
>> positive or negative direction) their accuracy decreases. So while
>> it may appear that the z-axis is redundant, when either the x or y
>> axes are at an angle close to 90 degrees from the vertical, it
>> would be more accurate to include the z axis data in calculations
>> as it would be closer to 0 degrees from the vertical.
>>
>> I also didn't realise the accelerometers could output a normalised
>> reading above 1g, so with this in mind it should be possible to
>> calculate acceleration independent of gravity effects, if we
>> assume that the acceleration occurs in a 'jerk' and the rotation
>> can be re-calibrated at the end (which shouldn't be too delayed
>> considering the finite space people have to accelerate things
>> given the length of their arms).
>>
>> i don't have any more time to look at this now (i think i probably
>> need a good nights sleep...) but i'll definitely give it some
>> thought over the next few days and let you know what i come up
>> with...
>>
>> also, the whitepaper on gesture recognition is completely useless
>> for anyone willing to understand the mechanism, but i'm sure
>> there's more useful papers out there.
>>
>> Rob
>>
>>
>>
>> On 4/2/07, Adam Robertson <oldskool73 at gmail.com> wrote:
>> err, yeah, all three are in there, I may not be passing them all
>> through to flash though as i assumed it wasn't all needed :)
>>
>> A
>>
>>
>>
>> On 4/2/07, Pete Hobson <pete at freesome.com> wrote:
>> hey adam,
>>
>> can i just confirm you have access to *both* the live acceleration
>> data , and the 1G *and* zero point calibration data. All three
>> are needed to calculate rotation correctly believe.
>>
>> On 2 Apr 2007, at 10:20, Adam Robertson wrote:
>>
>>> wow, bet someones a bit tired today ;)
>>>
>>> so, I take it it worked for you, that's a good first step!
>>>
>>> this page my be helpful (or may be what you already know)...
>>>
>>> http://www.wiili.org/index.php/Motion_analysis
>>>
>>> ...in fact that page seems to have been updated since I last
>>> looked and have the pitch/roll equations, which I think are the
>>> same as we are using?
>>>
>>> A
>>>
>>>
>>> On 4/2/07, Rob Bateman <rob.bateman at gmail.com> wrote:
>>> Hey guys
>>>
>>> i've had a look at the .as files and the output you get from the
>>> conduit, and looked at how it reacts to the motion of the wiimote
>>>
>>> very interesting stuff, and after much waving about, i've made
>>> some observations which i hope will help with the development
>>>
>>> i've not had a chance to compile my own tests, (no as3 on my pc
>>> at the mo) but from what i've seen of your own, there seems to be
>>> some confusion over the three gyroscopic outputs (measured as gX,
>>> gY and gZ i believe, as output in your graph demo)
>>>
>>> each one appears to be outputting the sin of the angle of the
>>> normalised vector from the horizontal. (a normalised vector to a
>>> plane represents a vector of length 1 extending perpendicularly
>>> out of the plane) to elaborate:
>>>
>>> gX is outputting the sin of the angle of the normalised vector
>>> of the right side of the wiimote from the horizontal
>>> gY is outputting the sin of the angle of the normalised vector
>>> of the front of the wiimote (where the ir sensor is) from the
>>> horizontal
>>> gZ is outputting the sin of the angle of the normalised vector
>>> of the bottom of the wiimote from the horizontal
>>>
>>> in each case, a positive angle is represented as being above the
>>> horizontal plane, and a negative angle below. So for example,
>>> when gY is +1, the angle is +90 degrees and the right side of the
>>> wiimote is pointing straight up.
>>>
>>> for the fields in your wiimotecontroller class, pitch can be
>>> calculated in radians from the arcsin of the gY value, and roll
>>> can be calulated in radians from the arcsin of the gX value. The
>>> gZ value is slightly redundant as it doesn't add any information
>>> to that already given by gX and gY, but i suppose it could be
>>> used to smooth out erroneous readings from gX and gY.
>>>
>>> From examining the fields in the wiimotecontroller class, i'm a
>>> little confused by the presence of relative acceleration values.
>>> I'm unsure how these could be calculated to sufficient accuracy
>>> with the information available, because of the redundance with
>>> orientation thanks to Newtons second law. The force
>>> (acceleration) being applied to the wiimote could not be
>>> distinguished by the gyroscopes from the force being applied by
>>> the earths gravity, hence the two vectors would simple multiply
>>> together and would appear as if the wiimote had been tilted. It
>>> may be possible to produce something that could be subtracted
>>> from the orientation readings given by the ir sensor, but only if
>>> the wiimote was pointing at the sensor bar at the time.
>>>
>>> I plan to get my pc set up so that in future i can run tests
>>> myself, to get a better picture of what is it possible to
>>> determine from the output available. In the meantime, i hope the
>>> above information is useful! :)
>>>
>>> cheers
>>>
>>> Rob
>>>
>>>
>>>
>>> On 4/1/07, Pete Hobson < pete at freesome.com> wrote:
>>> Nice one adam.
>>>
>>> I'll have a look at this under parallels on the mac, will be
>>> interesting to see if it works there.
>>>
>>> One quick question - does using c# bring in dependancies on
>>> the .NET framework also, or can you use c# for non .net console
>>> apps also??
>>>
>>>
>>> On 1 Apr 2007, at 21:41, Adam Robertson wrote:
>>>
>>>> Hi,
>>>>
>>>> I've put my work so far on the new FWiidom c# wrapper in my svn @.
>>>>
>>>> http://www.fwiidom.org/svn/
>>>>
>>>> there's a quick readme and the start of some bare bones
>>>> documentation in there too, if you are intrested in beta testing
>>>> it feel free to have a play and let me know how you get on.
>>>>
>>>> Adam
>>>>
>>>> _______________________________________________
>>>> Flii mailing list
>>>> Flii at osflash.org
>>>> http://osflash.org/mailman/listinfo/flii_osflash.org
>>>
>>>
>>> _______________________________________________
>>> Flii mailing list
>>> Flii at osflash.org
>>> http://osflash.org/mailman/listinfo/flii_osflash.org
>>>
>>>
>>>
>>>
>>> --
>>> Rob Bateman
>>> Senior Creative Developer
>>>
>>> Work: 0207 7804841
>>> Mobile: 07714 329 073
>>>
>>> rob.bateman at akqa.com | http://www.akqa.com
>>>
>>> AKQA, 1 St John's Lane, London EC1M 4BL, UK.
>>> _______________________________________________
>>> Flii mailing list
>>> Flii at osflash.org
>>> http://osflash.org/mailman/listinfo/flii_osflash.org
>>>
>>>
>>> _______________________________________________
>>> Flii mailing list
>>> Flii at osflash.org
>>> http://osflash.org/mailman/listinfo/flii_osflash.org
>>
>>
>> _______________________________________________
>> Flii mailing list
>> Flii at osflash.org
>> http://osflash.org/mailman/listinfo/flii_osflash.org
>>
>>
>>
>> _______________________________________________
>> Flii mailing list
>> Flii at osflash.org
>> http://osflash.org/mailman/listinfo/flii_osflash.org
>>
>>
>>
>>
>> --
>> Rob Bateman
>> Senior Creative Developer
>>
>> Work: 0207 7804841
>> Mobile: 07714 329 073
>>
>> rob.bateman at akqa.com | http://www.akqa.com
>>
>> AKQA, 1 St John's Lane, London EC1M 4BL, UK.
>> _______________________________________________
>> Flii mailing list
>> Flii at osflash.org
>> http://osflash.org/mailman/listinfo/flii_osflash.org
>
>
> _______________________________________________
> Flii mailing list
> Flii at osflash.org
> http://osflash.org/mailman/listinfo/flii_osflash.org
>
>
>
>
> --
> Rob Bateman
> Senior Creative Developer
>
> Work: 0207 7804841
> Mobile: 07714 329 073
>
> rob.bateman at akqa.com | http://www.akqa.com
>
> AKQA, 1 St John's Lane, London EC1M 4BL, UK.
> _______________________________________________
> Flii mailing list
> Flii at osflash.org
> http://osflash.org/mailman/listinfo/flii_osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/flii_osflash.org/attachments/20070403/2df5fde9/attachment.htm
More information about the Flii
mailing list