SKPIC32 Image Recognition and Processing Possibility

[Hollowaykeanho]

Hi all,

Thanks you for dropping by. Just wondering, anyone tried using SKPIC32 to do image recognition/processing before?

I'm an active 18F programmer dealing with sensors and automation instrumentation.. thinking of moving up to 32 bits and is interested of dealing image recognition embedded solution.

Thanks ahead.

regards,
Holloway

[Brian Griffin]

Hi all,

Thanks you for dropping by. Just wondering, anyone tried using SKPIC32 to do image recognition/processing before?

I'm an active 18F programmer dealing with sensors and automation instrumentation.. thinking of moving up to 32 bits and is interested of dealing image recognition embedded solution.

Thanks ahead.

regards,
Holloway

You need a DSP for this, or a seperate SBC, with another onboard DSP.

Image recognition requires a lot more of processing power and mainly involves floating point operations too. Not just that - a lot of RAM is required too.

An easy way out is to get a SBC with Linux inside, create a Linux program with OpenCV, and interface with the SBC with other sensors or whatever it is according to the job.

[Hollowaykeanho]

Thanks for your reply.

You need a DSP for this, or a seperate SBC, with another onboard DSP.

Haha.. Well, I'm acutally seeking single-chip solution, size perhaps around uC (although the above is a viable solution too). My current solution: big PC as "brains" with uCs as "limbs" but well, it is too bulky and is very stationary.

Image recognition requires a lot more of processing power and mainly involves floating point operations too. Not just that - a lot of RAM is required too.

An easy way out is to get a SBC with Linux inside, create a Linux program with OpenCV, and interface with the SBC with other sensors or whatever it is according to the job.

Oh well, looks like I need to continue my hunting.

Anyhow, thanks for the sharing. Greatly appreciated for your wisdom.

[Brian Griffin]

Thanks for your reply.
Haha.. Well, I'm acutally seeking single-chip solution, size perhaps around uC (although the above is a viable solution too). My current solution: big PC as "brains" with uCs as "limbs" but well, it is too bulky and is very stationary.

You can either use:

1.) FPGA - Hardware descriptive language on image recognition technique implemented inside the system. All in one. Use the PIC32 as a central system - it gets the results from the customized solution and displays it on elsewhere. (Match or no Match? on screen, as an example)

2.) Powerful ARM processor with DSP capabilities. Put the routines in C into the processor inside like usual.

3.) Micro-SBC like "Raspberry Pi". Put your program and OpenCV inside that thing. Story end. (And it's $25, if I'm not mistaken)

An image recognition method by Viola-Jones (in OpenCV it's called Haar Classifier) will be easier on those smaller high-end processors. However, you may need to write these routines, including the Adaboost (another machine learning algorithm), all into the FPGA or the into the processor. Plus, you may need to train the system to properly recognize the object too.

Neural-networks is also okay, but the difficult part is to train the system. You need many samples of the thing for the system to successfully detect the object.

No uCs can do all of this - you need a more powerful solution.

There are other straight forward methods if you just want to simply see whether both images match each other or not on these system. You may check "correlation" algorithm in the Google, and implement this into the system as well.

Meanwhile, shape-detection algorithm is more difficult to use. I admit I only implement the circle-detection algorithm (Hough Transform) into my FYP two years back.

* I would recommend (3) but that Rasperry-Pi isn't in the stores yet. Plus, it's tiny, it's about 80mmx50mm.

[sich]

What about using the Beagle Board?

[Hollowaykeanho]

What about using the Beagle Board?

3.) Micro-SBC like "Raspberry Pi". Put your program and OpenCV inside that thing. Story end. (And it's $25, if I'm not mistaken)
...it's about 80mmx50mm...

Man, these options are great. Computer-based, Linux, small sized, and am sure Python supported. This guy with uCs as 'limbs' extensions, intelligence everywhere. Gosh, I'm in for it man. Next generation controller, save a LOT of efforts in computer software development. Okay, truth be told, I quite enjoy designing robots, control programming etc etc but don't quite like custom computer software development. Guess these board can kills 2 birds with 1 stone. Bye bye PICs.

I would recommend (3) but that Rasperry-Pi isn't in the stores yet.

FYI, Estimating Feb 2012, saw from FAQ of the web.

An image recognition method by Viola-Jones (in OpenCV it's called Haar Classifier) will be easier on those smaller high-end processors. However, you may need to write these routines, including the Adaboost (another machine learning algorithm), all into the FPGA or the into the processor. Plus, you may need to train the system to properly recognize the object too.

Neural-networks is also okay, but the difficult part is to train the system. You need many samples of the thing for the system to successfully detect the object.

There are other straight forward methods if you just want to simply see whether both images match each other or not on these system. You may check "correlation" algorithm in the Google, and implement this into the system as well.

wow, I need to salute you for your expertise. Well, I'm just a rookie for image processing. My last attempts is very pc-based using Roborealm, recognizing color patterning. I'm moving up to OpenCV due to as usual, cost. However, I'm not going to give up due to learning curve, never will.

1.) FPGA - Hardware descriptive language on image recognition technique implemented inside the system. All in one. Use the PIC32 as a central system - it gets the results from the customized solution and displays it on elsewhere. (Match or no Match? on screen, as an example)

