Electronic – Any ideas to make IR LEDs identifiable during position-tracking

identificationinfraredledModulationwii

Background

Johnny Lee demonstrated various interesting ideas (detailed, e.g., in this video as well as this page) that take advantage of the Infrared camera from a Wii-Remote. The IR camera has 1024X768 resolution, and is designed to position-track the 4 brightest infrared-lit points in its view, at 100 Hz. Each of these 4 "points" could be a moving marker in the form of, e.g., an infrared LED — the LED's emission is detected by the camera, which in turn outputs at 100 Hz, the position data of the IR "blob" observed. Which allows a fast and inexpensive DIY position-tracking system.

Problem

In the above setup, if each IR LED is not just powered on but also somehow made uniquely IDENTIFIABLE, it would give rise to many interesting possibilities. For example, this would allow continuously position-tracking each marker in space uniquely (i.e., with knowledge of which blob is which). In addition, having each IR LED marker being unique also means the setup could be extended to any number of points (say 50 markers) instead of just the 4 brightest points.

The question is: Assuming you start by connecting each IR LED marker to a microcontroller, what would be the most effective way to extend the above setup so that each IR LED marker is uniquely IDENTIFIED? I roughly describe one approach below — is there some more versatile or simpler approach than it, or perhaps can improvements be made to it?

First, a method that is NOT promising: Since each infrared MarkerLED is connected to a microcontroller, you could have each MarkerLED blink in a unique pattern. But the IR camera has only 100 Hz refresh rate so if there were 50 LEDs, it would be difficult to fit in a unique pattern for each, without the camera's effective position tracking of the points becoming really slow.

Below is a rough idea I'm currently considering (tracks & identifies 50 IR LED markers):

  • Start by tagging on a simple IR-Detector next to the IR-Camera, both of whose ouputs are read/tracked in sync by a common microcontroller or computer.

  • Now, let's say there are 50 Markers. For each MarkerLED/Microcontroller circuit, you also add on a second IR LED, called the IdentifierLED, thus there is a pair of IR LEDs for each marker, both controlled by the microcontroller.

  • For a given marker, so that its position can be tracked, the MarkerLED is only turned ON for exactly a specific 20-millisecond-window out of each second (each marker has its own 20-msec window). During that same particular 20-msec-window, the corresponding IdentifierLED is pulsed in a specific manner by the microcontroller at a high frequency (e.g., 38 kHz), setting up a unique pattern/ID for that specific marker.

  • And the same for the remaining 49 Markers consecutively, each with its own different 20-millisecond-window and its own high-frequency identifying-pattern. That takes care of the markers' side of things.

  • Now, on the sensing side of things: For each consecutive 20-millisecond-window during a second, the IR-Camera detects the position of one specific marker (whose 20-millisecond-window it is) via the corresponding MarkerLed. At the same time, the IR-Detector identifies WHICH marker it is, from the detected pattern of the corresponding IdentifierLED.

  • And this position- and identification-tracking continues for all fifty of the 20-millisecond-windows within each second.

  • Thus, all 50 markers are tracked, with the tracking-side microcontroller able to update each marker's data once per second.

Best Answer

Rather than transmit the marker ID code from the marker to a central receiver, perhaps it would be simpler to transmit the marker ID code from a central transmitter to the marker.

The central transmitter (perhaps a 38 kHz IR transmitter or some wireless transmitter) would send, in effect, "Marker number 22, please turn on for the next 20 ms on my mark: NOW". (Ideally, while that marker is glowing for those 20 ms, the central transmitter is sending out the ID of the next marker to turn on).

Since that one central transmitter is controlling the timing, you won't have to deal with markers getting out-of-sync and accidentally transmitting at the same time.

Hopefully you can place that central transmitter close enough to the position tracker, so that if any marker can't see the commands sent by the central transmitter, that marker wouldn't be in the visual field of the position tracker anyway.

That also gives you the flexibility of using the data you get back from your position tracker to dynamically adapt which markers you select:

  • If some markers seem to be motionless or extremely slow-moving, perhaps you only need to check on them once every 3 seconds or so.
  • Perhaps you can check up on the latest positions of more than one marker at a time; something like "OK, marker number 22 and 23, please turn on for the next 20 ms on my mark: NOW".
  • If some markers are not visible from this vantage point, perhaps you only need to check if any of them have re-entered the visual field once every 3 seconds or so.
  • The time slots you free up with the above techniques could be used to track the remaining markers at a somewhat faster update rate than you could if you simply cycle through every marker in a fixed pattern.
  • If, say, marker #22 is so close to marker #23 that receiver of #23 is blinded when marker #22 is active, you could shuffle the order you turn on the markers so that the "#23 please turn on" message happens a few slots before the "#22 please turn on" message.
Related Topic