IR Hit detect, spaceships and pirates.

Keep a log of a project build here. Be sure to include pictures and as much documentation as possible.

IR Hit detect, spaceships and pirates.

Postby pilesofspam » January 31st, 2011, 1:53 pm

This is something I created for my son's 4th and 5th birthday parties. It turned out well, and it was a blast so I figure I'll post it here with enough build info that anyone interested can build one as well. If anyone has any questions, post away and I'll answer when I can.

Little background- I've always been interested in the interface point between man and machine. As a result, my hobby is custom controls. We were having a pirate themed birthday party for my son Ben's 4th birthday party, and so I built a pirate ship themed playground feature in the backyard. I still had some time before the big birthday so I thought "Why not make a custom game?" There must be at least 200 pirate themed video games available these days, and I wanted to do something original. So I made one with a big PVC cannon:
Image
and I put a pirate ship on screen to shoot at:
Image
Here's a youtube video of the whole thing in action.
http://www.youtube.com/watch?v=FwNK34K3PKg


Fast forward a few months, and Ben was now interested in spaceships and astronauts. Based on the success of 'Piratinhas' (little pirates in Portuguese, named by my friend jorgerosa over on the irrlicht forums) I decided to make a space themed game. This one was to be a coop game- a spaceship driver who manned the controls, and a gunner who, well, gunned. Here's a pic of the spaceship:
Image
here's the joystick up front:
Image
Here's a youtube video of the game in action (again, done in irrlicht)
http://www.youtube.com/watch?v=IsbFwmEBieM

Note that you really have to make sure that your IR laser is eye safe. I'll cover that and a lot of other details later.

So, to come- build details, schematics, source code and firmware to make your own. I'll put that up in ensuing posts.

Edit: changed the title to more accurately reflect the content based on input below
Last edited by pilesofspam on January 31st, 2011, 7:06 pm, edited 1 time in total.
pilesofspam
 
Posts: 17
Joined: January 31st, 2011, 1:29 pm

Re: IR laser pickup on a screen

Postby pilesofspam » January 31st, 2011, 2:46 pm

Some build details. Let's start with the most important part, the hit detect (or laser pickup) system. I guess there are a lot of ways you could do this, ultimately, the way I chose ended up being pretty cheap and really simple. Here's a picture of my projector next to the NTSC camera with an IR interference filter taped to the front:

Image

Do you know anything about black and white NTSC composite signals? Here's a quick lesson on the horizontal timing:

Image

An NTSC camera will put out a signal that contains the information of the odd lines, then the even lines in a method called 'Interlacing'. Half of your picture comes at a time, and then the other half with each horizontal line meeting the diagram above. I'm using an LM1881 decoder chip to tell me when the vertical sync happens, and whether you're on an odd or even line, and even when the horizontal sync occurs, so vertically it's easy to calculate where you are. Horizontally, however, is a different story.

So when I first concepted this, I used an arduino that I had otherwise sitting on the desk next to me. There's some very capable people who don't like the platform for real work. If you're one of them, and you're in the Atlanta area, lets discuss it over a beer on me. The vertical resolution is no problem as discussed before, but horizontal is a bit of a bugger- you've got full NTSC resolution that's got to happen in 52.6uS. You're probably looking at a maximum horizontal resolution in an NTSC CCD camera of about 480 pixels (mine is actually less, but the signal looks the same). This gives you right at .11 uS/pixel of horizontal resolution. You'll need to capture every frame, remember it, and process it REALLY fast to catch everything out there.

