views:

94

answers:

9

I'm writing an app for a museum tour. I'd like my app to know where the user is in the building, if the user is standing in a particular room, in front of a particular work, etc.

GPS doesn't work inside. (Using WiFi positioning could work, but I know Apple doesn't use Skyhook anymore, so I don't know where I would register my base stations.)

Since GPS won't work, it would seem like having a specialized device in a known location and having the app detect that device, could work. But based on my research, this doesn't look easy, either:

• There's no way to detect nearby WiFi base stations because Apple doesn't allow querying for base stations via public APIs.

• Finding a device via Bonjour only works if the devices are already on the same WiFi network. And the Guest's phone won't be on our WiFi network.

• GameKit...hmm...don't yet see an angle there.

Does anyone have ideas on how this could be implemented?

Thanks!

A: 

The only thing I can think of is bluetooth, but I'd think that would be nearly impossible to get right.

Most people have one or two RFID tags on them, if they allow it maybe you could have a handful of detectors rigged up. I know I carry 3 different ones (car keys, building passes) and maybe more.

Bill K
+1  A: 

How about barcodes (traditional or 2D)? These can be printed as part of the work description.

Paul Ardeleanu
+2  A: 

I would probably stick some hundred QR-codes on the walls of the building.

fluchtpunkt
Would have to have the camera on and facing the walls all the time though. And iPhone before 4G has a rather horrible camera. Hmm...
Rei Miyasaka
A: 

The AMNH Explorer app does this

Steve
A: 

Here's a ridiculous idea: set up speakers around the building emitting high pitched pings beyond audible range. Each speaker would emit a unique sound which can be identified and triangulated.

With enough DSP it just might work. I'd feel sorry for any dogs and cats and teenagers in the vicinity though.

Or you could try deploying your own GPS stations -- but I'm willing to bet that you'd get a visit from men in black trench coats arriving in an unmarked van.

Rei Miyasaka
A: 

Can you manufacture some small device for the task? ie making an IR receiver that can identify a IR emitted code and make a sound signal for the iPhone to interpret through the headphone mic plug.

Here is a pure mic but I think it could be made with an IR sensor instead. alt text

And...here is a product that does both sensing IR signals and emits IR. Redeye mini. Then you will need some sender devices for the rooms and perhaps near a particular work.

epatel
A: 

I ran into this problem myself last summer during an internship, because of the research I was helping to conduct I know the only real solution that doesn't involve extra hardware or user involvement is to use the private API and avoid the app store.

This obviously only really works if you have complete control over the hardware being used on the tour (I.E. you provide the iPhone). If you do provide the iPhone then you can deploy the app to it manually. Obviously that isn't an ideal situation but it would work.

As others have mentioned the use of QR-codes is another solution to the problem but requires the user to actively look for the codes to get the information for the tour. For the individual exhibits this would work quite well but it has limitations especially if there isn't a convenient place to put them.

James Raybould
A: 

I went to a museum where they used a different approach.

At each location, the phone user texted a code to a number, and received a text message.

Perhaps you could do something like that.

Gilbert Le Blanc
A: 

I suggest Bluetooth. I did some preliminary work on a similar problem, played around with some code for watching which bluetooth devices were visible to the phone while walking between rooms of my house.

You don't have to pinpoint precisely where the bluetooth devices actually are; if you can see device A and B but not C then you're in this area, if you can see all three then you're in this area, etc. With a little bit of "watching" the signal changes you can pinpoint their location more closely, e.g. I can see A but not B or C and 10 seconds later I can see A and B then odds are good that I'm towards the A-only side of the A+B area; when 10 seconds later I can see B+C but no longer A then odds are good I'm closer to the area where you cross from A+B to B+C, etc.

Though I didn't test it exhaustively, my results were sufficiently positive to advise my client that some more robust, real-worldish testing was worthwhile, that this would likely work just fine. There might be issues with signal bounce that might require some shielding or that kind of thing, but it does seem feasible.

Matthew Frederick
I think this will likely work for us. The only downside is that there doesn't seem to be a way to turn on the Bluetooth automatically, save for using the GKPickerViewController (or whatever it's called), and I don't want to use that UI. So I may have to resort to asking people to turn on Bluetooth. Not ideal, but may be okay. Thanks for everyone who answered!
Greg Maletic