Our team is looking at doing some off-cRIO vision processing next year since the FIRST-provided vision API is so limited. We’re looking at purchasing one of the ARM-based boards to do vision processing with OpenCV and send whatever data we need over to the cRIO.
I know at least a few teams have done this last year. What have you used or seen others using as far as hardware? Beagle boards? Pandaboards? Something else?
I just received my $35 model B Raspberry Pi and am doing some initial testing with it. Off-season robots could use the 3x more powerful gooseberry pi (only wifi is supported so competition is out of the question). I’ve been contemplating creating a simple board with a single Ethernet port and a dspic33, pic32 or DaVinci processor…
In the performance category, a beefy driver station laptop is going to be very difficult to beat.
I would also have suggested the Raspberry Pi, the big issue is the time between ordering and receiving the board. I ordered one at the very end of June, and it’s not coming in until October. Those things are seriously popular somewhere.
We have a beagleboard XM rev C, with Ubuntu running on it. However we are having a real tough time getting OpenCV compiled and built for it. Currently stuck in the steps regarding ffmpeg as this portion refuses to compile. Does anyone have experience in getting this working that could assist me?
Recent production increase of the Raspberry PI and a memory increase to 512 makes this a better choice as a co-processor. Delivery times are now ~14 days, so ordering now is a must.
Still love the Beagle Bone for the IO farm it has, but for a small vision processor the PI has moved to the front.
I still think that computer vision isn’t possible this year. Too much color differences between shops (crappy incandescent), practice field (florescent) and game fields (mercury and sodium). St Louis has the new SuperLux lamps to make color and brightness on TV work well. But I think the improvements in processors will let the vision sent back to the player station be a huge bonus.
Foster, I have to agree with you on one point here, and respectfully disagree on another.
I think the PI has good potential to be an outboard video processor and am hoping to give it a try.
Lighting variations between your shop and the playing field should have little or no affect on your performance.
If careful White Balance and Brightness calibrations are performed in your shop, and then again on the competition field, you should have very similar, if not identical outcomes.
By no means should you allow either of these values to run in Auto mode, especially the White Balance.
We have successfully used cRio vision processing for the last few years with solid results because we made sure we performed these calibrations in both locations.
I’d recommend doing some benchmarks on these platforms before making a recommendation. The Pi, while a cool board for the price, is pretty underpowered for this kind of task. I was only able to pull about 10 FPS off a Logitech webcam using the Pi using OpenCV without doing any image analysis. I was using the Python bindings so there is probably some performance to be claimed by nixing the interpreter and compiling some C, but I don’t think it will be much.
Hello all, some more information from my earlier post.
I was running Ubuntu 11.04 on the beagleboard which ofcourse is an ARM processor. As it turns out, ubuntu removed support in the kernel for some of the features that I was trying to link against, and there really is no way of gettng this package to compile under 11.04 on arm. So, I did discover that OpenCV can be built into the kernel under Angstrom using the narcissus image building tool so that is what I am off to attempt now.
As a positive side effect of this, the beagle board now is clocking at 1Ghtz, rather than the 650 that ubuntu was running at, since the angstrom image is better optimized for this hardware.
I have been keeping an eye on that kind of solution over the past few years, but still remain relativity expressive. If a windows machine is a requirement, upgrading the driver-station (or a second one) might be a better investment. Although it’ll make using the Kinect easier to use the windows machine, I did find this with quick goofu, http://www.pansenti.com/wordpress/?page_id=1772
I’ve placed my order for a rPi, but is back-ordered. Some of the other arm based boards are also contenders, especially for robotics, despite the increased priced over the rPi.
Team 846 ran with http://www.newegg.com/Product/Product.aspx?Item=N82E16856119069 this offseason (replacing a beagleboard which we used during the season). It turned out to be a very convenient solution, small, light, inexpensive and powerful. We are booting ubuntu server off an SD card formatted to have both a windows readable FAT32 partition, and a linux partition. We are powering it with http://www.amazon.com/3-5-30V-4-0-30V-Booster-Converter-Regulator/dp/B008FLE7PA/ref=pd_ybh_15, which worked. The peak power draw (only during the boot) is roughly 20 watts. Its easy to work being x86 , and we don’t have to worry too much about performance. We’re running two vision programs all the time (one for aligning the robot shooting yaw and distance, and one for tracking and picking up balls autonomously faster than a driver can :P), and we just leave both running at the same time. We don’t even max out the CPU freerunning at over 30 FPS for both programs (admittedly with the same code that was originally optimized for the beagleboard).
In short, why we chose (and love) a solution like this:
Ease of use (x86)
Ease of powering
Lots of IO (The beagleboard only has a single USB port whose bandwidth is shared with the usb to ethernet chip and the usb hub)
Ease of fetching video and logs from the computer using the flash card
Modularity, its a lot easier for someone to work on the vision code at home, making it easier to involve more programmers.
Has anyone looked into using the Odroid X? It’s by a South Korean company, so shipping might be expensive. It has a quad core CPU and GPU, and runs Android. It supports up to 4 cameras, for any teams wanting to do stereoscopic vision. It has a built in Hardware Accelerated JPEG Encoder/Decoder, so that is a plus. It does have GPIO, I2C and SPI interface for additional sensor inputs. I know that there was rules regarding the cRio being the sole board to actuate any mechanisms, but this has PWM/ADC output for your personal projects.
If your are running your Driver Station on a relatively new laptop, and not the Classmate, you have more than enough processing power available to do your image processing there. The image processing routines included with LabVIEW are impressively efficient and powerful. I actually use them in my professional life, and have found them to be among the fastest such routines available. You can then send whatever computed values you need back to the robot via a UDP connection.
Our team used a beaglebone during competition season and tested out a raspberry pi at two off season events. Both of them work well enough, having a low frame-rate but fast enough to get back accurate data. The main problem with these boards if you don’t get a high end board is the lack of fast enough USB drivers to allow for large or fast frame-rates from usb webcams. Even though using the network camera can get around this, pyopencv uses ffmpeg for network streaming of video which has a very slow connection and is a major bottleneck, iirc C and C++ implementation can get around this by using their own image acquisition functions. Take your video source into account when picking the board. Of course your best option is offloading processing to a fast Driver Station.
Has anyone used an off-board processor (beagle/bone/pi/arduino and others) with a directly connected camera (not using USB or Ethernet)?
For example, I think the beagle xm has a camera connector and modules one can buy. The pi has a 5MP camera module in design but looks like it will not go into production in time for FRC2013 use. Since it is December we need to buy something with a canned hardware/solution that requires only the poring of OpenCV (or equivalent) etc.