does anyone know of tablets that work for driver station?

I would imagine any windows tablet would work as long as it is Intel or AMD. The new Microsoft Surface tablets could do nicely, but they will likely be $1000+ upon their arrival to the market this fall/winter. HP has a tablet and I think Dell does as well. Only issue I see is that you will probably need a USB to ethernet adapter to connect to the field because I don’t think either one has ethernet.

Edit: HP does indeed sell a tablet, the HP Slate 2 which runs windows 7 so you can put lab view on it for the drivers station and so does Dell, the Latitude ST. The HP starts at $700 and the Dell at $760

Any tablet running an operating system compatible with the Driver Station software (Currently Windows XP and 7) will work, but as already stated it must have an ethernet adapter and at least one USB port.

That being considered, you would have to use a laptop-style tablet. I’m not sure why you would go that route unless you plan on a touchscreen being integral to your DS setup.

You could probably get a Tablet/Laptop like Lenovo has. They look great from the task, but can get pretty expensive. They have Tablets also but they are only running on Android right now, they should have a windows one soon.

I had this Lenovo netbook for a while. Off the shelf, it was awful where performance was concerned. Windows 7 isn’t made for a touch device, so I wound up writing my own utilities in Java to launch applications, do some monitoring, etc. I also stuck a solid state drive in it, used a blank copy of Win7 Home (to get rid of the Lenovo crapware) and doubled its RAM for performance.

For FRC, that tablet is pretty good if a team knows how to program an interactive touch display. It’s only slightly larger than the classmate. It can do dual touch (though getting that through to Java is next to impossible without custom JNI libraries). It’s lightweight. Java can emulate several things, including a USB device or keyboard – so it can replace a button board while also showing the state of the robot.

However, the interactive Java display can go on other displays as well. Look for other touch netbook convertibles, not just tablets. Having a netbook that works with Windows out-of-the-box will save you compatibility problems.

We used this laptop-tablet this year:

Our mentor just received his Alienware laptop, and decided to give us his 4 year old Thinkpad X61 tablet. Ours had a Core 2 Duo processor, 500GB, 2GB RAM and a special SSD memory device to boost top speeds. Needless to say it worked perfectly. Booting up took less than 20 seconds, and we could go from shutdown to field-ready in under a minute.

The only cons was that there was no DVD drive, you would have to buy the expansion base separately, and the screen was a little hard to see outdoors. Oh, and you could only input using the screen/stylus (which were surprisingly accurate), or the red trackpad thingy - there was no touchpad.

If you want to do a fresh install, all the current drivers (most updated in 2012) are easily available on Lenovo’s site. Just make sure to install Wacom’s special driver as well. Ebay prices are $400 - $700 depending on condition.

I’ve used a Lenovo ThinkPad X61-T for years as a classroom computer. They are rock solid, sturdy, and have plenty of upgradeable specs. They glass on the screen is really good too. After almost 5 years of writing with the wacom pen there are hardly any scratches. The “multi-touch” screens allow for human input as well.

I’ve seen teams use UMPC’s before with mixed results. I personally have owned many tablets over the last few years. Currently I have two tablets a Fujitsu Stylistic 1440 and a Motion Computing m1200. I regularly use the m1200 to drive at demos, but it is rather finicky because the pentium series processor in it doesn’t support SSE2 optimization.

Another computer of mine I use a lot is a Panasonic Tough book, they are small, practically indestructible and have a screen that spins around and then folds flat.

One thing you should be wary of is that because tablets don’t look like normal computers, field personel may give you a hard time. Also, if anything goes wrong, you really won’t be able to troubleshoot because a touchscreen display isn’t that easy to navigate quickly, and the parallax on a pen driven display is even harder to work with in a fast and accurate way.

I’m guessing the Intel Surface (there’s 2 versions) would cost around $950. Certainly not over 1k.

Microsoft had said that it would be comparable to ultra books and since most of them are $1000+ that’s what I said. And anyway if you can spend $1000 you can spend $950, I guess it’s better to go a little over and find it’s cheaper than to be short some money.

or you can use a 6-7 year old machine with an intel chipset and just use that. Difference of about $900 if you look around.

When looking for a driver station computer, I would keep in mind any current or future vision related demands that would be put on the driver station device. Also remember that while some old lap tops that can be had for cheap work when connected by wire to FMS can have lag problems when used by direct wireless link to the router.

true, old laptops sometimes have speed issues. given that the OP appears to have some funds at thier disposal, I would say use a machine with at least 10/100, and offload the vision to a single board pc on the robot, cutting out network lag entirely.

and offload the vision to a single board pc on the robot, cutting out network lag entirely.

Keep in mind that the kit cameras are 100MBit enet, and the comms on the robot are often enet to single board computers. So you are mostly simplifying the network, not cutting it out entirely.

You can look at the numbers on the DS to see what the trip time is for small packets like the control packets. It is also pretty easy to make a latency tester to numerically measure it.

  1. Use the dashboard PC to display a numeric indicator with a large font and the camera image.
  2. In a loop, update the indicator every 5ms or so with the milliseconds value.
  3. In a parallel loop, get the camera images and display in the image display.
  4. Point the remote camera at the computer display.

You now have a side-by-side display of the source time and measured time updating too fast to really see.

  1. Take a screen-shot to freeze the display and you’ll see that the camera image is delayed by x milliseconds compared to the source.

You should do this a few times and plot the numbers you get. Keep in mind that the monitor will not display text to the screen when you tell it to, but on the next refresh, which is up to 10 or 12ms later. So you have jitter in your measurement, but the smallest number in your sample is a good estimate of the latency you’d see for a source that isn’t a raster display.

To time latency with a computer that doesn’t have a display, you may need to flash LEDs or use a 7 segment display that you drive via digital lines – get creative to drive a source, and do processing to measure what the camera sees. Determine how long in the past, the camera is accurately describing things. You can also have the source be something not controlled by the computer, but measured by it in different ways. You could have a pot or encoder connected to a pendulum, and measure the location of the pendulum with the camera as well and compare the latency of the camera measurement.

My point is that I encourage you to measure the latency rather than assume one approach has it and the other doesn’t.

Greg McKaskle

If you use something like a USB webcam, you can bet much better speed than the kit cams. Plus, if you have USB onboard, it might even be possible to use the kinect’s 3d imaging functionality:) .

Neat idea with the screenshot, I have had people wave their hand in front while watching the screen to see if it was really bad lag, but I never thought about trying to get a time reference in frame with both ends in there.

I believe most USB webcams have an upper limit of 30fps. The difference between them and the kit cameras is that the kit cameras are compressing the image and sending it over 100MBit enet. Since the USB2.0 spec allows more bandwidth, about 480 MBit theoretical, the camera streams are usually not compressed, though the Kinect does compression for the higher resolution modes.

Fortunately, kit cameras were selected that do the compression in HW, so they don’t introduce much lag.

For industry, where camera rates and resolutions are often much higher, USB is becoming popular along with other standards such as GigE (gigabit ethernet), 1394 (FireWire), and Camera Link.

Greg McKaskle