Image detection using Arduino Due and a Video Experimenter for measuring a gap.

I'm planning a project to automate measuring of the gap of a spark plug. I'm trying to figure out what the best IC is for my project. My requirements are that the device has to be battery operated and have an image resolution of at least 0.005mm (will be rounded to nearest 0.01mm for the display, this is for accuracy purposes)

My goal for end user interaction is this: User inserts spark plug into a hole in the device, presses a button, a 3 digit LED displays the gap size.

To do this, I am considering taking a picture of the spark plug electrodes, and then doing some analysis on that image. The picture will be taken inside the device with controlled lighting conditions, so a black-white 1-bit image is all I think I really need. My biggest hurdle is getting the image into memory. Once I have a 2D array of the image, I can figure out the gap from there. I'm not sure Arduino is the best choice for this project due to the resolution that I need. Ideally (to minimize the work needed on the mechanical design) I would use an image size of 3mm wide x 4mm tall with a resolution of 600x800. If I can get that image into one bit per pixel, that's still a minimum of 480kb of memory required. I think I can knock that down some with good lensing and design of the camera chamber. If i use a non-standard resolution, I can maybe get 240x600 for 144kb, but I don't think I can go lower than that.

Can the Flash memory be used to store variable data? I don't think so, but I thought I would ask.

I have not considered speed in this, but anything faster than 90s is acceptable.

I was thinking of using the Arduino DUE for the processing and the video experimenter (link below) for the image processing. The video experimenter supports NTSC which is 600x480, so I think that should work. I'm still not sure about the memory though... http://nootropicdesign.com/ve/?utm_source=projectlab&utm_medium=ad&utm_content=sidebar-top-1&utm_campaign=projectlab

I'm looking for suggestions as to what platform to use, or any other suggestions you have, really. Thanks for your time!

-Russ

No you can't easily use program memory to store variable data. Video data would come in too quickly to store anyway.

The video experimenter supports NTSC which is 600x480

No, it supports RS-170 which has a maximum resolution of 600x480 roughly, but it cannot capture anything like that resolution, and even then only a single bit per pixel. It is limited by the time it takes to store each bit.

Are the spark plugs to be tested new or used? If used, you will need to distinguish between the metal and any carbon build up.

As for extra ram, you could use something like this: http://ruggedcircuits.com/html/megaram.html

You would still need to take into consideration the time taken to store the data.

The Due while having a lot more memory than a UNO is still rather too small for your proposed image. I would consider this is more in the Yun camp.

Before you go for an embedded soloution I would try it all with Processing so you can see the captured image and have the opportunity of using more than one bit per pixel. I think you will find it harder than you think. Then when you have a working system you will know exactly what you need to implement

@AWOL: The Video Experimenter website says: "Works with NTSC (North America, parts of South America and Asia) or PAL..." I'm not really well versed on video communication protocols, so what's the difference? http://nootropicdesign.com/ve/?utm_source=projectlab&utm_medium=ad&utm_content=sidebar-top-1&utm_campaign=projectlab

Anyway, based on my reading, and your comment, it seems analyzing a still image is harder than analyzing video. This seems counter intuitive, what are your thoughts on why this is?

@UnoDueTreTHANKS, that's a good suggestion regarding the carbon buildup. Generally carbon builds up on the insulator, not so much on the tip of the metal electrodes themselves due the spark itself having a cleaning effect. But that is a valid point, physical measurement with pin guages would remove any carbon buildup there is (How spark plugs are currently measured). Generally, there is little to no carbon on the plugs I measure, so it shouldn't be a factor, but, again, thanks for the suggestion.

About how long do you think it would take to store 480kb of memory? I'm not 100% sure how to translate processor speed into a rough idea of processing time.

@Grumpy_Mike I had considered a Raspberry Pi, but the power requirements seemed too high for batteries. Thanks for the suggestion on the Yun. Why is the Yun not on the Arduino products page?

I know it's not going to be easy, but I already do a lot of custom data analysis at work using programs like Matlab and NI Diadem. Honestly, that will be the fun part of the challenge! The biggest hurdle for me, and where I lack the most knowledge, is getting an image from the physical world into memory for the processing.

Thanks everyone for the comments! :)

I had considered a Raspberry Pi, but the power requirements seemed too high for batteries.

My point is get any solution working before you move to make a fixed installation. I have worked with image processing and it is never as straightforward as it seems in your head.

Why is the Yun not on the Arduino products page?

It is? Second row, second from the left. http://arduino.cc/en/Main/Products

The Video Experimenter website says: "Works with NTSC (North America, parts of South America and Asia) or PAL..." I'm not really well versed on video communication protocols, so what's the difference? http://nootropicdesign.com/ve/?utm_source=projectlab&utm_medium=ad&utm_content=sidebar-top-1&utm_campaign=projectlab

Anyway, based on my reading, and your comment, it seems analyzing a still image is harder than analyzing video. This seems counter intuitive, what are your thoughts on why this is?

NTSC is a colour standard, and RS-170 its monochrome analogue. The Video Experimenter does not decode colour information, so I'd say it doesn't support NTSC.

Video is a sequence of still images, so I can't see how analysing multiple still images is any easier than analysing a single still image. That's been my experience anyway.

There are other ways to do this, optically or otherwise, which might be considered.

A metal leaf on a small leadscrew could be moved back and forth while detecting electrical contact between the leaf and either contact.

