gamepad API based on serialport about johnny-five HOT 12 CLOSED

Thanks @ThomasDeutsch! I'm actually involved (to a lesser degree these days) with the browser gamepad API :)

A few initial thoughts: Johnny-Five is a specifically a command line program, however there is nothing stopping us from using socket.io to transport gamepad signals from the browser to the program. Also, we've already built in support for Wii Nunchuk, so why stop there??

Let's use this thread as a way to brainstorm ideas for how to approach this and come up with a strategy

from johnny-five.

@rwldrn i have seen your name in the w3c specs :)
Yes, we can use socket.io or redis to get the gamepad data to the johnny-five node.
Everything is fine in johnny-five world - what bugs me is how we get the gamepad data.

When it comes to gamepads, Johnny-Five is on a leach.
It depends on a big guy with a browser or one of the Frameworks, so we are unable to
keep things small.

So, i want a robot that is small, agile and free. I run johnny-five on a small arm-board - nice!
But now... i want to control my little fun robot with a gamepad connected to it - not possible.

from johnny-five.

Yeah, I'm with you on that. I've actually built my own controller using the five.Joystick() and five.Button(), but I know that's not the same. Let's do some research about hardware that is "hackable" and post back here

from johnny-five.

I think that the standard gamepads (xbox360, PS3, ... ) are the only choice.
They are high quality, you can buy them everywhere and they are not expensive.

from johnny-five.

Ok - i found a solution. See this tutorial:
http://nodebits.org/linux-joystick

also:
https://github.com/gorillatron/node-pad
(based on node-hid: https://github.com/hanshuebner/node-hid )

Or a SDL lib for node:
https://github.com/creationix/node-sdl (see 1.4. Joystick Functions )

from johnny-five.

I've just ported this nodebits sample into a module and published to npm and then stumbled onto this thread, Doing this very same thing -- using a wireless usb joystick on a beaglebone to remote control a robot.

https://github.com/JayBeavers/node-joystick
https://npmjs.org/package/joystick

from johnny-five.

@JayBeavers how would you feel about working out a common joystick API? We could work together to create a sort of "standard" API and event semantics, with the goal of allowing user code to hopefully work with either your project or Johnny-Five. I think this could be a critical step in the right direction for node hardware programming as a whole :)

from johnny-five.

Great work @JayBeavers !

For an API, i think it would make sense to exclude parts of the parser into a json file (offsets and event names).
This file could contain the offset+bits/eventNames/ of all the supported controllers - and it would be easy to add a new one.

example:
Here you can find the input-data used by the xbox360 controler: http://free60.org/GamePad

a bit off-topic:
I want to use the node.js-Domain ( http://nodejs.org/api/domain.html ) to implement my joystick-module. Here is the fiddle: http://jsfiddle.net/Q3LCU/2/ what do you think?

from johnny-five.

@rwldrn I'd be happy to work together on this joystick api. How do you think it should be changed?

@ThomasDeutsch the joystick struct comes from the linux kernel driver, it should be the same struct across all joysticks supported by Linux. I've looked at the USB HID structs which do vary between joysticks and decided against implementing it this way for now because it's considerably more complicated. When I can find the time, I want to write a libusb/usbhid library for node and we could build cross platform joystick support on top of this.

@ThomasDeutsch the domain concept looks interesting. I haven't used this yet. I took out the 'wrap' code from nodebit's implementation because I wanted to simplify things and it looks like Domain is meant to be the official way to do the same error catching. If you want to fork node-joystick and code it up as a domain, I'd love to see the results.

I think I'm pretty happy with the scope of the api at this point. One additional feature it could use is some form of auto-calibrate. I've added a little logic to help clean up the input data (deadzone & sensitivity) but I think deadzone could use a little more intelligence based on some limited testing I've done. I'm curious what your own testing results will be.

from johnny-five.

@JayBeavers awesome. I have to drive for 10 hours today, so I'll have plenty of time to think about it :)

from johnny-five.

Please stop me if this is necromancy but I was going through the issues list and noticed this one was still open. Personally I use a 360 controller for a lot of project prototypes with this driver https://github.com/andrew/node-xbox-controller.

While it would be nice to build this into johnny-five I also think that there are a lot of controllers out there that would have to be catered for and one extra require really doesn't kill me. It's the "do one thing right" side of my brain that keeps nagging at me when it comes to this topic. Of corse theres the other side of me that uses JQuery and Bootstrap...

from johnny-five.

Please stop me if this is necromancy but I was going through the issues list and noticed this one was still open. Personally I use a 360 controller for a lot of project prototypes with this driver https://github.com/andrew/node-xbox-controller.

I won't stop you! This is awesome and super helpful :)

While it would be nice to build this into johnny-five I also think that there are a lot of controllers out there that would have to be catered for and one extra require really doesn't kill me. It's the "do one thing right" side of my brain that keeps nagging at me when it comes to this topic.

Agreed! I use several other libs for Kinect, LeapMotion, etc.

from johnny-five.