I'm curious, is FPGA learning curve steeper than, says, coding assembly for PICs? (I'm okay with assembly coding, in fact, quite enjoy the style of thinking). I'm completely blank for FPGA and definately needs 101.


Well, learn a lot today. Thanks guys. =)

[Brian Griffin]

Man, these options are great. Computer-based, Linux, small sized, and am sure Python supported. This guy with uCs as 'limbs' extensions, intelligence everywhere. Gosh, I'm in for it man. Next generation controller, save a LOT of efforts in computer software development. Okay, truth be told, I quite enjoy designing robots, control programming etc etc but don't quite like custom computer software development. Guess these board can kills 2 birds with 1 stone. Bye bye PICs.

Scale your applications accordingly. Something big like image recognition - you have to use something big. And PICs aren't any dead yet - they find their way on general purpose applications. You may combine the PICs with other chips to obtain a complete system. You don't use a Pentium II processor on a fancy light dimmer, isn't it?

wow, I need to salute you for your expertise. Well, I'm just a rookie for image processing. My last attempts is very pc-based using Roborealm, recognizing color patterning. I'm moving up to OpenCV due to as usual, cost. However, I'm not going to give up due to learning curve, never will.

I'm not an expert - I only did computer based image recognition during my FYP in final undergrad year. So, had to read up on all these. It was years ago, so I didn't really remember much now.

I'm curious, is FPGA learning curve steeper than, says, coding assembly for PICs? (I'm okay with assembly coding, in fact, quite enjoy the style of thinking). I'm completely blank for FPGA and definately needs 101.


Well, learn a lot today. Thanks guys. =)

It's not assembly in FPGA. You need a seperate language on that - Verilog or VHDL. Though C made its way on the FPGA systems too, it's not much to be seen, and the Papillo board apparently supports that.

I had tried to model a PWM module by using an FPGA. It's quick, fast and precise, but I have to do simulation and proper "circuit placement" inside the chip for it to reduce timing errors.

And I had to work on FPGA in my work now. Never that easy, because I'm still learning and had to write a program within a very short time frame.

P.S: The "BeagleBoard" is good - but in Malaysia, it's nowhere to be found and it can be very, very expensive.

[Hollowaykeanho]

It's not assembly in FPGA. You need a seperate language on that - Verilog or VHDL. Though C made its way on the FPGA systems too, it's not much to be seen, and the Papillo board apparently supports that.

I had tried to model a PWM module by using an FPGA. It's quick, fast and precise, but I have to do simulation and proper "circuit placement" inside the chip for it to reduce timing errors.

Oops.. I'm aware of the VHDL. Actually, I wanted to visualize that will learning VHDL from scratch easier/harder than say, we benchmark with the learning and coding assembly language for PICs? FPGA seems to be applied in many sectors, might want to look into it near future as well.

... because I'm still learning and had to write a program within a very short time frame.

Cheers. I can share your experience for this one.

[Brian Griffin]

It's not assembly in FPGA. You need a seperate language on that - Verilog or VHDL. Though C made its way on the FPGA systems too, it's not much to be seen, and the Papillo board apparently supports that.

I had tried to model a PWM module by using an FPGA. It's quick, fast and precise, but I have to do simulation and proper "circuit placement" inside the chip for it to reduce timing errors.

Oops.. I'm aware of the VHDL. Actually, I wanted to visualize that will learning VHDL from scratch easier/harder than say, we benchmark with the learning and coding assembly language for PICs? FPGA seems to be applied in many sectors, might want to look into it near future as well.

... because I'm still learning and had to write a program within a very short time frame.

Cheers. I can share your experience for this one.

There are no benchmarks because microcontrollers and FPGA are different entities.

If you need to come up with something parallel in nature, you need to use FPGA. Some designers implemented a processor inside the FPGA and on its side are other devices assisting the processor. It could be floating point unit, could be a USB controller, could be VGA driver, and could be anything you want if you need to free up the processor's time. Another example: There is an Arduino shield which drive VGA signals for the Arduino - it runs on an Xilinx FPGA. Best part is, Arduino never gets all occupied because the display is entirelly driven by the FPGA.

If you still need to run image processing in embedded system, only (cheapest) way is to get the Raspberry Pi. It has some GPIOs, a USB socket for your webcam, and SD-card for your own program. The BeagleBoard can be a nice alternative but it is very, very expensive in here.

I heard that the Raspberry Pi might be out on after 20th of February. Probably you can have it for a testdrive first.

[Hollowaykeanho]

Okay, got it. Thanks for your advice. =)