This year we were only able to use usb-hid joysticks attached to the DS, (as well as the 8 io and 4 analog). but my team would like to make our own pseudo joystick, using a microcontroller like an arduino. Would a usb-serial device (an FTDI chip) be able to be used on the driver station? 
or would i have to do something like AvrUsb on the mcu? 
[Explanation of USB device classes]
The USB specification contains several predefined âclassesâ of devices, each of which has a corresponding protocol of commands that are sent between the USB host (in this case the DS) and the USB device (the joystick). HID (Human Interface Device) is one such device class, CDC (Communication Device Class, the class most commonly used for USB-serial devices like FTDI chips) is another. These classes allow USB hosts to use generic drivers for devices that are connected to them, instead of requiring a driver for each specific device. The designers of the FIRST control system like this because it means that they only need one driver to be able to interface with almost every USB joystick (there are some exceptions, such as the Xbox controllers, which have been noted previously).
Because each device class has its own unique set of commands, a device that does not implement the HID class will not be able to work as a joystick. It will not be identified to the host as a HID device, and even if the host could be tricked somehow, the device would not know how to respond to the commands being sent. As a side note, the USB commands are also at a lower level than the serial data sent through a USB-serial device, which is itself encapsulated in USB data packets, so itâs not simply a matter of sending the right serial data over a USB-serial device.
[What your microcontroller needs to do]
In order to be used as a USB HID device, your microcontroller will either have to be connected 1) to another chip that formats the data into the format of HID packets, such as maybe taking apart an old joystick and wiring the various buttons and potentiometers to digital and analog outputs, respectively, on your microcontroller, or 2) directly to the USB bus, such as in the AVR USB design.
[My recommendations]
I do not have any experience with AVR USB, and if they already have code that implements the right sections of the HID class, that could be a very viable method. However, I have made attempts before to implement USB on other devices, and while it is possible, itâs not fun to wade through the specification documents. If you use a microcontroller with digital and analog outputs, another option instead of wiring it to an old joystick is to simply wire it into the exposed analog and digital input headers on the side of the DS. This is what most teams use when adding their own custom controls.
Good luck,
âRyan
I would be very surprised if we have the same drivers station next year. So who knows what input will be avaliable.
is it possible to bitbang the io pins on the ds fast enough for ttl level serial?
we are building a touchscreen inteface to the driver station for autonomous mode, with liquidwareâs touchshield slide. if we could use the io pins then that could free up a lot of programming time
QFT
FTDI isnât the easiest way to go about this - FTDI Knowledgebase
Many microcontrollers will have demo code that will do what you want. I know firsthand that code for PSoCs and PICs are available, and Iâd be surprised if any USB-device capable uP didnât have it.
Theoretically, yes, you could use the digital inputs as a TTL serial line, as they run at 5 volts. However, you will only get you 50 baud, as the DS updates at 50 Hz (source). Using parallel inputs will get you 50 * 12 inputs = 600 baud (assuming you repurpose the analog inputs as digital). Either way, you will probably have to establish some sort of flow control using one of the digital outputs, flipping it each time an update is sent to the DS by the cRIO. Even with this, however, you still stand a pretty good chance of data corruption because thereâs no reliable way to know when the DSâs inputs are being sampled in relation to when the outputs are refreshed, the actual data is sent to the cRIO, or any other step in that process, so to be safe you would have to hold the data values across two transmission cycles, halving your data rate.
So in short, while it is possible, I believe you would be better off mapping the analog and digital inputs to the controls exposed on the touch screen, perhaps using digital potentiometers to output analog values if necessary. What kind of interface are you trying to develop on the touchscreen?
âRyan
The screen would be used to determine the position and place the robot should travel to during the auto period. the screen would be powered before the match and the position would be saved to eeprom, so on the next power up it would report to the crio a cartesian point (or points if possible) with rotation. so it would have to be read before the robot is enabled
If this is only to adjust auto-mode settings before the match, is there a reason you canât directly interface the touch screen with the robot itself instead of having to send the data over the wireless link? You could then even have the freedom to use a direct ethernet interface, setting up a server to run on the robot, which your touchscreen device could then connect to over a crossover ethernet cable. Depending on what your purpose was in developing this functionality, you might even be able to create the interface on a laptop instead of having to create your own embedded device.
As a side note, for other suggestions on how to rapidly set autonomous mode parameters, see this thread.
Of course. none of this applies if you need this functionality during matches as well.
âRyan
Though, im sure if i got it working for auto, then theyâd want to use it for an operator control :ahh:, so an interface to the DS would be best.
what baud could be obtained through usb? HID is for the most part uni-directional, so an output pin could be used to signal auto / tele modes.
and have it dynamically update the controls.
Do you know of any cheap ethernet controllers for mcus? your last point could make it into a small dashborad 
Telemetry, speed and other statuses could be displayed, and have it for times not in a comp :yikes:
True, I could see that kind of interface getting addictive⌠
Thereâs a couple of different ways you could go with this:
- Slightly higher-end microcontrollers often have ethernet interfaces built in. Many of these same controllers are also able to run Linux, which gives you the standard network suite (ifconfig, etc) that youâll be familiar with if youâve ever used a Unix-like system. The chip that I have the most experience with in this category is the Avr32 from Atmel. Certain models of the Avr32 chips also have builtin LCD controllers, which you may be able to use to output to your touchscreen. Linux drivers for the LCD controller are included, I believe. For more information, check out Atmelâs site or the user forum at Avrfreaks.net. If you choose to go this route, Atmel makes âevaluation boardsâ](Electronic Components and Parts Search | DigiKey Electronics) that basically save you the effort of having to design and fab PCBs yourself. Theyâre a little on the pricey side, but I still feel theyâre a good deal for what you get in the package.
- Alternatively, if you already have a system design in place and just want to add on ethernet functionality, there are several makes of ethernet to TTL serial converters. While I have not used any myself, I can pass along many good recommendations Iâve heard about Lantronixâs modules. The XPort line seems to be about what you want. The $50 price tag may seem like a lot, especially compared to the price you may be able to find on a raw IC that accomplishes the same purpose, but, again, this gives you an already assembled package, and itâs all about saving yourself the effort of having to solder tiny traces onto a PCB.
- If you want a completely assembled board, but donât want to go as far as the Avr32 eval boards, you may be able to find somehing like this board from SparkFun (this one built around a PIC).
One thing to consider though is that FIRST has been very particular in the past about what types of devices can plug into the control inputs of the DS/OI. They might not allow your interface to be both connected as a dashboard and as a controller.
Even USB 1 can get 12 Mbsp, but since youâre limited to packing your data into the amount of data that the joystick would be sending, I doubt youâll be able to get any more data through the USB ports than you will through the exposed analog and digital inputs. Itâs just a matter of how the input data is being sent to the processor in the DS; it all eventually gets packed into the data packets that only get sent at 50Hz.
âRyan
Well, does the lantronix xport have an output saying if an ethernet cord is plugged in?
if so, then the board could dedicate all processing time to the parsing of dashboard data and ignore the touchscreen
(it would still get power from the DS though and the oled screen would be showing the data)
or it could send the commands for auto then switch to a dashboard display and disable the touchscreen, the dashboard data has the game mode in it right?
According to the datasheet on the Lantronix website, yes.
Iâm still a little fuzzy on how youâre planning on sending the data entered onto the touchscreen to the robot. If youâre planning on sending it through the inputs on the DS, then yes you should be able to detect the game mode through the dashboard ethernet port and send the data at the appropriate times. My previously stated concern over the legality of having something attached as both a dashboard and controller would then still apply; not to overly discourage you.
Just to clarify, though, you wonât be able to send data back to the robot through the dashboard ethernet port (based on this yearâs rules/field setup), as the DS blocks all traffic besides the dashboard packets coming from the robot when it is in competition mode.
I would also warn against trying to draw power from the DS. According to the information provided in the control system manual, the DS is only rated for 900 mA, total system current. I donât know what the exact specification on the exposed power pins are, but Iâd be surprised if you could draw much more than 150 mA, since theyâre intended to be used primarily for pullup sources or similar. That may be enough to power a microcontroller by itself, but the driver for your display alone is going to draw considerably more than that.
âRyan
i was thinking of using a digital potentiometer into the Driver station
i wouldnât, what i was saying was that it could send the position through the analog in, and then be used as a dashboard for the rest of the match, so for 95% of the game its an output onto the screen
could the 5v lines be connected in parallel?
Ok cool.
I did a little more looking, and I stand corrected on my previous assumption:
<R84>
Please note that the power available through the USB ports, digital I/O, and analog input pins is limited to 2 amps total. Care must be taken to ensure that any team-provided devices connected to these sources do not over tax the available Driver Station supplied power.
Seeing as your joysticks will be drawing some power as well, Iâd say youâd be safe with 1700mA. But yes, I would suggest ganging several of the power connectors if youâre going to be drawing that kind of current. Just to be safe 
Note, however, that the wall wart supplied in the KoP is only rated for 1000mA, so youâll have to make other arrangements to supply the needed power while developing the system.
âRyan
well this is the screen that will be used
http://www.liquidware.com/shop/show/TSL/TouchShield+Slide
i donât know its power usage, (plus an xport ethernet, and arduino (atmega 168)), hopefully it not going to be too much
One option would be to use the analog inputs - you might be able to produce two voltages proportional to the X and Y axis on the screen.
My favorite method is still to pretend to be a USB joystick.
The wallwart supplies 1000mA**@12V**. This is enough power to create 2000mA**@5V** using a switching regulator. Perfect Linear regulators are current in = current out. Perfect Switching regulators are power in = power out. Reality doesnât match ideal: (most) Linear regulators will draw a little extra current, and typical switching regulators are ~90% efficient.
The actual pins on the DS can safely handle 1 Amp each, so 2 should be fine.
Yeah, thats what i was thinking of doing,
take 3 analog pins
1 X
2 Y
3 Point #
and update per point on screen
Yes, that would be very cool, but iâm not sure if theres enough memory on the atmega 168 for that (the screen + usb is almost all the available memory and ram)
How much power does the competition port provide in a competition?
PLEASE NOTE: I have very little experience programming, so what I am about to say may not work, it is just an idea.
I was just thinking, if you really want a touchscreen device, use an iPod touch or iPhone. With the release of OS 3.0, Apple opened up the possibility of utilizing the usb connector for outside devices. Maybe you could build a program for the iPod/iPhone to emulate a HID and get it to connect to the DS.
The referees may not allow it due to the many types of wireless communication that it can do (wifi, bluetooth, cell phone) and i donât know if its a usb host, if its not a HID implementation my not be possible
While i wait for everything to arrive (Slowwww mail :mad: ), i have almost finalized how its going to work (Ethernet pending)
3 Analog inputs on the driver station,
#1 X input 100 points of resolution (Have to account for Electrical noise)
#2 Y input 100 points
#3 Point # 50 points (To reduce waypoint navigation math)
1 digital in
#1 to signify point # change
1 Digital out
#1 To signify robot received point
1 digital potentiometer to the arduino and driver station
liquidware touchshield slide to arduino to digital potentiometer