Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Regression in balance board #10

Open
rpavlik opened this Issue · 20 comments

5 participants

@rpavlik
Owner

From personal email:


Specifically I need to use the wii board. After running the project to create the libraries and the example for the new version I get a warning right of the bat saying that the expansion code 0x4200402 could not be recognized, and the board is treated as regular controller, while incoming data is ignored (another warning).

I then tried v0.14 and the example there runs perfectly.

Could it be something I did wrong? Any pointers you could give me would be appreciated.

@rpavlik
Owner

My reply included: Please follow up there with more information: what kind of computer are you using and what operating system? Also, could you paste the output of running an example?

If you could use git bisect to track down the first commit that builds and runs but produces the same message you're seeing, that would also be very helpful.

@jandroGlez

I'm running XP with the Service Pack 3.

The outpur I get it this:

Connected to 1 wiimotes (of 1 found).

--- CONTROLLER STATUS [wiimote id 1] ---
attachment: 0
speaker: 0
ir: 0
leds: 1 0 0 0
battery: 1.020000 %
[WARNING] Unknown expansion type. Code: 0xa4200402

--- CONTROLLER STATUS [wiimote id 1] ---
attachment: 0
speaker: 0
ir: 0
leds: 1 0 0 0
battery: 1.020000 %

--- EVENT [id 1] ---
A pressed

--- EVENT [id 1] ---
[WARNING] Packet ignored. This may indicate a problem (timeout is 10 ms).

And this last warning keeps repeating.

@rpavlik
Owner

@janoc - The expansion detection code changed a lot with your motionplus support. Could you take a look at this and see why it might be issuing the [WARNING] Unknown expansion type. Code: 0xa4200402 line?

@janoc
Collaborator

Ah, that looks like a bug. I think the WiiBoard code is still looking for the encrypted expansion ID instead of the unencrypted one. 0xa4200402 is the unencrypted ID of the WiiBoard.

@janoc
Collaborator

OK, I checked the code - it seems that the code for handshaking the board is missing from events.c, function handshake_expansion(). The warning comes out of there - the board ID is not handled. I think that something wasn't merged correctly - still investigating.

@janoc
Collaborator

I am trying to reproduce the problem here with my balance board before trying to implement the proper detection. Unfortunately, it seems that in Linux even 0.14 is very unreliable - for me the board initializes every second-third attempt and doesn't report the weight data, only the button press. The balance board I have (bigben black clone with a digital scale built-in) works with report 0x32 enabled (buttons + 8 bytes expansion data) which isn't even defined in wiiuse, only report 0x34 (buttons + 19 bytes expansion data).

So there seems to be a bit deeper problem than I expected. It is possible that the code will need to be modified depending on the description of the connected controller and if it is detected as the board ("'RVL-WBC-01" instead of "RVL-CNT-01" for normal wiimote), initialized differently. I will keep you posted once I have something working.

@rpavlik
Owner

@marsh - what version of Wiiuse have you used with the balance board? Have you seen any of these reliability issues with the "official" balance board?

@janoc
Collaborator

