Author
Topic: Infrared identification (Read 1467 times)

I put leds on top of my robots and then I identify each robot by camera according to the colors. But it proved to be difficult to use when the light in room changes.Is there a way to do this in infrared version? And would it help?

I mean is there a way to distinguish at least four different infrared leds by (infrared) camera?

But if somebody know a way how to do it with infra leds (or other type of led) I would be very grateful.

Btw. on top of every robot there are three leds in a row. In same distance on each robot. So detection is not done by positioning leds.

I don't know what your software is capable of, of course, but assuming it can just distinguish between two different magnitudes/levels of IR, you could use a dim LED as "0" and a bright LED as "1", giving you up to 8 combinations with 3 LEDs (if you can detect what's front and back, only 6 unique combinations if you can't).

If that's not enough and if your software's up for it, you could use ternary ("trinary") numbers (like the Russian computers did during the "Cold War" to speed things up considerably), giving 3 levels on each LED (dim, medium and bright, representing "-1", "0" and "1"), giving you 27 combinations if direction can be established (and 18 unique combinations if not).

How many different vehicles do you need to distinguish?

Logged

Regards,Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?Please remember...Engineering is based on numbers - not adjectives

Thx Soeren, that is actually what I wanted to know. So it is possible Thanks very much.

But thanks to Gertlex I realized one more way to do it in IR (or UV). I just need to use IR/Uv paint to create the QR code and it should work. Then I have more than enough combination and detecting QR via image recognition is more reliable than using led (I think).

I just need to use IR/Uv paint to create the QR code and it should work. Then I have more than enough combination and detecting QR via image recognition is more reliable than using led (I think).

No need for any special paint, white and black (to IR) will do.Personally, I think it will be way more work, as you need to get each "dot" of the code filling more than one pixel (at all possible angles).Contrast and resolution are the key parameters in reading QR codes and bar codes.Oh, and you need to know how to code and decode a QR code image of course.

Logged

Regards,Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?Please remember...Engineering is based on numbers - not adjectives

Why can't you just use a picaxe controlling an IR LED on the robot and another one using IR receivers to read a variable sent from the LED. You can use IROUT and IRIN commands with a picaxe that send and receive variables by IR automatically.

Soeren,good thing is that my robot's size is around 10cmx10cm ant top is flat co QR can cover most of it. There are supposed to be 5 - 10 object on the field so I don't need so many combinations. Then QR can be low res. In this situation it should be simple task to capture and decode it with camera.

Soeren,good thing is that my robot's size is around 10cmx10cm ant top is flat co QR can cover most of it. There are supposed to be 5 - 10 object on the field so I don't need so many combinations. Then QR can be low res. In this situation it should be simple task to capture and decode it with camera.

In that case, you might wanna consider using bar codes, code 2/5i ("two of five interleave", sometimes called ITF) in particular, as that will make your life a lot easier.

I have attached an example of QR code (encoded with the number "5") and 2/5i (encoded with "05" - two digits) respectively, as with any interleaved code, it only works with an even number of chars - one is encoded in the bars and the next is encoded in the spaces, This makes the comparison a bit unequal, as the 2/5i, as shown, can hold up to 100 numbers (00 to 99) with the complexity shown, compared to only 10 for the QR (0 to 9).QR codes was developed for holding more information than bar codes, but they carry quite an overhead compared to bar codes.

Thanks I really appreciate your advices and willingness to help me. Thnx.But I'm afraid that there might by problem when capturing with camera. Since the camera is placed in some distance from robots (around 2 meters) and might not be directly above robots.

Dut what I was thinking about was actually using my own version of QR. Let say with resolution 3x3. If we remove two fields to identify front and back side we still have 7 fields that holds 2**7 = 128 combinations. And since we are programmers it should not be a problem to implement this pseudo QR code decoding algorithm.

Dut what I was thinking about was actually using my own version of QR. Let say with resolution 3x3. If we remove two fields to identify front and back side we still have 7 fields that holds 2**7 = 128 combinations. And since we are programmers it should not be a problem to implement this pseudo QR code decoding algorithm.

What do you think?

Well, for starters, I think you shouldn't use the name QR even if you precede it with "pseudo", as QR code has got a very strict protocol (or should I say several, one for each version).

It's not hard to make up something usable (plenty of other 2D codes exists), but why reinvent the wheel when a 2/5i will do what you need? All you have to do to read it, is to discern between 2 widths (wide bar made 3 times as wide as the narrow bar).

It's not as simple as "removing" 2 fields, ever noticed how much area is used to tell the direction of a QR?You have two values, white and black, so a 3x3 with the first two fields blanked/white/"0" looking like:000110100

Bar codes have a similar code, for 2/5i the start code reads (reading from left to right): narrow bar, narrow space, narrow bar, narrow space.The stop code (read the same way) is: wide bar, narrow space, narrow bar.Hence, if the code read starts with: narrow, narrow, wide, it's backwards and the entire string is mirrored to read it right.You need to implement the same sorat of structure to any code made for automated information gathering and it's not an easy task (as you seem to think), for someone who hasn't done it before and this is why I'll keep suggesting you to go with a code that is already well proven

QR codes are reliable only due to good reading equipment. Bar codes were originally developed for reading with a pen that swept the bars as a trajectory (some people never learned to read a bar code with a pen, it requires a smooth and steady sweep) and therefore, the bar codes were designed to be very forgiving and they're much easier to read than a QR code and the full code extends throughout the entire height, so a torn corner doesn't render it unreadable like it would a QR code. Just to repeat myself, QR codes are for when you need lots of info stored, but they're weaker than bar codes in your application.

If I were in your position, doubting the old hand, I'd simply make one of each codes and test them with a camerasetup like the one you are going to use (and with the same distances and angles for say some hours spread out over a week or so (to get different light, temperatures etc. - That should tell you what to use when testing is done with

Logged

Regards,Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?Please remember...Engineering is based on numbers - not adjectives