Joystick type field in HAL_JoystickDescriptor

We’re developing some robot-side code to ensure it is seeing the right joystick configuration on the DS, and lighting up an indicator on the dashboard. To figure this out, we’ve been experimenting with HAL_GetJoystickDescriptor() which provides a structure called HAL_JoystickDescriptor.

This structure is pretty self explanatory, except for the type field. This is only documented as “This is device specific, and different depending on what system input type the joystick uses.”.

After trying it with a variety of joysticks and gamepads, there wasn’t an obvious pattern, and the values don’t correlate to any USB device descriptors I’ve found. My best guess is it relates to the driver that Windows on the DS uses to talk to the Joystick.

Anybody know exactly what the HAL_JoystickDescriptor.type field means?

Ultimately, I don’t think it matters too much; we’ll just look for the three devices we expect to find by name (or at least match the first 3 letters).

BTW, here are the details for all the joysticks/pads I tried:

Joystick HAL_JoystickDescriptor
Description Notes .name .type (dec) .type (hex) .isXbox .buttonCount .axisCount .povCount
Logitech Gamepad F310 Same regardless of mode toggle “Controller (Gamepad F310)” 1 01 1 10 6 1
Logitech Extreme 3D “Logitech Extreme 3D” 20 14 0 12 4 1
Saitek ST290 Pro “Saitek ST290 Pro” 20 14 0 6 4 1
Playstation3 Controller via USB; doesn’t actually work “PLAYSTATION®3 Controller” 20 14 0 19 4 0
VKBsim Gladiator Mk. II Thumb & Pinkie buttons not recognized “VKBsim Gladiator” 24 18 0 29 7 1
TI LaunchPad Option 1 Firmware “MSP430-USB Gamepad” 24 18 0 11 8 0
Arduino Leonardo With Joystick Library “Arduino Leonardo" 28 1C 0 ~ ~ ~
eStop Robotics CCI Custom control interface eStop Robotics HID 21 15 0 12 4 1

If isXbox=1, type is the Type field returned by XInputGetCapabilities. Reading the documentation, this isn’t very useful (it would have been more useful if it was the SubType field), as it’s basically always 1 (XINPUT_DEVTYPE_GAMEPAD).

If isXbox=0, type is the DevType field returned by IDirectInputDevice8::GetDeviceInfo. The documentation only gives the enum value names, but the dinput.h source gives the values:

#define DI8DEVTYPE_KEYBOARD         0x13
#define DI8DEVTYPE_JOYSTICK         0x14
#define DI8DEVTYPE_GAMEPAD          0x15
#define DI8DEVTYPE_DRIVING          0x16
#define DI8DEVTYPE_FLIGHT           0x17
#define DI8DEVTYPE_1STPERSON        0x18
#define DI8DEVTYPE_DEVICECTRL       0x19
#define DI8DEVTYPE_REMOTE           0x1B

As you discovered, this is pretty generic, as only the type and not the subtype is provided. I agree with your approach of using the names as a better way to disambiguate joysticks.

1 Like

Awesome - thanks for the quick and definitive reply!

Do you know if there is a callback or a flag that indicates the joystick configuration has changed? I’d rather not have to compare descriptors frequently to see if the setup has changed, but I haven’t found anything.

— Dean

There is no callback only on change. In addition, the descriptors are sent over TCP, so they’re not part of the control packets so you can’t synchronize them to the new data checker either. There is no notification for this at all anywhere on the robot code side either, so even at the low level it’s not possible for us to implement.

Thanks for confirming that - that’s about what we figured. We noticed that fetching the joystick data right after the DS connects doesn’t work.

It seems to work OK scanning the 6 slots just comparing the .type and the first character of the .name, which is enough to differentiate our 3 devices. Comparing all 6 slots only takes a few dozen microseconds; maybe 100µs worst case.

We’ve got it in RobotPeriodic() now, but if it starts to bog down our main loop we could move it off to a separate thread that only checks once a second or so.

— Dean

Those calls are just a mutex and a read, as they’re actually reread manually from the JNI layer every control packet. So its very cheep to actually read those from the DS class, and should be deterministic timing.

1 Like

The driver station disables the robot if joystick configuration changes. Thus you only need to check when disabled.

Not when connected to the FMS however, I believe.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.