How To: Xbox Controller Vibration

[MDAWG25]

I have noticed a lot of question regarding how to access the vibration controls of an Xbox controller connected to the driver station.

So I started investigating and found LabVIEW can use DLLs, and remembered that Xbox controllers use the xinput DLL to control this feature of the controllers.

This is the function definition of XInputSetState in the Xinput DLL found on most, if not all Windows computers. I am using the Xinput9_1_0.dll found in C:\Windows\System32. If you do not have this DLL, install the latest directx available.
http://msdn.microsoft.com/en-us/libr...=v s.85).aspx

dwUserIndex is the controller index of the controller you want to use, you can identify the number by seeing which "player" light is lit on the controller.

pVibration is a struct in C++ but a cluster in the LabVIEW code attached. The vibration value is from 0 to 65536, higher means more vibration.

The attached code is a LabVIEW library that you place in the user.lib directory of your LabVIEW install. For example mine is

C:\Program Files (x86)\National Instruments\LabVIEW 2013\user.lib

Unzip the folder Xinput9_1_0 to that directory and open up LabVIEW with either a new VI or your current Dashboard Project. The example pictures below is a new, default Dashboard Project.

1. Start by dragging the XinputSetState VI to you block diagram.
2. Right click on the pVibration terminal, go to create, then click constant
3. delete the wire branch connecting the constant to XInputSetState
4. create a bundle by name and place it on the diagram
5. connect the cluster constant to the bundle by name
6. create controls, constants, or what ever to the input terminals of wLeftMotorSpeed or wRightMotorSpeed

   Left Motor is the 'rough' vibration while the Right Motor is the 'smooth' vbration

7. Run the project and give it a value between 0 and 65536
8. Your controller is Vibrating!

Here is a small video demonstrating the library (Note the controller in the video is wireless, this library will work just the same with wired controllers): https://www.dropbox.com/s/swrerlsmom...415_141309.mp4

Remember to set the vibration value to 0 before exiting, or your controller will vibrate until you do set it!

The controller will be pulling power from your driver station's USB hub. Be sure it does not go over the limit for your hub or your may lose connectivity to other devices connected to the same hub.

This method of interfacing with the XInput DLL should transfer to the SmartDashboard as well. If anyone accomplishes this, send me a private message with instructions and I will update the thread.

[JamesTerm]

This is pretty cool. I believe, and Greg please jump in if I am wrong... only labview teams can use this kind of solution. If c++ and java teams could use xinput there is not anything that I have seen to do so in short of having to write our own application (e.g. make a wedge proxy to the dashboard with its own networking solution). IIRC I believe direct input had some preliminary functionality for that for rumble, but I have never tested using that so it is hard to say... The driver station uses direct input, but the c++ and java interface is limited to certain controls because all the controls and submitted in a packet and it is packed tight, so I am somewhat surprised that labview is not subjected to the same functionality.

[Johnbot]

That's actually pretty neat - I didn't know LabVIEW was that extendable.

Last year, team 2607 used a separate Java application running on the driver-station to add rumble functionality to our Xbox controllers.
We just read the button states from the application to trigger the hard and soft rumbles, but you could easily integrate it into your dashboard to communicate with the robot (which would also allow for other nifty things, like reading the triggers separately, etc.)

[MDAWG25]

Originally Posted by JamesTerm

This is pretty cool. I believe, and Greg please jump in if I am wrong... only labview teams can use this kind of solution. If c++ and java teams could use xinput there is not anything that I have seen to do so in short of having to write our own application (e.g. make a wedge proxy to the dashboard with its own networking solution). IIRC I believe direct input had some preliminary functionality for that for rumble, but I have never tested using that so it is hard to say... The driver station uses direct input, but the c++ and java interface is limited to certain controls because all the controls and submitted in a packet and it is packed tight, so I am somewhat surprised that labview is not subjected to the same functionality.

The XInput DLL is loaded from the dashboard separately. The Smartdashboard should be able to load the xinput.dll just like the labview dashboard is.

[MDAWG25]

Originally Posted by Johnbot

That's actually pretty neat - I didn't know LabVIEW was that extendable.

Last year, team 2607 used a separate Java application running on the driver-station to add rumble functionality to our Xbox controllers.
We just read the button states from the application to trigger the hard and soft rumbles, but you could easily integrate it into your dashboard to communicate with the robot (which would also allow for other nifty things, like reading the triggers separately, etc.)

If I were to further extend the access to the DLL, I could in theory read every button on the controller and the triggers individually more like how PC games do.