So let's cut to the bare essentials. If, instead, we just ran our signal to a fast comparator, and compared it to a pot, then we set a threshold. Sort of 'Anything above this level throws a signal'. NOW we're just looking for the first bright dot we can find on screen. Since your laser is only going to come out at around 1 camera pixel (yeah- you can lose 1 pixel of accuracy as it bleeds into neighboring pixels but I don't care) we just have to identify that spot.

So- to capture a single pixel happening in .11uS, we need about a 10MHz (or higher) clock and a processor that runs at one clock cycle per instruction or interrupt to get reliable values, and since we're sampling we could lose a whole pixel of resolution at this rate.

I had a 16MHz arduino sitting on the desk next to me, powered by an avr ATMega168. Even better, it's got a USB to serial converter on board.

Here's a schematic of the final board (I rolled my own with an ATMega168 and burned an arduino bootloader onto it) which uses this functionality. NOTE: Pins 2 and 3 on the USB port are reversed. I had to cut and rewire these on the actual board!

Image

Here's a link to the 'Express PCB' schematic and file. It's not the best deal if you want to go into production, but I only needed one working board, and the software is free (but a proprietary format). Remember that pins 2 & 3 on the usb connector are reversed.

http://www.gdn.net/~dbarr/daily/lsd.sch
http://www.gdn.net/~dbarr/daily/lsd.pcb

Here's a picture of the populated board. Notice the reset button in the middle which doesn't quite fit, the cut and jumps to the usb port, and the RCA plug (which is the camera signal) in the bottom.
Image

For the firmware, I took a little bit of liberty by hijacking the timers that the arduino usually uses for PWM, etc, and the reason I grabbed em is so I can ditch the prescaler, reset the timer at the beginning of every horizontal sync, and then interrupt on any incoming NTSC signal above the threshold. The ATMega168 has an interrupt that saves the timer value for you, so you've instantly got clock counts from the horizontal sync. it's a quick calculation to turn this into screen position.

Here's a link to the firmware download:

http://www.gdn.net/~dbarr/daily/pirates.pde

And I'll post the code here for easy perusal (It's short)

Code: Select all
/*
pirate ship simulation hit detect
 */
 
#include <avr/interrupt.h>
 
#define  vertical_sync_pin     2
#define  composite_sync_pin    3
#define  brightest_pixel_pin   8

volatile unsigned int vertical_line_number=0;
volatile byte  seen_dot_flag=false;
volatile byte arm=false;
volatile unsigned int horizontal_position=0;


ISR(TIMER1_CAPT_vect){
    if (arm)
      seen_dot_flag=true;
    horizontal_position=ICR1;
}





void vertical_sync(){
   vertical_line_number=0;
   arm=true;
}

void horizontal_sync(){
  TCNT1=0;
  vertical_line_number++;
}
 


void setup()
{
  attachInterrupt(0, vertical_sync, RISING);
  attachInterrupt(1, horizontal_sync, RISING);
  Serial.begin (115200);
  TCCR1A = 0x00;      // COM1A1=0, COM1A0=0 => Disconnect Pin OC1 from Timer/Counter 1 -- PWM11=0,PWM10=0 => PWM Operation disabled
  TCCR1B= B01000001;      // 16MHz clock without prescaler means TCNT1 increments every 1/16uS rising edge noise canceller
  TIMSK1 = B00100000; // ICIE1 enable the icp, plus the overflow interrupt
  sei();
}



void loop()
{
  if (seen_dot_flag) {
    seen_dot_flag=false;
    cli();
    Serial.print(char(horizontal_position/4),BYTE);
    Serial.print(char(vertical_line_number),BYTE);
    arm=false;  //disarm till next vsync
    //delay(100);
   
    sei();
  }
}



For my current projects (Pirate cannon, spaceship gun turret) accuracy just isn't that important, so I convert to two bytes- first horizontal and the second vertical. On a 96" wide screen, I get +/- 1/2" of horizontal accuracy and +/- 1/4" of vertical accuracy (observed). The only negative is that I have the camera aperture and sensitivity (ISO) set pretty high, because I keep my lasers really dim. As a result, I get a noise induced false fire every 5 minutes or so. Really this works fine with a visible laser as well- I initially tested with a red laser and a red wratten kodak filter on the camera, but you get more false fires from bright red (and some white) content from the projector.

OK- next up, I'll put up some details on the software interface!

