Using a (Logitech) Controller?

[ctccromer]

Hey guys. So I'm still very new to LabVIEW (though thankfully not to programming in general). I finally got our cRIO imaged today and managed to deploy the starting code that FRC provides -- unedited -- over to our cRIO.

The last two years we've used 2 logitech joysticks, but long story short, we're switching to a controller this year and I do not have contact with our programmer for the last 2 years. Everything I learn will be from chief delphi, other online sources, and studying his code from last year.

So now my question: What's different between coding for 2 joysticks and coding for a controller? It has two joysticks and a dpad as well as some buttons, but when I tried running the starting code with it, only the left joystick worked.
Rather than programming Joystick 1 and Joystick 2, each with 2 axes, do I need to program Joystick 1 with 4 axes and just make it so that the first 2 axes are the left joystick and the second 2 axes are the right joystick?
What else might I run into trouble with?

Thanks for any/all help! I'll update this with a link to the specific Logitech controller we're using in the morning when I'm at school

EDIT: We're using a Logitech F310 controller

[Greg McKaskle]

From your description, you have it under control. You may want to pay attention to the positive/negative direction of the coordinate system, but the change you described should work.

Greg McKaskle

[ctccromer]

Originally Posted by Greg McKaskle

From your description, you have it under control. You may want to pay attention to the positive/negative direction of the coordinate system, but the change you described should work.

Greg McKaskle

Okay thank you. I just wanted to make sure this was necessary and a good work around if so

I'll use this thread for any other questions I have about controller vs joystick programming

[Ido_Wolf]

To tell the difference easily if it ever happens to you again, just open your Driver Station and go to Setup with the controller connected to the PC.

You'll see a drag&drop list of all the joysticks connected (if a joystick doesn't appear, just push a button on it and the list would refresh). The first joystick in the list is the one you set to "USB 1 port" in your code's Begin.vi, the second is USB 2 etc.

You'll also notice that a controller would only take one slot in said list, while your 2 older joysticks would take one slot each. So, going by this logic, you'd need to use just one reference for the controller in LabVIEW like you said. Some joysticks and controllers (typically the vast majority of them other than Logitech Attack 3 or Xbox 360 controller) are completely messed up when it comes to axes/buttons ordering, you can either fix that by utilizing the appropriate drivers or making a small LabVIEW program with indicators for all the joystick's outputs and make a chart out of it.

Tip: In my experience, it's much easier to test your code with joysticks though, especially the ones that have winch/throttle axes as they're so flexible and you can assign certain tested variables to those extra axes and you get so many options with all these buttons on 2 joysticks. Plus, pulling the trigger feels MUCH more natural with a joystick to me when testing a shooting system, and the migration to a controller (in case the driver wants that) can be done very easily even without the robot between the end of the build season and the competition. But all in all it's your choice of course

[ctccromer]

Originally Posted by Ido_Wolf

making a small LabVIEW program with indicators for all the joystick's outputs and make a chart out of it.

This is what I was planning on doing today, but quickly found out that I dont know labview enough ... How do you make a simple system that simply does:

When Button 1 == true, light up a light on the front pannel. (When false, dont light it).

I couldn't figure out how to simply say Button 1. Or Joystick 1. I made the light Vi at least, hehe

And I'll keep that in mind, about testing on joysticks. Good to know!
Thanks for the help

[Joe Ross]

Did you find the joystick VIs?

[ctccromer]

Originally Posted by Joe Ross

Did you find the joystick VIs?

I found the OPEN vi but not the actual joystick or whatever is wired to the left (blue) side

[Mark McLeod]

Originally Posted by ctccromer

I found the OPEN vi but not the actual joystick or whatever is wired to the left (blue) side

Right-click on the Blue input and choose Create->Constant

"USB 1" should appear.
Change it with the hand cursor.

[Greg McKaskle]

The attached picture shows how to show a button's state on the panel of teleop. If you want to show it on the dashboard, that involves writing it to a SmartDashboard variable and modifying the dashboard. Fortunately, the default dashboard already shows the state of all buttons and several axes.

Greg McKaskle

[ctccromer]

Originally Posted by Greg McKaskle

The attached picture shows how to show a button's state on the panel of teleop. If you want to show it on the dashboard, that involves writing it to a SmartDashboard variable and modifying the dashboard. Fortunately, the default dashboard already shows the state of all buttons and several axes.

Greg McKaskle

how do you get the Button 1 part? I got the JoystickGet.VI and tried right-clicking on the button area on its right side, but couldn't figure out how to add a Button like in the picture

[Mark McLeod]

right-click -> Cluster, Class, Variant Palette -> Unbundle By Name
Then wire the resulting box to the output node on the Get (either Axes or Buttons).
The resulting box can be changed to the button/axis you want, or expanded to reveal several buttons/axes.


Another way, for looking at everything on the Joystick, is to right-click -> Create -> Indicator
for both the buttons and the axes.

[Ido_Wolf]

Mark McLeod's way to handle it is the best in that case (making an indicator for the entire cluster), but also note this:

In some cases, you may want to see what kind of data flows on a certain wire while running deployed code. In that case, you don't have to create an indicator for each wire before running your code, simply press on the wire while the code is deployed and running to display a probe of its data.

[ctccromer]

I just made a program in LabVIEW (attached pictures of the Block Diagram and Front Panel). After making it as pictured, I plugged in my controller via USB port and clicked "Run Continuously" in LabVIEW

However none of the lights lit up when I pressed the buttons on the controller

[Mark McLeod]

Your program is only a sub vi and won't perform on it's own.
It's missing some essential stuff like communication with the Driver Station that reads the joystick.
You also need to have the Driver Station app running along with your LabVIEW session.

It would be easiest if you created a default robot project, from the Getting Started window, then added your code to the project.
The default project has most of what you need already, including one joystick.
We can walk you through the steps to take. For example,

1. Create a Robot Project (inserting your team number into the IP address)
2. Expand the Team Code folder
3. Edit the Teleop.vi block diagram
4. To begin with use just the Joystick that is already there to display it's buttons.
5. Open the Robot Main.vi
6. Press the Run arrow to start your project
7. Plug your game controller into your laptop
8. Start the Driver Station app.
9. Go to the Driver Station Setup tab and see if the game controller is listed on the right in the first/top position. If not then click and drag it up to the USB 1 spot.
10. Enable the Driver Station.
11. Go to the Teleop front panel to see your button displays.

This is the general format to use a joystick


Take a look at some of the NI tutorials at: https://decibel.ni.com/content/docs/DOC-8923
The [FRC 2013] FRC Robot Framework Tutorial would be a start.

[Greg McKaskle]

As Mark pointed out, your VI was running on the PC, not on the cRIO. The WPILib VIs to read the joysticks don't work that way, and will be zeroes instead. The Joystick VIs work via the driverstation protocol and the VIs read those values on the cRIO.

Greg McKaskle