I’ve written a small program to help with vision processing for FRC. Right now it only does the thresholding, but you can use it quickly see the results of thresholding ops in real time. The idea is that if you need to recalibrate your vision processing at competition, then all you have to do is plug your laptop in and you can get new values and see the result of the thresholding ops as you change the ranges. I’ve tried to make the thresholding as similar as I can to the cRIO’s.
URL:
Program:
axisviewer
Dependencies:
libcurl (not sure about the version)
gtkmm 3 (sorry, i’m working on getting a gtkmm >= 2.4 version)
cmake (to build)
Because it requires gtkmm 3 there’s no currently stable way to build this on windows. However, gtkmm 3.4 is about to be released, and I just got info from the mailing list that this version should work well on windows. As far as the libcurl dependency, that’s just there so that I don’t have to deal with the http socket stuff. I plan to remove this dependency in the future.
TODOs:
Make the image processing stuff less crufty
Add more vision operations
Get a working gtkmm2 build
and other misc. stuff.
I’ll put a screenshot up tomorrow.
If you want to use this with your own, just go to Config->Set Camera IP and use that. It should also theoretically work with other IP MJPEG cameras too, you just need to get the correct delimiter. Maybe I can add something to guess the delimiter in the future…
I just pushed a revision that adds gtk2 compatibility. I’ll see if I can get MinGW to cooperate (I hate developing on windows… or any OS without a package manager!)
CMake should now automatically try and find GTK and configure the project to use gtkmm-2.4 or gtkmm-3.0 depending on you installed libraries.
If anybody is using arch linux, here’s a PKGBUILD. I don’t have a camera with me, but it successfully builds and installs the program.
(remove the .txt extension; some people still think the extension matters)
That’s a pretty sweet, simple, lightweight program. Yet, when I want to verify thresholds for our camera at competitions, I just use NI’s Vision Assistant with a snapshot photo from the Axis (using the color threshold VI) which works just as simply, although the whole program is a bit clunky.
Are you hoping that this is a program for those who want to use Linux? I suppose I fail to understand the differences between this program and what FIRST and NI have given us.
There’s probably a bunch of bugs, so if someone would like to test it, that would be awesome
I’ll work on cleaning up the build system on windows later as right now I have to hard-code things to get everything to build properly.
@kenavt: There were a few motivations for me making this program.
I don’t like having to go into the web interface for the camera, grab a snapshot, open it up, process it, repeat the process to see if it works, etc. So of course the logical thing to save 30 seconds of time (for a programmer) is to spend hours on a program that grabs the stream from the camera and processes it in real time
Since the source code is available (and will be made more pretty soon) for the image processing, I’m hoping that anyone who wants to look at the calculations for HSL and the thresholding (and maybe more algorithms in the future) can just open the file and learn from that. You can’t do that with NIVision.out (unless you use objdump! - no random NI person who’s reading this, I did not disassemble your proprietary code)
I like having applications that are crossplatform and lightweight. I personally use linux for all of my development, robotics included, and I prefer to have native builds of my toolchain and development tools.
So, in essence, convenience, open source, and portability provided the reason for writing the program.
But seriously, I am happy to see you creating your own implementation of the algorithms and making your own tools. Feel free to compare them to the NI results, and if you want to disassemble the NI stuff to see how it does its thing, I’ll back you all the way.
I did my own HSL implementation last year and based it on the Foley and VanDam implementation. I know, I know, reinventing the wheel, but as long as you don’t fool yourself, building wheels is not a bad hobby. I implemented my HSL algorithm in LV just to see what the performance and implementation would look like. Again, let me know if I can help.
I know you read the forum a lot, but I don’t know if you’re the only one.
But seriously, I am happy to see you creating your own implementation of the algorithms and making your own tools. Feel free to compare them to the NI results, and if you want to disassemble the NI stuff to see how it does its thing, I’ll back you all the way.
Sounds awesome!
I did my own HSL implementation last year and based it on the Foley and VanDam implementation. I know, I know, reinventing the wheel, but as long as you don’t fool yourself, building wheels is not a bad hobby. I implemented my HSL algorithm in LV just to see what the performance and implementation would look like. Again, let me know if I can help.
I’m the king of wheel building; i even have my own kernel (it doesn’t work though )!
Ok, so an update:
The latest code sould work with both gtkmm 2 and 3. I was able to get a working build with version 2.22 on mingw32. I haven’t tested it much since the revision i originally posted, though.
Im hoping to develop a bunch of tools - though you arent supposed to reuse robot code year to year, tools dont fall under that requirement. Im still a team member (till June at least) so i dont see any conflict with the spirit of the competition.
Shameless plug: working on build scripts for gcc 4 with rvalue references, lambdas, enhanced libraries, and more fun stuff (see WindRiver C++ forum- busy testing that out).
)!