Wii nunchuck

This is why I also pointed out the median. You really can’t tell what value is not in the margin.

So if you have 5 samples

50
51
50
70
48

sort them

48
50
50
51
70

take the middle one

that is 50 :wink:

What is bad about averaging is that you are including the error in the values where if you use median then the error is completely ignored.

Foekie , you can also try to add a large 100uF+ capacitor to the power right on the Wii controller. This will probably help in making the values more stable.

Ok for the video. I didn’t see it before :-[

I have some questions : is it an analog or digital joystick ? Can it be configured to be one or the other ?
I’m not in joystick anymore since long time ago, but I remember that many “problems” were due to the joystick not being configured properly, hence sending “weird” values.

Also, are you sure that what you receive from the joystick is always data ? I mean : could the large values be some kind of control data ?
I ask you that because I’ve had to cope with this when I was writing the drivers for the Phidgets boards. The way data is sent may not be as logical as it seems.
Maybe an USB sniffer could help in this case : you would see “real” data packets and others. This way you could possibly ignore some incoming data.
That’s just an idea, though.

is commonly used for something like this.

It might be nice if we had a Kalman filter tutorial around this site. Not everyone is really into and it might make things easier for them.

[quote]I have some questions : is it an analog or digital joystick ? Can it be configured to be one or the other ?
I’m not in joystick anymore since long time ago, but I remember that many “problems” were due to the joystick not being configured properly, hence sending “weird” values.

Also, are you sure that what you receive from the joystick is always data ? I mean : could the large values be some kind of control data ?
I ask you that because I’ve had to cope with this when I was writing the drivers for the Phidgets boards. The way data is sent may not be as logical as it seems.
Maybe an USB sniffer could help in this case : you would see “real” data packets and others. This way you could possibly ignore some incoming data.
That’s just an idea, though.[/quote]

The joystick is not the problem, the data discussed is coming back from the nunchuck joystick (I believe analog?)

[quote]Kalman filter - Wikipedia

is commonly used for something like this.[/quote]

That’s indeed a bunch of theory :o

Well I am working on the filter for the nunchuck and the wii motion plus as we speak have to work out some i2c issues. Once that is done i will post it up here along with the driver changes.

That would be awesome! Could you add a filter? Might be a good idea. (not because I need it, I’m testing too)

I am testing the filter. Trying to get some progress with this :slight_smile:

Yeah have to add a filter for what i am using it for. Will work on it more tonight. After i rework some code on the I2C device.

Do you own a wireless or a cabled nunchuck?

Cabled. Off brand. Gonna pick up stock version today. Though they all should work.

The one I currently use is a wireless one. Might borrow a cabled one to see how it responds.

Look at this video. I am gonna try out all 3. Since the FEZ can handle any of them with its processing power.

the Complementary Filter and the Extended Kalman Filter seem stable enough to me. But the Kalman is not. :stuck_out_tongue:

Ok Foekie

So you start it off with init
Then send a reset

     
       FEZ_Components.Wii.Nunchuk.Initialize();
            Thread.Sleep(100);
            FEZ_Components.Wii.Nunchuk.Reset();    

Make your rest code have this in it let me know how the number look then. I am sending more init commands then the driver package does.

public static bool Reset()
                {

                    // Initialize NumChuck in unencypted mode so xor does not have to happen to read values by sending F0, 55 and then sending give me data command by sending 0xFB, 0x00

                    I2CDevice.I2CTransaction[] NumChuckInitializeTrans = new I2CDevice.I2CTransaction[1];
                    NumChuckInitializeTrans[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0xF0, 0x55 });
                    //NumChuckDevice.Execute(NumChuckInitializeTrans, 1000);
                    Thread.Sleep(100);
                    


                    if (NumChuckDevice.Execute(NumChuckInitializeTrans, 100) == 0)
                    {

                        Connected = false;

                        return false;

                    }

                    else
                    {

                        Connected = true;
                        NumChuckInitializeTrans[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0xFB, 0x00 });
                        NumChuckDevice.Execute(NumChuckInitializeTrans, 1000);

                        return true;

                    }

                }

[quote]analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: -80 analog Y: -77
analog X: -80 analog Y: -77[/quote]

As you can see, this does not make any difference. I have organised a cabled nunchuck. But I need to work for 2 days, so you will have to wait a bit before I get it.

Thanks for your hard work so far! :clap:

I’m sorry to insist with this but I don’t think that your extra values are real data…

Each time you have a difference of 128 with the preceding value (48-128 = -80 and 51-128 = -77), which seems obviously not by accident. Especially in our binary world :wink:

Also, those values are always the same : -77 and -80. Too much for a simple coincidence, to me.

makes some difference Foekie. You are reading analog X now says something other then 48 :> Also what is read if you leave stick dead center. Mine shows

Analog X: 4 Analog Y: 5

Can you post your loop code so i can run it on my setup.

Edit: have you plugged it into Wii yet?

[quote]Each time you have a difference of 128 with the preceding value (48-128 = -80 and 51-128 = -77), which seems obviously not by accident. Especially in our binary world
[/quote]

True, but why?

The fact that both X and Y are showing values is that I placed the stick to the southwestern position.

I do not own one, but I can test it on Tuesday with a Wii.

Idle values are good, these are stable.

[quote]analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51[/quote]

So which values are wrong here.

[quote]Idle values are good, these are stable.

analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
analog X: 48 analog Y: 51
[/quote]

Post you basic code and will run it also.

Given your idle values, I would say that the joystick adds/removes 128 to each one to give its position. Could you give the values for each 8 positions, please ?
I would expect values like x from -80 to +176 and y from -77 to +179.

This would also mean that the joystick operates in digital mode, where you only know it’s left/right but not midlle-left or midle-right, for example.

Could you also press some buttons while leaving the joystick in idle position and see how the values change ?