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 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.

[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?

[Alan Anderson]

Originally Posted by GuyM142

Can I use the XInput DLLs to send controller data to the robot?

You can send any data you want to the robot. You can get that data any way you want (subject to robot rules).

Will it be as responsive as the joystick library of WPIlib?

Your custom data will be as responsive as you want to make it (subject to bandwidth limitations). The joystick data provided by the standard WPI library functions is part of the Driver Station communication which occurs 50 times per second.

[JamesTerm]

Originally Posted by 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?

Why would you want to do that if I may ask... is there something XInput offers that the joystick library does not?

I know about the analog trigger buttons (direct input issue), and some limitation of the POV's (WPIlib issue). Hopefully that's all of them.

[Peleg2230]

I got a tricky question...

If there are two Xbox controllers connected do they both vibrate?
(We don't have two controllers to check it out in our lab...)

[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.

[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.