Who used Driver Station for Vision?
 

I am just wondering who was using their Driver Station or an non cRIO computer for Vision Processing in Rebound Rumble, and what are you going to do next year with the new field data limits.

On a side note, because of the $400 limit of parts on the robot and the new allowance of laptops allowed on robots, would people like a price raise limited for laptops/alt. computing devices that could go on the robot?

Re: Who used Driver Station for Vision?
 

Where did you hear about new field data limits?

Re: Who used Driver Station for Vision?
 

Page 23 of the Einstein Investigation Report: <http://www3.usfirst.org/node/2426>
Ideally each of the 6 teams on the field will get ~50Mbps, most of which will go to FMS/Robot Control data.

Re: Who used Driver Station for Vision?
 

I'm pretty sure the robot control data doesn't take more than about 1KB per update, at around 50 Hz. This gives you 400 Kbps for robot control data.

To transmit a single frame of video with 320x240 resolution and 24bit color is 320*240*24 = 1.8 Mb. Note that the Axis cameras use MJPEG compression as well, so this is a gross overestimate. For targeting purposes, given the network lag that's going to be inherit in the system, you shouldn't need more than 10 fps. Maybe 15 if you want smoother-looking video for display to your drivers.

That's still only 30 Mbps (even with uncompressed video).

Re: Who used Driver Station for Vision?
 

Note the word Ideally, 300 Mbps it the theoretical bandwidth for 802.11n with the FMS router and robot in channel bonding mode (this doesn't happen as far as I know), but can drop to under 130 Mbps which would then give each team ~21Mbps or under. Also to do nice detailed image processing my team used 640x480 resolution on two cameras in stereo, pushing us to ~14 Megabits(7Mb*2) for both images at ~15FPS, excluding network overhead, this according to the FMS people in Raleigh was getting close to taxing the FMS when we were the only team using vision on the field during a match.:confused: :eek:

Re: Who used Driver Station for Vision?
 

Here's is what the Q/A said for last year:

Re: Who used Driver Station for Vision?
 

Acknowledged - just pointing out that the needed bandwidth is fairly close to the actually available bandwidth, not many orders of magnitude difference. I'm actually hoping they can implement a robust QOS system; it will make our jobs much easier instead of having to implement throttling ourselves.

Did you do any testing to compare your accuracy against a lower resolution?

Re: Who used Driver Station for Vision?
 

341 used off board vision using Java/SmartDashboard. It worked really well for them. One of the top 5 teams in FRC this year. We used their code as well, it made a huge difference for us.

They were kind enough to put their code up on Delphi, so take a look if your interested.

-RC

Re: Who used Driver Station for Vision?
 

Yes, we tested on lower resolution. Refer to my teams white paper for examples of a 640x480 image and how far apart our cameras were. The reason for the large images is for calculations, low resolution images give larger errors in our distance and angle calculations due to the pixels.


*Edited top Question*

Re: Who used Driver Station for Vision?
 

That's what I had assumed, but I'm curious if you noted how much larger the errors were. I'd also be interested in the errors of the stereo distance measurement vs the perspective distance measurement as a function of distance, if you have them.

Re: Who used Driver Station for Vision?
 

Due to the events on Einstein some of the rules regarding networks have changed. One of those is that there's going to be a bandwidth limit for each robot and QoS to ensure the driver commands can make it through with as little latency as possible.

Re: Who used Driver Station for Vision?
 

We ran our vision on Dashboard.

I set the fps limit to 20fps. Due to the design of the control algorithm we used, more frames is better, so we try for 20. We get images at 320x240 (we determined this was the smallest size that achieved adequate resolution with the fish-eye lens we used).

If we encounter any bandwidth limit in the future, we'll either run smaller or slower. Running at 320x240 at 10fps is still far better than what the cRio on its own is capable of (I don't think we could get more than 6fps at any resolution, given the amount of processor utilized by non-vision code), and any solution that is weight neutral on the robot the solution we will almost always choose.

Re: Who used Driver Station for Vision?
 

I would think a better plan would be to have the vision processing calculated on the robot, use of cheaper and better USB cameras with low image capture lag, with a light and powerful laptop and send relevant data to the Driver Station/Robot. But alas there is a dreaded $400 limit to ALL parts, if only laptops that would go on the robot could be a little more expensive the FMS would not have a need to worry about large images clogging the field network...:rolleyes: ;)

Re: Who used Driver Station for Vision?
 

If you're worried about the price limit and weight, you shouldn't even be looking at laptops. Build your own Mini-ITX board. You can buy/bill the components separately and to your needed specifications, and that way you don't have to carry around the screen. There are power supplies on that site designed for car computers that are tolerant to voltage drop-out as well, so you can even power the computer off of the robot's battery, saving you more weight.

Re: Who used Driver Station for Vision?
 

For me the bigger question is, why doesn't FIRST just ditch the cRio and go with laptop controlled robots?

All it would take is a USB motor controller + I/O board (and since we already have FIRST-specific electronics that ship with the cRio, I don't see this as being a huge issue) and almost any laptop and you have a control system that can be easily upgraded/updated, has an independent backup battery (no worries about power loss on your controller), can be programmed in virtually any language, can run vision processing without eating network bandwidth, and, depending on what you get, can be cheaper and have more features than the cRio.