[flameout]

I'm not aware of whether or not WPILib can deal with those axis and button counts, but I believe that you are correct in believing that FIRST's protocol doesn't transmit that extra data.

Reading the values on the dashboard and sending them over via UDP sounds like a fine solution. Off the top of my head, I can think of two possible issues:

1. Two programs accessing 1 joystick might be a problem (I don't think it'll be an issue, but _maybe_... all I can suggest is to try).

2. Delay in transmissions. I've done custom (not for FIRST robots, though) communication between a DS and a mobile robot, and if the packets get delayed or queued up, it's possible for a large delay in control response to form. I suggest taking 2 precautions: code a watchdog for your UDP transmissions (in case of loss of your custom UDP communications without a corresponding loss in "main" communications), and timestamp the packets.

By timestamping, I mean that it should have a way to detect if the packet is too "old." I'm not sure if the dashboard protocol includes match time, but if so, that could be used.

Alternatively, the robot could transmit time (in milliseconds since boot) to the dashboard, which timestamps the packets it sends back to the robot (this would be more work, but might be more reliable (not having to deal with teleop/autonomous/disabled modes)).

I hope this helps, and good luck (I've seen teams using the Saitek X52 system, which sounds like what you're referring to. I'm not sure if they used buttons and axes not transmitted by WPILib, though).