Arduino and images

Hi guys, first i want to say that Im a begginer in all this so I'm sorry if I'm asking dumb questions :-[ . My project is about taking a photo of a number ( 0 to 9 ) from a camera that is related to my arduino and send the number in the photo via sheild gsm to a database ... My idea is to convert each photo to a binary code and give it a number. But the problem is I don't know how the arduino will receive the photo. Is it a frequenciel signal or binary ... I'm stuck actually ... any kind of help will be good so pleaaaaaaase help me :'( I don't have much time :/ thank you

First i want to say that Im a begginer in all this

And first I want to say that this is not a beginners project. It is a very difficult thing to do.

There is little you can do with an Arduino and a camera due to the lack of memory and processing power.

One camera you can use is here:- http://www.adafruit.com/products/397 It will take 10 to 15 seconds to transfer an image to an SD card.

My idea is to convert each photo to a binary code and give it a number.

Any digital photograph is already in binary numbers.

a camera that is related to my arduino

What does that mean? First cousin twice removed?

The Arduino is not the right platform for this project.

You could do what you want with a Raspberry Pi. Then a bit of character recognition to turn the written ( not wroten * ) number into your data base.

  • I can say this because I am dyslexic myself.

Okay thank you for all this !
Do you think there is any other way for that I can read a number that is wroten ( as in the picture below ), Because these is actually the problem that I have that why I though about a camera .
I hope you can help me :confused:
Thank you again.

Okay! is it possible to send from it to a database, like using a sheild GSM ? it's the first time I'm hearing about Raspberry PI :/ I'm sorry for my English, I'm from morocco, they gave me this project to do and I'm just trying to find the way ..

it's the first time I'm hearing about Raspberry PI :/

It has been out three years and they have sold over five million. It is a Linux box and for your project it is much better bet for image processing. See here:- https://www.raspberrypi.org/

But you don't have to use images.

I can read a number that is wroten ( as in the picture below )

Do you have to read one of those dials or all of them?

If it is only one then you could paint a coloured dot, or stripe on each position and have a colour sensor. Or you could fit a magnet and hall sensor on the pre gearing before the number train and then count the revolutions. You don't have to read the whole number, just keep up with the changes.

A camera will afford you inordinate amounts more data than you need - with 10 symbols per dial you should need only 4 points to sense … log2(10)

See here

Specifically the ‘off topic’ discussion re. sensing 7segment displays - thing is, the logic stands as the font for those digits is pretty ‘digital’ - the trick is to find them.

A camera will likely be the easiest way regardless :wink: but it shouldn’t be that complex in terms of image processing - find the four points, sense dark or light, look up number from look up table (you figured out).

Or do as Mike suggests and come up with your own ‘lettering’ and sense accordingly.

What sort of periods are you looking at per iteration?

Thank you guys for all your ideas !! That is very helpful. I'm going to study all this ideas and ask you if I need anything ! I'm really thankful.

About the color sensor, can I for exemple put a different color in each number, 10 different colors ... ? Like green is 0 etc ... :-[ :-[

Use the resistor colour code 0 = black 1 = brown 2 = red 3 = orange 4 = yellow 5 = green 6 = blue 7 = violet 8 = grey 9 = white

can you advice me which color sensor is best for me to use ? I found the TCS230D color sensor but i think i can't use 5, for 5 dials, because of his dimensions .. Im really thankfull sir

Well, you could use a camera !

It can(/should be able to) sense all 5 dials at the same time - aaaand, with a little smarts you will be able to read the dials with no added colour coding. As the font is both known and constant the image 'processing' would be trivial.

but - again, what is the period you are looking at per iteration?

If 15s is ok - then you have all the info you need here in this thread ;)

The link to that adafruit one says you can change the image size and compression ...

Which is good and bad - i.e. reduce the dimension to make things faster (160*120 for instance)- buuuut, if you're saving jpeg data, then there will be non-trivial processing accessing the RGB values, but still, potentially doable - with time. And actually you're only after intensity values, no need for colour if you're clever about it - a mono-chrome camera would be better suited.

So how do you get a jpeg decoding on a UNO? I am sure itis not doable. Due to lack of memory to work in.

I don't know the numbers for say 160*120, sounds painful so yeah, if you say it's not feasible ... but then again if the 'image' were small enough and monochrome, sooner or later it's going to be a happening thing :)

what do you mean with periode of iteration ? iteration of what ? :-[ and can you advice of a good camera monochrome that i can use .

what do you mean with periode of iteration ?

How often you need to do the measurements of reading the numbers to see if it has changed.

We are asking you how fast those numbers move. You only need to read one of the numbers, because you can start the code with the most significant digits already defined and increment it as you see the first number wrap round. Store the number in EEPROM to keep it during power cycles.

Mike brings up a good point!

If they only ever increment, then just sense change. Then add +1 and so on from a defined start point.

Dial movement can be sensed many ways, but since we're discussing light and cameras etc. - how about a photodiode recognizing the relative darkness between the numbers?

Is the ambient lighting condition static?

Grumpy_Mike: We are asking you how fast those numbers move.

well, the numbers are moving really slow

1:1: Mike brings up a good point!

If they only ever increment, then just sense change. Then add +1 and so on from a defined start point.

Yes there is so many ways actually, i thought about a a lot of things but did not find a good idea how to read this :/ it's because, the point is to read the dials once per month, so Im looking for a way to do that just one time per month, whiche means i don't want to make another system that counts in paralelle with the dials, to avoid the problem in case the alimentation stops working, because when it will start working again, it well continue counting but the dials will be already ahead ... did I meake my point a litlle bit clear :/ ?

1:1: how about a photodiode recognizing the relative darkness between the numbers? Is the ambient lighting condition static?

it's going to be dark actually, because those dials are in a box, and if we need light we can just use 2 LEDS i think .. but can you explaine to me a little bit more your idea please ?

Chad21: well, the numbers are moving really slow

How slow is slow ?? one count per ?

Do they move fast but at a low period - i.e. no move then fast move - are they constantly moving? Or is it more random?

'read them once a month'

This means you need absolute measurement like you suggested at the get go - this is a lot harder than the relative measurement that I was suggesting in the last post.

'to avoid the problem in case the alimentation stops working'

I had to look up that word, still not sure exactly what you mean - could you elaborate ? Seems like something critical to the project might be lurking in this statement.

Anyways, I meant if you look at any of those dials (but I guess the 'least significant dial' is the dial of interest) and take a 'horizontal' slice across the face of it, it either:

  • has some white
  • doesn't have some white

So, set up a photodiode or LDR such that when it has any amount of white it is high - and low when it doesn't. (or flip the logic, whatever is easiest)

When it spins it is essentially an incremental encoder: high-low-high-low-high-low-high-low- ...

then something like:

if (LDRstate - LDRstate != 0) {     //looking for state *change* here - i.e. first derivative
    count++;
}

You'll need to reference it once (in code) and then away it goes... Obviously it'll need to be made robust for opening the box and so on - annoying, but doable.

Anyways - that's relative measurement - something you say you don't want ;)

So, back to the drawing board ... aaaand I'm thinking the approach might be a bit arse about face, question: what signal/circuit/mechanism/thingimabob is running that dial ? can't we hack into that?

Just realised the code above will count++ twice as much as it needs to - but that is solvable many ways ...