(Edit 2/1/2011 - put up links to the schematic and pcb files)
(Edit #2- 2/1/2011 - added a picture of the stuffed pcb)
Last edited by pilesofspam on February 1st, 2011, 8:28 am, edited 2 times in total.
pilesofspam
 
Posts: 17
Joined: January 31st, 2011, 1:29 pm

Re: IR laser pickup on a screen

Postby pilesofspam » January 31st, 2011, 3:33 pm

Software Development.

Coming into this, i really had no idea how to approach it, so I began researching 3D engines. Turns out there is a wealth of information and friendly communities available. After playing with a few, I chose Irrlicht http://irrlicht.sourceforge.net/ mostly because of great examples and a terrific and friendly community, but also because the learning curve appeared to be shorter than some of the others. Ultimately, 'Piratinhas' ended up being a great starter project because it was simple in concept. I even trimmed the scope by making each cannonball reset the last one (like in space invaders, where your bullet in flight disappears as soon as you fire the next one). While Planetwars is open source, Piratinhas, unfortunately, is not open sourced because I got my original pirate ship off of google sketchup and couldn't contact the original author. Jorgerosa from the Irrlicht forums has given me permission to use his (which appears in the screenshot a few posts up) so as soon as I get a few hours to do some code cleanup I'll release the whole thing.

The platform is Linux, originally done to run on Mythbuntu 9.04 which is what my home theater PC was running (it is now running Mythbuntu 10.10). Fortunately, it's an easy translation if you want to run these elsewhere.

For Piratinhas, the only input is the on screen hit detect. The software just moves the pirate ship around waiting for two bytes to come in the USB serial port and shoots a cannonball appropriately. For Planet Wars, the same thing applies but I've also got to manage the position of your spaceship (which is really just the camera), a couple of shots, and all the enemy spaceships. It was really easy to set up a solar system that more or less takes care of itself. Incidently, many thanks to James Hastings-Trew who allowed me to use his planet textures. You can find his website here:
http://planetpixelemporium.com/planets.html
The rest of the art and objects I actually created myself using Blender and the Gimp, and LordHavoc's LHfire billboard particle generator. The sounds (even the 'pew' of the laser cannon) were generated using a bunch of open source sound tools like DrPetter's sound tool http://www.drpetter.se/project_sfxr.html and Audacity http://audacity.sourceforge.net/ The voices actually belong to members of my family, who did a great job, but I learned a few lessons there- professional voice actors are very good, and when you pretend you're being loud it just sounds like you're pretending to be loud.

So- before I point to where the source is, please keep in mind that this was my first major foray into C++, and I was following the next 4 steps in order:
1. Make it Work
2. Make it reliable
3. Make it understandable
4. Make it pretty

I got most of the way through step 2.

You'll need svn to check this out of sourceforge, but from a linux command line all you need is:

svn co https://alienplanetwars.svn.sourceforge ... planetwars alienplanetwars

That's all for now. Tonight I'll try to post specific details on the laser- especially with respect to eye safety- and other detail challenges like "You can't use incandescent lights on the screen if it's looking for an IR dot!"
pilesofspam
 
Posts: 17
Joined: January 31st, 2011, 1:29 pm

Re: IR laser pickup on a screen

Postby MS3FGX » January 31st, 2011, 6:12 pm

Well...that is a really lucky kid, that is all I can say. This is some very impressive work, and excellent documentation for what you have done. I would only suggest you change the topic title to something more descriptive, as I don't think "IR laser pickup on screen" really does this work justice. There is a whole lot more to be learned from this than just that.

Also, I would expect this project to be featured on HaD in the very near future, if they haven't already contacted you about it.
MS3FGX
 
Posts: 356
Joined: January 25th, 2011, 10:47 pm

Re: IR Hit detect, spaceships and pirates.

Postby pilesofspam » January 31st, 2011, 7:32 pm

Thanks MS3FGX- new title which is both more enticing and possibly more accurate.

I'll cover laser safety and the laser design tomorrow. It's an important topic and I'm a little limited on time at the moment. Instead, I'll mention a little something about the environment.

Since we're looking for a very small dot (well, one camera pixel) above a threshold, we really need to limit the amount of extraneous IR in the room. My first challenge was to black out all the windows. Since I use this room as a theater, we're already there, as I have rollup blackout shades and curtains over the windows already. But what about the downstairs lights?

CFLS to the rescue:

Image

Only one problem. CFLs drive my antiquated X10 controls bonkers.
Image

So I put one low wattage incandescent in the can furthest away from the screen on each switch:
Image

With this setup, I can leave the lights on if desired, and dial R3 (my sensitivity pot) until the ambient room light no longer spews data all over the place. It took less than a minute to tune, and from here I can pick up an IR laser anywhere on the screen. The only problem occurs when people are coming in and out of the door, allowing enough IR light to spill onto the screen to overwhelm any laser shots. The kids were pretty effective at making sure the door stayed closed.
pilesofspam
 
Posts: 17
Joined: January 31st, 2011, 1:29 pm

Re: IR Hit detect, spaceships and pirates.

Postby pilesofspam » February 1st, 2011, 8:22 am

Eye safe lasers

We're running a party with a room full of 5 year olds, I really need to make sure I'm not going to blind one of them. How should I go about this? Lets start with the power limits of eye safe lasers- meaning how much power can your eye take before it burns:

Image
Source: wikipedia

The laser module I'm using is this one:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=38-1018-ND

which is a 780nm 5mW ir laser. In the IR spectrum, it's no brighter than your regular red laser pointer, except that if somebody shines a red laser in your eye you BLINK within .25 seconds. That's what makes the red one eye safe. There's no reason to blink at the IR laser (you can't see it), so you'll burn your eye.
To find the exposure limits of power vs. time, we look at the graph above, particularly the purple line (800nm). My laser, again is 5mW which translates to .005J/cm^2 . Since the aperture is 4.3mm, we really have an area of .145cm^2 if you were to look directly into the laser up close (there's some divergence as you get further away- my spot on the screen is closer to 1cm diameter).

Based on the graph above, we need to limit our ontime to .01S to remain safe. So how did I do this? The Laser module requires 2.1VDC nominal, so I had another arduino lying around. I connected the laser module's + lead in series with two silicon (0.6VDC drop) diodes to 3.3VDC. The laser module's - lead is connected to the collector of an npn 3904 transistor. The arduino controlls the base (through a 1k resistor) and the emitter is connected to ground. Firing the arduino control pin fires the laser. Another arduino pin is selected as the 'Trigger' pin. When the trigger is activated, the arduino fires the laser for 1mS every 200mS to simulate rapid fire, staying well within the limits.

Here's a rough schematic:
Image

The only problem left is that I believe 'Eye Safe' is determined by FDA standards- feel free to chime in if you know the details. In order to be truly eye safe, you'd need to make sure any single point of failure could not make the laser non- eyesafe. You might accomplish this with a 220uF cap in parallel with a 1k resistor, then put that in series with the laser above. This would let the occasional quick pulse through, but even if the circuit shorted ON the laser could not remain on. I haven't tried this, but it should work.

Image

I believe that concludes my presentation, except I may go back and edit some of my 'stream of consciousness' ramblings and add a few pictures. If anybody has any comments or questions, ask away! Also- if anybody builds one of these, let me know. I'd love to build a network game on this platform.

Dave
pilesofspam
 
Posts: 17
Joined: January 31st, 2011, 1:29 pm

Re: IR Hit detect, spaceships and pirates.

Postby omstout » February 1st, 2011, 10:32 am

You Sir, are quite probably, the Coolest Dad of the Month.
omstout
 
Posts: 1
Joined: February 1st, 2011, 10:29 am

Re: IR Hit detect, spaceships and pirates.

Postby christian » February 1st, 2011, 11:43 am

Hi,

Nice work.

How did you come to the "safe" exposure time for the laser? I feel like I followed your explanation up to the point where you drew a conclusion from the graph.

Christian
christian
 
Posts: 1
Joined: February 1st, 2011, 11:35 am

Re: IR Hit detect, spaceships and pirates.

Postby pilesofspam » February 1st, 2011, 12:50 pm

Hi Christian,

Sorry about that, I documented that part quite poorly, as that graph is measured in energy density and you have to take aperture, ontime, and duty cycle into consideration. Here's a better graph, also from wikipedia. It's measured in watts/cm^2. At 5mW with an aperture of 4.3mm (.145cm^2 area) you should use .0345 watts/cm^2 for the Y axis.

Image

This puts us at .001S exposure time if you stick your eye on the front of the laser, and the time increases a lot as the beam diverges towards the screen (where the area is about .8cm^2 and the power number you use is .006). Note this number is for class 1 MPE, which means it is 10% of the dose at which you have a 50% chance of incurring damage.

The hit detect works with a shorter pulse as well, but at some point your signal/noise ratio will become an issue. I didn't test to find out where that point is.
pilesofspam
 
Posts: 17
Joined: January 31st, 2011, 1:29 pm


Return to Project Logs

Who is online

Users browsing this forum: No registered users and 1 guest