11
\$\begingroup\$

For a project of mine I need to use infrared LED markers to identify locations of points in space with stereovision algorithms and multiple IR cameras. I also need each LED marker to have a unique recognizable ID, which is my current problem.

My thought was to have each LED flash between two states of brightness (is this possible?) in a recognizable sequence but still be bright enough to track in the lower brightness state.

I don't know how to implement this or really where to start looking. I am a programmer but have never worked with actual circuits before. Can you help me get started?

\$\endgroup\$

7 Answers 7

11
\$\begingroup\$

if all your LEDs are being controlled from the same source, consider using a microcontroller + differential Manchester encoding + your high/low LED states to encode bitstrings of repeating sequences like:

id #0: 1000000000000000[10000000000000001000000000000000....]
id #1: 1000000000000001[10000000000000011000000000000001....]
id #2: 1000000000000010
id #3: 1000000000000011
id #4: 1000000000000100

to encode ID numbers as a 16-bit bitsequence consisting of a 1, then 7 zeros, and an 8-bit ID#. Then when decoding, look for a 1 followed by 7 zeros, then take the subsequent subsequent bits. This works for all 8-bit ID#s (even #128 = 10000000 which encodes as 1000000010000000 which can't necessarily be synced properly but for that number it doesn't matter).

(If you have fewer potential LEDs, use fewer bits; this scheme is pretty simple and generalizes to a 1 + (N-1) zeros + an N-bit number)

Manchester encoding is self-clocking so you should be able to synchronize a receiver to it (even if it's another microcontroller not sure of the frequency, sample several times per bit so you can stay locked).

\$\endgroup\$
4
\$\begingroup\$

If you could flash each LED on and off at a different frequency this would probably simplify things a lot as you could use 555 based circuits to flash each one at the required frequency.

\$\endgroup\$
3
  • 2
    \$\begingroup\$ simplifies transmitter, but complicates the receiver \$\endgroup\$
    – Jason S
    Dec 28, 2009 at 13:26
  • \$\begingroup\$ If he's tracking loads of points, he's probably not going to be using an Arduino or any other microcontroller. \$\endgroup\$
    – Amos
    Dec 28, 2009 at 15:18
  • \$\begingroup\$ ..for the receiver that is, plus it's not the programming that's the problem it's the circuits so the simpler the circuit the better. \$\endgroup\$
    – Amos
    Dec 28, 2009 at 23:58
4
\$\begingroup\$

Everyone seems to be starting off with Arduinos these days, so something like this is probably what you are looking for. However it seems as if you are intending to use a lot of LEDs in this project which would be difficult with an arduino. This is all off the top of my head* here, but it may be possible to use a transistor and a large resistor in parallel so that when the transistor is off, the current flows through the large resistor and you get a dim light. When you turn it on though, current flows through the transistor due to the lower resistance and you get the brighter state. Assuming this works, you could use digital components like microcontrollers to control the transistors and achieve the flashing that you require. Attached is a schematic of what I mean (the values are arbitrary, you will probably have to change them for your circuit):

Schematic of transistor circuit

Whichever way you do it, its going to be quite hard considering you've not done much electronics. Good luck!

*it is late; this could be completely wrong and not work at all. ymmv.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Basically OK, but you need another resistor in series with LED and transistor to set the current for the bright state, otherwise your LED will die. \$\endgroup\$
    – starblue
    Dec 28, 2009 at 12:12
  • \$\begingroup\$ yes this is true. I figured it was implied but I should have mentioned it anyway. \$\endgroup\$
    – jeremy
    Dec 28, 2009 at 12:16
3
\$\begingroup\$

I would do a variation of penjuin's idea. I would use an on and off state to generate the two levels. Rather than trying to track the LED in the off state (or low state) make the off state short and just track in the on-state.

You also didn't mention how many LEDs you need to track and how fast they are moving.

\$\endgroup\$
1
\$\begingroup\$

Yes, two-state "dim" and "bright" is easy. Given any circuit that blinks a LED hard on and off with a transistor, you add one resistor across that transistor. Then when the transistor is fully off, the resistor allows a dim glow. I would start with a resistor of exactly the same value as the current limiting resistor already connected to the LED. (Every LED needs a current-limiting resistor).

For a few markers, a independent battery and 555 timer at each one is going to be the simplest marker hardware. (plus a few resistors and capacitors).

The overall system simpler if you can synchronize the LEDs: turn all markers on at the start of the cycle, then turn off one marker at a time until they are all off, then turn them all back on and start the cycle over. The amount of energy needed to keep a bunch of LEDs blinking for a couple of hours typically weighs much less in the form of one or two central batteries rather than one battery per LED. (This requires a comparator IC at each LED, or a few shift registers or an Arduino emulating those shift registers at some central location). (This requires lots of wires stringing from one marker to the next, or from each marker to some central point -- so that may not be possible for your application.)

It makes your vision recognition software much simpler if the PC can control the LEDs directly. Then when the PC is searching for LED_5, it can turn off and on LED_5 and be confident that the one LED that blinked must be LED_5. Perhaps using something like a USB to 8 bit parallel port converter, which (with 8 resistors, one per LED) can directly control 8 LEDs or (with 4 resistors, one per column) a 4x4 matrix of 16 LEDs. (This requires yet another wire, a USB cable from the PC to the converter, but it doesn't require any batteries or transistors or additional chips -- this may be the simplest for a programmer non-electronics guy to get working).

\$\endgroup\$
1
\$\begingroup\$

I think you may run in to trouble on the vision side of things if the frame rate of the camera isn't high enough relative to the rate of motion of the LED's.

the LED's are going to need to cycle from high to low at some reasonable multiple of the camera's frame rate, at least 2 frames per state change to make sure that some of the frames have light from only one state instead of mixed from two states, which means you need two frames for every bit of data flashed out by the LED's to identify which marker it is. obviously a shorter code will be best for that.

If the markers are moving a distance over that that is on the same order as their distance from each other in the frame, then the vision system may lose confidence in correctly identifying which flashes belong to which marker.

\$\endgroup\$
0
\$\begingroup\$

schematic

simulate this circuit – Schematic created using CircuitLab

Figure 1, 2 and 3 LED schemes.

  • Dual LEDs give very simple control. R2 sets the brightness of the always-on LED. R1 sets the brightness of the pulsed LED.
  • Single LED, dual brightness is another simple scheme. D3 always lights with current passed through R4. When BUF2 switches low it connects R3 to GND and the current through D3 increases causing the LED to glow brighter.
  • PWM brightness control is the simplest from the hardware point of view but the software needs to control the LED brightness.

enter image description here

Figure 2. PWM encoding.

Using pulse-width modulation (PWM) you can vary the apparent brightness by varying the on-off ratio. Figure 2 shows a high-power, low-power, high-power sequence.

For your application you would need to set the PWM frequency high enough that the camera sensor won't see any flicker. The data modulation or rate of switching between high and low brightness would have to be at most half of frame rate and more likely about one tenth of frame rate to be able to discern it properly.

You may also need to address beam angle from the LEDs. It sounds as though your cameras will not be on-axis all the time.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.