Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wiimote tilt support? #21

Closed
hissingshark opened this issue Oct 25, 2016 · 5 comments
Closed

Wiimote tilt support? #21

hissingshark opened this issue Oct 25, 2016 · 5 comments

Comments

@hissingshark
Copy link

Hi,

I've followed the build and installation instructions for SingleUser as I'm running a Retropie install on OSMC (Rpi3). All appears to have been successful, apart from having to manually connect the controller each time through bluetoothctl and the Wiimote's sync button.

Emulationstation detects the controller and I can configure all of the buttons. But i can't set up the analog axes. This I anticipated would come from the Wiimote accelerometers (I'm doing all this to let my daughter use a Wiimote and steering wheel for N64 MarioKart as her hands are too small for handling analog sticks on a joypad and the first thing she tried to do was intuitively steer by tilting the controller).

I tried to diagnose using jstest from the commandline but that doesn't even register the button presses that are already proven to work, let alone the axes, so that's not been helpful at all.

So is tilt support actually a part of the driver? I wondered if it was a configuration issue, but I can't find any config files. The installer didn't create anything under ~/.config/ or in /etc/ as I was expecting so I can't see anything to be tweaked.

Many thanks.

@jgeumlek
Copy link
Owner

jgeumlek commented Oct 25, 2016

  1. The installer doesn't make any config directories, though MG should make ~/.config/moltengamepad when it is run. (Though that directory will be empty).

Right now the configuration files are essentially "make them as you need them", with everything falling back to defaults when not set via a file.

  1. Please use evtest instead of jstest, and make sure you are checking the virtual devices made by MoltenGamepad.

  2. Since reading wiimote accelerometers drains the batteries, the default profile has them disabled. Further, the default profile has these tilt axes unmapped.

# Run this command to see the current wiimote mapping
print profile wiimote

You'll want something like the following:

# enable the accelerometers
wiimote.?wm_accel_active = true
# map steering wheel tilting onto the x axis of the movement thumb stick
wiimote.wm_accel_y = -left_x
# Optional: map tilting towards/aways onto the y axis of the movement thumb stick
# wiimote.wm_accel_x = -left_y

Those commands can be typed into MoltenGamepad directly, or you put them in a file inside the profiles directory for easy loading later. load profiles from <filename>

Notice how the accelerometers are enabled, and I mapped the relevant wiimote axis onto the x axis of the virtual controller's left joy stick. This corresponds to steering-wheel-esque tilting.

  1. I haven't figured out the exact requirements, but if you make bluetoothctl forget about your remote, and then do a sync-pair-connect-trust through bluetoothctl in very quick succession, you should make it so that the wiimote attempts to connect to your PC when you push any button.

Oh, and a fair bit of warning:
These accelerometer values are being processed pretty naively, and MK 64 wasn't exactly designed with virtual steering wheels in mind. Your mileage may vary.

@hissingshark
Copy link
Author

Lots to try there.

Now I get how to issue commands. I was trying to send them via the FIFO with no luck. You just run MG directly to give an interactive mode like bluetoothctl has. This also produces the empty directory I was looking for. So far I've been using the daemon mode via service files, which does not create them it seems.

I'll try the evtest route to verify the alternative configs as recommended.
With respect to accuracy, it will be interesting to see if MarioKart is playable within those tolerances, as it's the sole purpose of this exploration for me at least.

Regards battery drain, was this the same when used with the Wii officially, or did they manage reads differently perhaps?

Thanks very much for getting back to me on this.

@jgeumlek
Copy link
Owner

jgeumlek commented Oct 25, 2016

You said you installed as Single User, so that means you wrote your own service files, yes? You should check how your environment is set up when run via your service files. I think MoltenGamepad might have been unable to find a sensible location from your environment variables, so it bailed out of trying to create its directory.

Writing to the FIFO should be acting as equivalent to just typing things directly into MoltenGamepad, assuming MoltenGamepad is listening to it. Sounds like something went wrong, and I'd appreciate more details on how you were running MG and how you were writing to the FIFO.

I'm pretty sure it is the same as the Wii. The linux kernel is using the protocol reverse-engineered from the Wii. The wiimote supports configuring different reporting styles, and by not opening those sensors we can stick to the simpler reports. I haven't actually done any tests to see how much a difference it makes.

Looking back at the kernel wiimote module, I see they do mention the IR feature being power costly (a camera + tracking). No mention about the accels. Perhaps sending the accel data isn't much of a drain.

Another reason for disabled accels by default is that they'd create a lot of spurious events inside MoltenGamepad even if they end up ultimately being ignored.

@jgeumlek
Copy link
Owner

Changing to help wanted:

How should we process tilt values to be most usable?
What would be the appropriate way to smooth them?

The code is already able to get the raw accelerometer data. We just need a smarter way of using those numbers.

@jgeumlek
Copy link
Owner

jgeumlek commented Apr 5, 2017

Opening separate issue for improving tilt and Wiimote pointing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants