Tablet Controller Legality

Essentially, I’m a programmer and I thought it might be a cool idea to use a tablet as a controller for our Driver Station.
I planned on implementing this by connecting the tablet to the Driver Station via an ethernet cable, writing a client app for the tablet which would send over various input data, and writing a host application on the PC which would convert the inputs into a virtual joystick.
However, I’m concerned about the legality of such a setup, and could not find any pertinent information in the rules. Would such a setup be legal?

Any input devices that isn’t wireless is legal. However, remember that FMS connects to your laptop via ethernet, so make sure your tablet input still works with FMS.

There was a team in the past two years that had used a Raspberry Pi connected to the DS as a “controller” via a TI MSP430 Launchpad as a controller, and it was deemed legal through the wired connection. They used it to make a “Pipboy” from Fallout.

In theory, you could use Ethernet to the laptop and use the tablet as a networktables client to send commands to the robot. Realistically, I have no idea how that would be called or interpreted, and I would seldom leave a critical portion of robot functionality to a potential blocking via an official.

A regular “USB” controller is your safest bet imho.

While the tablet is not specifically against the rules… R98 requires the DS to connect directly to the FMS IE not through a switch. You could use a second Ethernet NIC (controller) to connect to the tablet, but that might cause problems connecting to the robot/field. Unfortunately the connections issues might only show up when connected to the FMS

Now that you’re allowed to use any computer that runs windows for the driver’s station… why not just use a tablet PC and some off the shelf software that does input device emulation.

However, fussing with a touchscreen would not result in a fast and intuitive controller from what I have seen at competitions. Since your drive focus will likely be out on the field (with maybe some time on camera), tactile solutions work really well.

Have you asked your driver(s) what they want and what they feel will give them a real competitive advantage? They are the ones who will be expected to produce results using what you are proposing to implement. There are different interfaces used by the drivers on various teams (most often joysticks or gamepads) and they are often chosen due to the preference of the drivers to maximize their efficiency. It may be possible for you to emulate/implement the tactile feedback that the drivers want/need but it will take some careful thought on your part.

If you are wanting a programming challenge, you may want to discuss this with your team and get their buy-in first. This may be better as an off-season project where you can really spend time and learn what the drivers need and work out any bugs and get some objective data before deciding whether or not your team wants to use it in competition.

First off, thank you all for your replies, they’ve been very helpful so far.

Have you asked your driver(s) what they want and what they feel will give them a real competitive advantage?

However, fussing with a touchscreen would not result in a fast and intuitive controller from what I have seen at competitions.

Yes, I’ve talked with my drivers about the idea. I was actually planning to use it as a secondary controller, making use of the touchscreen to allow for autonomous motion (via my own A* and collision avoidance code) to any point on the field. As I’m sure you can imagine, they really liked the idea.

This may be better as an off-season project where you can really spend time and learn what the drivers need and work out any bugs and get some objective data before deciding whether or not your team wants to use it in competition.

This was actually planned to be an off-season project, apologies for not specifying that. I just wanted to know this year’s rules as I assumed next year’s will be similar.

You could use a second Ethernet NIC (controller) to connect to the tablet, but that might cause problems connecting to the robot/field. Unfortunately the connections issues might only show up when connected to the FMS

I did not know about this. I’ll have to prepare a plan B just in case. (Maybe use the tablet as the driver station?)

Realistically, I have no idea how that would be called or interpreted

The tablet client app would periodically send the following data across the socket to the host program: a bool containing whether it is being touched or not, and the x and y location of any touches (if touched) mapped to values between -1.0 and 1.0. The host program would then use put the values in as axes and a button into vJoy (a virtual joystick driver).