OpenCV vs RoboRealm vs SimpleCV…What’s the main difference? Also, what do you teams (with vision) use? I would like to know which is better prformance-wise, feature-wise and simplicity-wise. I currently have OpenCV and RoboRealm.
An option that isn’t listed is the NI Vision libraries. This is what the example/tutorial in LV uses. It runs on Windows and cRIO, and has LV and C entry points for its functions.
Greg McKaskle
We use NI Vision on a LabVIEW dashboard, communicating to a java program using Network Tables. We’ve been much more successful with this approach then anything else we’ve tried (and we’ve been playing with vision since 2005).
I think much of the success is attributable to the great examples that NI puts together for FIRST, rather then something inherent in the library. In addition, doing vision processing on the dashboard is much easier then trying to do it on the cRIO or on a robot-based co-processor.
Crap. I forgot about that. Is there a way I can edit the poll?
This is dawned on me:in order for a team to be competitive this year, they are required to do vision processing, and not just sending a feed to the driver station. Reason being that there is absolutely no way to tell unless you are analyzing the hot goal and/or the dynamic target. It will be interesting. A lot of teams get away with not using vision and just indexing on the field, but they can’t do that this year, and computer vision has a (very) steep learning curve.
Why wouldn’t teams be able to just look in the camera view for illuminated goals?
They absolutely can, except for that pesky first 10 seconds. 
NI vision library on the cRIO.
NI library for Java, on the cRIO for the last several years. Debating using OpenCV on a BeagleBone Black coprocessor arrangement this year.
I’ll throw in a plug for RoboRealm. In the past I’ve used NI Vision libraries on the robot and OpenCV on the driver station. Yesterday I decided to try making a program with RoboRealm running on the driver station sending data back to the robot with Network tables.
In about an hour I had a program that was detecting the hot target, and in another half hour had the data back to the robot using the built-in Network Tables implementation in RoboRealm. It’s not yet doing distance or anything complicated, but it does make my little desktop robot open and close the claw based on the target being hot. I’ll leave the hard parts for the students. I just wanted to see how well it worked.
I was able to test the program using the sample images that are included with the sample programs that come with all the languages. No field construction required, and didn’t leave my desk.
Brad
That’s what I was referring to. In the past, FIRST hasn’t made computer vision a requirement to be as competitive as possible, but this year they are.
So, I should ask why your team picked these different technologies. They all work well. I, myself, prefer OpenCV because it is so powerful. It is also well-documented, so learning it can be conquered within weeks!
Also, how do you communicate with the robot? Serial-RS232/UART, i2C, SPI, NetworkTables, Winsocks? By the way, would you guys suggest using winsocks? It seems quite easy enough to use and make a socket server using!
Last year we used SimpleCV (python) running on a ODROID-U2 with network tables from here:
So we could have it all Python and it worked fine.
The year before we did OpenCV in C++ using visual studio to compile an app on the driver station that interacted with the Java network tables on the driver side. We got great distances and it ran real fast except we ran c++ on the robot side and we could not get network tables that year working. We were going to convert the robot code to Java but ran out of time. The next year network tables worked great in c++ on the robot.
We played with the code that comes with the WPLIB this year and after adjusting the HSV setting we got decent distances with that. I am still thinking we might stick with off processing. Depends on how much we have to do in Autonomous and if we want it for other uses.
We ran everything on a PandaBoard last year, but we will be going with an ODROID board this year, most likely. We used OpenCV and wrote our own networking libraries. The networking stuff is pretty simple in C++, so it was easy enough to write our own and it gave us more flexibility.
The kids want to use Java this year, so that will require some adjustments in the networking code, but all of that stuff is fairly universal.
Our vision isn’t very heavy on any processor except the cRio’s, so we use the dashboard. 
I think you are asking an incomplete question. Most of these libraries contain similar functions which should suffice for FRC. filters, masks, histograms…etc.
What you should be more interested in, is what system a team is using, and the type of performance they are achieving.
i.e on dashboard, achieving 20fps with 500ms lag behind real-time, on crio - 4fps with 2 second lag behind real-time. Co-processor - 10fps real-time.
(Note, I just made these up, do not take the above to be factual, it is purly for illustraing a point.)
In the above scenario, which vision system would you choose? I know exactly which one I would choose. The performace other teams achieve with their Vision setup goes beyond what library they use.
Regards,
Kevin
We are hoping to use a new camera this year called PIXY from Charmedlabs. The specs claim it finds “blobs” and transmits only the x,y coordinates via RS232 - not the entire image. This allows it to process 50FPS with 20ms lag - which is as fast at the cRIO can consume the data anyway. If we get it in time, we hope to have a ball tracking goalie in AUTO.
We’re using OpenCV with an ODROID U3. Running two USB cameras, where one is for ball tracking and other other one for auton “hot” target detection.
Vision coprocessor communication is two-way between CRIO and ODROID via UDP ports.
I’m glad to see other people using O-Droid products.
Bidirectional udp: what are you sending to the U3? Just out of curiosity.
We use two-way TCP stream between our CRIO and beaglebone. For this year, the cRIO send a “MatchStart” flag.
We had to do this because, when your setting up, you will be looking at a hot target, and must wait for it to actuate away (indicating other side is hot) or stay up (indication this side is hot). If we didn’t send this data, the coprocessor could not differentiate between a hot target seen in disabled mode while setting up, or a hot target seen in autonomous mode (when it really counts).
The co-processor uses this data to then wait some steadystate time(time for the hot goal panel to actuate) and return a “ValidData” bit as well as a bunch of useful information about hot goal or not back to the RIO, which is used to make decisions on how the rest of auton is played out.
You could do this on the cRIO as well, and keep the stream one way, we just opted to do it this way. We choose this way because it makes the cRIO side interface really simple: Just wait for the “ValidData” bit, and “HotOrNot” bit, or timeout.
The commands on the cRIO, have timeouts so that if for some reason we loose the camera or the stream, our auton doesn’t hang and still continues, just assuming the closest goal is hot.
Hope this helps,
Kevin