LaserTagging

From syn2cat - HackerSpace.lu
Revision as of 13:42, 8 March 2009 by Kwisatz (Talk | contribs)

Jump to: navigation, search

Contents

Event

Next Events

??/03/2009 Event at the Musée national d'histoire et d'art/Marché-aux-Poissons

Past Events

17/01/2009 Test installation at Dudelange


Technology

Test Results

Performance

Testing has shown that performance with cameras that have automatic exposure control (which can't be turned off) is spotty at best. Performance on a windows laptop with a mobility radeon 9000 and a 3Ghz P4 is more than acceptable, but the faster the better.

Exposure

Webcams control exposure by a setting parametrised by a shutter time (ie: 1/20 s ), the inverse of which is obviously the maximum possible framerate sent by the cam to the bus. Many cams allow this to be set as low as 1/1000, but obviously both the encoder on the cam and the usb bus cannot handle these sorts of loads. 48fps @ 320x240 have been measured using a logitech communicate deluxe on linux. This is more than sufficient for good laser tracking as the tracking soft will probably max out at ~ 40fps on a laptop.

Settings

  • Exposure autocontrol HAS to be disabled. (in low light conditions the framerate drops to 4-5 fps)
  • Colours have to be set to something natural (the laser tracker uses HSV triplets to detect the laser spot).
  • Brightness must be reduced as far as possible (the relative brightness of the laser pointer more than makes up for this), otherwise the tags themselves mess with the laser tracking (even if they are red).
  • The best results were observed when the tags were barely visible on the camera image.
  • It takes about 10-15 minutes to get the software set up correctly. It was observed that the best approach is to reduce each tracking option to zero (not all at once) and then slowly increment it until tracking works. Repeat for each and then go over the list again just to be sure.

Avenues for Tuning

The software appears to be written really badly. Internally as many framebuffers as there are brush types (ie 4) are kept and updated continuously which causes massive overhead. No lines are drawn on the inactive buffers but their contents are still updated. (this is speculation from a vallgrind run which shows that for each call of "processFrame", rgb24_to_hsv is called 4 times. I will confirm this in the next few days and, hopefully, fix it.)

Resources

Software

Source

Software Setup

Personal tools
Namespaces

Variants
Actions
Navigation
syn2cat
Hackerspace
Activities
Initiatives
Community
Tools
Tools