@rpavlik - I doubt it is because of the board manufacturer. The Bigben board works just fine with a small script using Python and I can see it communicating and sending data (don't have a Wii to test it with). Just it doesn't work right with Wiiuse.

@marsh

It's been forever since I used it so I don't have any idea what version we were using. I don't recall any reliability issues. The only issue we had was that we weren't getting a number from one corner, but I don't know if that bug lies in wiiuse or VRPN. I wouldn't classify that as a "reliability" issue since it never worked.

I'll probably be getting the board back out in a few weeks (before I leave VRAC) to make sure that code still works. I'll let you know if I encounter any troubles.

@jcooperation

@jandroGlez The wii_board expansion check was simply not present in events.c/handshake_expansion(). So, it wasn't being recognized. I put the code back in my fork: https://github.com/jcooperation/wiiuse I tested it out (on WinXP SP3) with an official board and everything seems to be working now.

@rpavlik For what it's worth, I also changed the Windows stream-reading code so that it's more like the Linux reading code: i.e., it doesn't block for 100 ms for every device waiting for a report every time you poll but rather parses available packets and then moves on. This seems to work much better with the default MS stack: I'm able to run two balance boards simultaneously without noticeable latency--something I couldn't do before. I haven't tested with any other OSs or the BlueSoleil stack though.

@janoc
Collaborator

@jcooperation Yes, indeed, the board init was missing. Thanks for the work, I will have a look at it - it will make my integration easier.

I got bogged down with trying to make the Wiimote communication/handshaking code more robust, because on my Linux it is very unreliable - sometimes detecting the board, sometimes not, sometimes not even detecting regular Wiimote. Throw the Motion+ support into the mix and it was a lottery. Basically timing issues and some flaky hw - e.g. for me the board extension or nunchuck often identify as 0xffffff or 0x000000 instead of proper ID and then don't get recognized. Still trying to figure out what is going on there.

@jcooperation

@janoc The motion plus is definitely nasty because of the pass-through thing. In the old code from fwiine (I haven't had time yet to study this code-base much), if the motion plus is still active when you start up WiiUse, then it looks like a regular expansion; so the regular expansion handler tries to deal with it, but when it tries, that swaps the motion plus back to the 0xa6 memory space and suddenly there's no expansion. That puts things in a funny state. Just curious, has anyone in your group tried their hand at interpreting the calibration data that the motion plus reports? It looked like, right now, the code just uses hard-coded values for computing the angular velocities.

@janoc
Collaborator

@jcooperation The deal with M+ is that you have to detect it beforehand. That is what I am trying to do now. I am rewriting the initialization code to be completely synchronous (the async calls with callbacks and the obligatory state tracking all over the place are impossible to debug), with waiting for the correct reports, because the wiimote keeps sending regular data 0x30 reports even while calibrating or handshaking, throwing the code off. The idea is to init expansion, check the ID, if it is M+ in one of its states (there are about 5 possible ones ...), then turn it off, check for regular expansion, init it if present. When user asks for M+ to be turned on, then the correct pass-through mode needs to be selected based on which expansion is/isn't connected.

The M+ calibration interpretation isn't known, I think. However, the hardwired values are not too bad, because all you need to do to calibrate the static offsets of the gyros is to hold the wiimote still for few seconds. The scaling coefficients are known from the datasheets. I have also succeeded to link the M+ with the accelerometer & IR data using Kalman filter and that gives very robust orientation estimates.

@jcooperation

@janoc I can sympathize with the difficulty debugging; I'd like to help, but I don't have any pass-through devices at the moment. Maybe I can get one of my colleagues to bring some in from home.

When I was playing with the M+ a while ago, I did notice that if you write 0x00 to 0x04A400F2 while M+ is enabled, it seems to change the zero-point of the x and y gyros (not the z). If the device is moving at the time, it changes the reported values significantly. I guess that's just something for the gee-whiz collection.

I'm interested in learning more about your Kalman-filter tracking of orientation if that's something you're willing to share.

@janoc
Collaborator

@jcooperation Interesting info about the M+. Good to keep it in mind when the data go out of whack.

The Kalman filter I hope to release at some point, the problem is that it is something that cannot be integrated into WiiUse - it uses C++ and Eigen for the math, doing matrix algebra in plain C is pain :(

@janoc
Collaborator

Hello guys, a quick status update on this - while on vacation, I have managed to prototype a reliable initialization of both normal expansions & Motion+ in Python using Bluetooth sockets. Tomorrow I am flying back home, so I will check with my Balance Board and if it works, put the code in wiiuse.

There are some surprising issues, it seems - e.g. my wired 3rd-party nunchuck needs the expansion init code to be sent 4-5 times sometimes before it reacts and the expansion ID is readable (otherwise it reads all 0xFF but with no error flag). Other times it initializes right away. Most odd. Also, I have two Motion+ devices - one separate and one built-in in the Wiimote (the new Wiimote+). The latter has a different ID(!!): instead of 0x00A6200005 it reports 0x01A6200005. I wonder what I discover with the balance board tomorrow ...

@janoc
Collaborator

Hello folks,

Sorry that it took so long, but I had some personal and work-related stuff I had to get off my back first.

I have just sent Ryan a pull request for my changes. That should fix the balance board and also make the Motion+ more robust. If you want to test it, pull from my sync-init branch.

Regards,

jan

@rpavlik
Owner

OK, please test the latest master - I have included jan's latest changes.

@rpavlik
Owner

You may need to reset --hard for this master - I accidentally pushed the motion+ commit to master without making sure it didn't break other platforms, so I have corrected history a little bit.

The balanceboard support should still be fixed in the current master - please test.

@rpavlik
Owner

If it wasn't fixed before, it should really be fixed now. If you can, please give the latest master a try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.