Control Board

Has anyone tried using a different type of microcontroller for the control board other than the Cypress? My team and I are going to write our own dashboard program and I would like to use an interface that is more familiar to me like an Arduino. Does anyone know if this is even acceptable in the rules?

I in no way have a definitive answer for this, but I believe the DS is coded to only work with the cypress as an I/O board. If you were feeling fancy though, if you managed to make your board look like a HID joystick it should be recognized as such by the DS app and be able to be accessed like a standard joystick

One possibility is the use of something like Happ’s USB Game Control Interface ( Basically, it breaks out a slew of raw I/O pins from the USB port, and it is HID compliant. It also fits under past years’ cost allowances. There are a variety of buttons, switches, joysticks, and levers sold by Happ that are designed to work with it, but I would imagine that just about anything could be hooked up as long as the levels match up.

Thanks for the replies. I didn’t even think of something that sophisticated. However we are going to make our own DS and a networking library to read the data from the DS. So I was thinking like a microcontroller with serial communication? (the Happs interface definitely looks interesting and I will look at it more but I’m not entirely sure how I would implement it. Have you used it before?) Also, does anyone have suggestions for a networking framework for our custom dashboard? I was looking at OSC ( or just straight TCP. Any recommendations? Things you’ve used in the past?

For a dashboard program, anything goes.

It sounds like you’re talking about the driver station program, though. I expect that next year’s rules will let you use whatever hardware you want as a controller, so long as it connects to the Driver Station using only USB. I also expect that the required DS software will work only with the provided breakout board (i.e. Cypress) and with controllers which implement the USB HID protocol (e.g. joysticks). So if things don’t end up significantly more restrictive than I believe they will be, USB HID is basically your only constraint.

As Alan stated, everything has to go through the provided DS app in competition.

That being said, if you are still interested in hacking up a custom control protocol, I would say go for it. FRC doesn’t really expose students to network programming, so this could be a cool little project.

OSC would work fine for this (it’s just a fancy layer on top of UDP). I would not reccomend using a TCP stream to drive the robot. Basically, it turns out TCP is pretty good at delivering data reliably, with the cost of reduced speed. UDP is quicker, with the cost of possible data loss. I’ll leave it up to you to figure out why both of these things are bad, but one is worse than the other in terms of driving something real time.

Ya I thought it would be a fun learning experience also. In some of the earlier posts, it seems that I was glossing over the distinctions between the DS and Dashboard. Sorry about that. What I wanted to do was somewhat hacky but it would transmit data from buttons and such from the PC to the robot as well as receive and display data from the robot. The FIRST Driver Station would be left unmodified of course. A semi-related question: do you know what ports are open on the field?

The official answer is only the ones in use by the control system.

The actual answer is whatever the FTA actually set it up to be

Hey. I know how to use OSC and OSCulator. But, how would you connect this to the DS. What is all this UDP and TCP stuff??? Please help me!!