Driver Station Usb

[biojae]

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?

[RyanCahoon]

[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

[IndySam]

I would be very surprised if we have the same drivers station next year. So who knows what input will be avaliable.

[biojae]

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

[EricVanWyk]

Originally Posted by RyanCahoon

...

QFT

FTDI isn't the easiest way to go about this - http://www.ftdichip.com/Support/Know...icesappear.htm

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.

[RyanCahoon]

Originally Posted by biojae

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

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

[biojae]

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

[RyanCahoon]

Originally Posted by biojae

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

[biojae]

Though, im sure if i got it working for auto, then they'd want to use it for an operator control , 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

[RyanCahoon]

Originally Posted by biojae

Though, im sure if i got it working for auto, then they'd want to use it for an operator control , so an interface to the DS would be best.

True, I could see that kind of interface getting addictive...

Originally Posted by biojae

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

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" 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. <Insert disclaimer that I've never been a robot inspector and that rules are subject to change without warning from year to year anyway>

Originally Posted by biojae

what baud could be obtained through usb?

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

[biojae]

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?

[RyanCahoon]

Originally Posted by biojae

Well, does the lantronix xport have an output saying if an ethernet cord is plugged in?

According to the datasheet on the Lantronix website, yes.

Originally Posted by biojae

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?

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

[biojae]

Originally Posted by RyanCahoon

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.

i was thinking of using a digital potentiometer into the Driver station

Originally Posted by RyanCahoon

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 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

Originally Posted by RyanCahoon

I would also warn against trying t 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

could the 5v lines be connected in parallel?

[RyanCahoon]

Originally Posted by biojae

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

Ok cool.

Originally Posted by biojae

could the 5v lines be connected in parallel?

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

[biojae]

well this is the screen that will be used
http://www.liquidware.com/shop/show/...chShield+Slide
i don't know its power usage, (plus an xport ethernet, and arduino (atmega 168)), hopefully it not going to be too much