[Alan Anderson]

Originally Posted by JamesTerm

This is pretty cool. I believe, and Greg please jump in if I am wrong... only labview teams can use this kind of solution.

The method Matt is talking about has nothing to do with how the robot is programmed. The code runs on the computer which has the controller plugged into it. The xinput DLL ought to be usable from any language.

[JamesTerm]

Originally Posted by Alan Anderson

The method Matt is talking about has nothing to do with how the robot is programmed. The code runs on the computer which has the controller plugged into it. The xinput DLL ought to be usable from any language.

Yeah.. that makes sense... the method doesn't but... the final problem to solve should be, and that was what I was trying to address. It sounds like labview would have to send a signal from robot to the customized NI Dashboard, and that would take the message and pass it to xinput to implement the rumble set interface.

[MDAWG25]

Originally Posted by JamesTerm

Yeah.. that makes sense... the method doesn't but... the final problem to solve should be, and that was what I was trying to address. It sounds like labview would have to send a signal from robot to the customized NI Dashboard, and that would take the message and pass it to xinput to implement the rumble set interface.

Yes, that is how it would have to happen. You can compare the flow to the PSOC board interface. To output a signal on the PSOC I/O board, the robot must generate the signal, pass it to the driver station, which then tells the PSOC board to set pin X high/low etc.

[Alan Anderson]

Originally Posted by JamesTerm

It sounds like labview would have to send a signal from robot to the customized NI Dashboard, and that would take the message and pass it to xinput to implement the rumble set interface.

LabVIEW is not required, and you don't need to use the default Dashboard as a starting point. The robot can be running a program written in any language, and so can the computer hosting the rumble-capable controller.

Minimal UDP communication from cRIO to computer is simple, but if you don't want to roll your own, there are well-supported implementations of Network Tables (and thus Smart Dashboard variables) for LabVIEW, C++ and Java.

[JamesTerm]

Originally Posted by Alan Anderson

LabVIEW is not required, and you don't need to use the default Dashboard as a starting point. The robot can be running a program written in any language, and so can the computer hosting the rumble-capable controller.

Minimal UDP communication from cRIO to computer is simple, but if you don't want to roll your own, there are well-supported implementations of Network Tables (and thus Smart Dashboard variables) for LabVIEW, C++ and Java.

Thanks for wording this clearer than what I was trying to do in my initial post... the confusion for me was... where the labview code was being applied.. I thought it was part of the robot code, but now I know it is a part of the custom dashboard.

When I was talking about doing this "(e.g. make a wedge proxy to the dashboard with its own networking solution). " I was hinting toward this solution. This wedges a proxy by being the main app that uses ShellExecute() to launch the SmartDashboar.jar. This way I can make my own code while still having full use of the Java client. In this project the compositor plugin has its own direct input implementation that runs parallel to the driver station's use of direct input. So yeah I could, and most likely will flip over to xinput. I'll want to use the same platform as the driver station for the sake of integrity... I know one day they'll switch and it may be next year.
On that note... they may indeed have full HID support and if so then all of this method will no longer be needed to gain full access of joystick support, but I'd still need it for the compositor. There is no confirmation on that, but I know it is a possibility as I've requested for it to do things like acquiring the joystick's name on any slot, and POV axis support etc... during beta.

Thanks for saying "well-supported" as the description of Network Tables.

[MDAWG25]

Originally Posted by Alan Anderson

LabVIEW is not required, and you don't need to use the default Dashboard as a starting point. The robot can be running a program written in any language, and so can the computer hosting the rumble-capable controller.

Minimal UDP communication from cRIO to computer is simple, but if you don't want to roll your own, there are well-supported implementations of Network Tables (and thus Smart Dashboard variables) for LabVIEW, C++ and Java.

I appreciate you explaining this better than myself.

[rpatel3001]

Originally Posted by Johnbot

Last year, team 2607 used a separate Java application running on the driver-station to add rumble functionality to our Xbox controllers.
We just read the button states from the application to trigger the hard and soft rumbles

Johnbot, would you be willing to post that code? I wouldn't want to reinvent the wheel for no reason.

[MDAWG25]

My fault, thank you Invictus3593, the library did not upload with the original post. The library *should be attached to this post.

[Invictus3593]

Originally Posted by MDAWG25

My fault, thank you Invictus3593, the library did not upload with the original post. The library *should be attached to this post.

Thanks!

[GuyM142]

Can I use the XInput DLLs to send controller data to the robot?
Will it be as responsive as the joystick library of WPIlib?