Similar idea with an IR slot-type opto sensor being moved (one with a large gap and fine beam - perhaps custom made).

The photo idea has issues with parallax to consider, it might be better to think of casting a shadow direct only a CCD sensor chip from a relatively distant point source (laser diode?) - this would be a high contrast image (silhouette) with low parallax and be easier to process than a lit scene.

it seems analyzing a still image is harder than analyzing video. This seems counter intuitive, what are your thoughts on why this is?

The reason why it seems counter intuitive is that it is rubbish.

bacon117:
About how long do you think it would take to store 480kb of memory? I’m not 100% sure how to translate processor speed into a rough idea of processing time.

The actual saving to RAM will be pretty quick, what will take much longer is any processing/manipulation you do on the stored data which will depend on factors such as how much data you will actually manipulate and the efficiency of any algorithms you use.
Certainly won’t be able to put a number on the time it will take.

Have you decided 100% that you want to use the video/image detection method or have you considered other methods such as the ones MarkT proposed or possibly even using some kind of high voltage testing.
The idea here being that you could generate an increasing high voltage and test for when the spark plug conducts due to the spark jumping the gap.
The smaller the gap, the lower high voltage will be required.
There will of course be other factors to consider such as temperature and possibly even relative humidity.
Not too sure about the feasibility or accuracy of this method, just a thought.

Perhaps you could even combine the variable high voltage test with optical feedback to sense when the spark occurred.
You set the PWM duty cycle to the high voltage generator, wait a certain amount to see if the photo-diode picked up the spark, if not, increase the PWM duty cycle a bit more (and hence the generated high voltage) and repeat the process until a spark is detected (or at least the light produced by it).

There is plenty of info on the net about voltage versus spark gap.
These two may be of help:

http://www.kronjaeger.com/hv/hv/msr/spk/

SparkPlugHVtest.jpg

@MarkT: It has to be non-contacting. That would be one of the other benefits. Physically measuring the spark plug increases the chance of breaking the precious metal tips.

Once I figure out how to get the image, experimenting with lensing and parallax correcting schemes can be done. I've considered using the shadow setup, but my main research right now is how best to approach it from the electronics side. (I'm an ME, so i'm an electronics dummy, for sure)

Measuring the sparking voltage to determine gap is an interesting idea, but I seriously doubt it's accuracy. I am an ignition systems engineer, so I've seen my fair share of secondary voltage traces on an oscilloscope. The stochastic nature of the ignition system, even in a controlled environment, would make gap size prediction very difficult. Although, this might be a good way to estimate gap, it's a bit beyond the scope of the current project. Interestingly, if this method were feasible, checking that spark occurred is as simple as taking the differential of the measured data, but to do this, you would need at LEAST 2MS/s sampling rate and a 1000:1 passive probe.

@Grumpy_MikeSorry, I meant the spec comparison page... But the yun isn't same type of board, so I guess there is no need for it to be there.

Also, I understand what you are saying regarding getting any solution to work. But, one of the main goals out of this is teaching myself to use embedded systems like the arduino or raspberry pi, etc. I learn and work best when I have a goal in mind, with the loftier the goal, the harder I work at it. So even if I fail to get the end product I'm seeking, I will have learned how to use the arduino or similar IC. And really my main focus right now is which board to get just to experiment with, not necessarily as a final solution. (I have an FPGA, which I thought about trying to make that work...)

Therefore, my first step is figuring out how to get any picture into memory. Based on my research and mostly your suggestion, I'm going to pick up a Yun, and start experimenting with it.

Ok this might be useful Guide to Setup Streaming Web Cam on the Yun http://forum.arduino.cc/index.php?topic=188690.0;topicseen

bacon117: Physically measuring the spark plug increases the chance of breaking the precious metal tips.

The rest of the world gaps plugs using feeler gauges and a few judicious bashes to adjust the electrode where necessary, and the insulator is the part that is considered fragile. What are these 'precious metal tips' you're using?

I’m still trying to figure out where the number “480K” is coming from…

Actually - that’s just 800 multiplied by 600 - but for 1 bit resolution, you need to divide by 8 - so 60K (and 240 x 600 1 bit is 18K). If the OP is this bad at math, I would seriously question their ability to handle the development of the image processing software needed by their proposed system…

That said (with snark, I might add) - does anyone even know if the VE will work with a Due or a Yun? I know that on the Nootropic Design site it states it won’t work with a Mega, because of a certain pin not being brought out from the microcontroller (though it might be possible to hack that back in). There would also be voltage issues - perhaps - to deal with. But greater than all of those, would be the need to hack the custom TVOut library that the VE uses so that it would work properly with those other faster Arduino systems (because of the timing needs for processing the video signal).

800 pixels by 600 pixels is 480,000 total pixels. If each pixel is represented by 1 bit (1 for white, 0 for black), that's 480,000 bits... Why do you divide by 8? If you wanted 8 bit color, that would be 480,000 * 8 = 3,840,000 bits or 480KBytes....

Why do you divide by 8?

To tell you how many bytes you need?

I see the confusion. I was careful in my post to use little b to indicate bits, but when looking at the memory specs of the board, I thought those values were bits as well. They are actually reported in Bytes, not bits.

So, I need 480kilo-bits for monochrome 600x800, which is 60Bytes.

bacon117: So, I need 480kilo-bits for monochrome 600x800, which is 60Bytes.

Make that 60K Bytes, and you're right.

bacon117: which is 60Bytes.

(Kilobytes)