TABLET FOR DRIVER STATION

[MAldridge]

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.

[Greg McKaskle]

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.

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

[MAldridge]

Originally Posted by Greg McKaskle

Keep in mind that the kit cameras are 100MBit enet

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.

[Greg McKaskle]

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