My project is doing image recognition using hough transforms. I ported some of the existing code over to c# and ran it on an image 128x96 in size.
It took a whooping 20,000ms (in release no debugger attatched).
Anyways, I need to port this code over to RLP. I’m seeing up to 100 time increase in several operations, it looks like I will be able to do about 3-4fps using RLP (on 72mhz panda II).
I want to thank GHI electronics for providing such an easy way to write native code for the platform. I’m familiar with C and whatnot; but I was really surprised how easy it was to interop with native code. This is actually a LOT easier than when writing native C libraries on win32 and trying to interop with them in C#.
I’m not sure how you guys pulled this off, but cudos.
I will submit this library back to the community when completed.
Very cool. Welcome to the community! Can you tell us more about what you’ll be using computer vision for with your Panda? I hope you can share your project when it’s complete.
The code performs exactly as the managed library; I did however trim it down quite a bit and limited the number of circles it finds and what not.
I also added code to not parse basically black images or mostly white images.
All tests 128x96 monochrome image with little noise.
First port to fez panda II:
Managed code (known circle radius) ~21000ms.
RLP (known circle radius) 192ms.
On my laptop the managed code I ported runs in about 4ms.
Performance depends on a few factors; noise and size of circles we are looking for.
The goal of this is to track a somewhat known radius of a bright circle with a camera for a robot (using the video exp. shield) at 3fps.
I’ll post the code in a few hours; it can be optimized in quite a few places.
I had zero issues compiling and calling RLP code. Very pleasant experience
I have unit tests written for the managed library and I compared the results to the RLP code and it’s identically at the moment.
openCV is the first library I looked at, it’s used alot and has been ported to many platforms and seems very robust. The problem was that I just needed circle transformations; and the opencv library seemed to be a bigger effort just to port that functionality. Guess I’m getting lazy on my older days
I wonder what kind of speed difference the code would run at on a cortex m 4 @ 168mhz vs the fez panda II @ 72mhz.
[quote=“twospoons”]
openCV is the first library I looked at, it’s used alot and has been ported to many platforms and seems very robust. The problem was that I just needed circle transformations; and the opencv library seemed to be a bigger effort just to port that functionality. Guess I’m getting lazy on my older days :)[/quote]
I totally understand. I’m looking at integrating some CV into one of my projects in the near future so I’m hoping to be lazy and borrow from your experiences
Do you have a Cerberus to test with? If not, send me your test code and we’ll find out. Are you doing your tests using a cam or with just a static image? I don’t have a camera that works with the Cerberus.
It’s just a static image. I just wrote a program which takes a regular image and converts it into monochrome bytes. One image is 1536 bytes; where one byte is 8 pixels (width).
The image will be feed from an arduino board; but that process takes about 250ms over UART. So I’m looking to just buy the cererbus with the camera and use that.
The only issue is the camera module is manual focus which is a deal breaker for this project.
Just an FYI the hough map is created in c# and passed as a pointer into RLP. The reason for that is that I cannot allocate a large enough structure in RLP to hold the map.
(It should be unsigned char map[96*128] in RLP).
More FYI:
Pretty memory intensive; not much to do about that.
Only supports monochrome images of size 128x96 (memory constraints).
Monochrome images works really well with hough transforms so this is a plus (normally you would run a filter to get an image like this)
This code is NOT thread safe. The circle struct is shared.
Your math is a bit off. The camera module is color, not black and white, so you need at least 8 X 3 = 24 bits per pixel. Actually it is 4 bytes per pixel.
