Chief Delphi - Best board for vision processing (beagle/panda/beaglebone/etc?)

Like many here, I've been wondering if any of the solutions here are worth pursuing. The attraction of doing vision processing on the robot is clearly understandable, but the cost, complexity, and unclear benefit really put a damper on my enthusiasm.

What is the difference in latency between doing image processing on the driver station, versus a hard wired image processor? If your onboard image processor only has one NIC and a wimpy processor, then it may have no advantage over a powerful driver station laptop.

Do you plan on hope? Many of the mini-ITX boards and the various ARM boards have really bad drivers, and spotty support. As mentioned earlier, the LabView vision processing routines are very fast and efficient. Most open-source vision stuff is not in the same league.

Just to put a finer point on this, I offer a comparison of apples to brussel sprouts. For the last few years, you can go to a Best Buy, and pick up. $99 Apple TV. The current one uses the ARM-based A5 processor that was in the iPad 2 and a few other models. This processor, while fast for an ARM chip, is not very powerful when compared to most intel chips produced over the last five years. In the Apple TV, this chip pushes out flawless 1080p video to any connected TV, as it reads a stream of data over a wireless network.

Now on to the brussel sprouts. Most of the mini-ITX systems are sold to do exactly the same thing, but they run Linux or Windows. Even running free Linux, they cost more than twice as much (not counting labor here). With much more substantial processors, RAM, and hard drives, these boxes struggle and often fail to deliver smooth 1080p video. Why?

I know I am comparing a specialized device to a general device that the users attempted to specialize. The point I'm trying to make, is that a lot of energy went in to making the $99 video device "just work", while the cobbled solution is relying on lots of disparate hardware and software to not screw things up too terribly. Any one non-optimal part, soft or hard, can compromise the function of the system beyond the ability of the rest of the parts to compensate. Do you have the time to find the limiting bottlenecks in code that you didn't write, or time to write drivers for hardware with no available documentation?

For my team, it comes down to the fact that another computer on the robot takes money and weight away from the component cost and weight budgets that all FRC teams have to deal with. Vision processing on the driver's station is free of weight or cost issues. Certainly there is a small latency issue, but it is still faster and more convenient for debugging than a robot-mounted solution. Perhaps if we mounted the Kinect on the robot (cost and weight) to get some amazing edge, then we would probably change course. Right now, my team just doesn't have the programming bandwidth to consider this. That could all change on Jan. 5th. :rolleyes:

I'm hoping for magical advances for onboard vision. Perhaps a few here will make them and I will tip my hat in appreciation and acknowledgement. Certainly the state of the art will not advance without teams pushing the boundaries. At the same time, we should all remember that good engineering requires objective analysis of value for all associated costs.