Monthly Archives: January 2017

Quick Tangent: An Open Standard for Indoor Navigation

“Since when did this blog become solely about indoor navigation? I thought that this thing was supposed to be about metadata?” Well…I can’t argue with you. I need to get back into that at some point.

In any case, after sampling different platforms for indoor navigation, I’ve come to notice something: there is no open source standard for indoor navigation yet. Of course, there is much discussion about indoor navigation within the gaming industry, especially within the community for Google’s Project Tango…but there isn’t as much talk when it comes to API standards. Considering that open source standards seem to be falling from the sky in the last few years (for cloud computing, for automobiles, etc.), it seems fitting that one of the bigger players (like Indoor Atlas or Estimote) should take this opportunity to lead the way with an open standard. As IoT invades our lives, indoor navigation will probably become more prevalent, and more development standards would be beneficial to the industry. (Of course, these Northern Europeans are probably too busy slugging it out, since that’s part of the travails of being a startup company.) I suppose another unmentioned company could also take this lead, but I’ve found that many are not as developer-friendly as Indoor Atlas and Estimote; most require any interested parties to fill out an application before even allowing access to their documentation.

Now, it wouldn’t have to be an all-encompassing standard, but it should probably take into account each of the strengths in the current set of available platforms. In addition to the practice of emulating Apple’s Location Manager (which they all seem to do in their iOS SDKs), an open standard could include interface methods for functionality like:

  • The ability to overlay the indoor navigation map over an actual world map (which is offered by Indoor Atlas).
  • The ability to generate a map of the indoor space dynamically (which is offered by Estimote).
  • The ability to raise a signal (email, text, etc.) when someone enters the navigable area (which is offered by both Indoor Atlas and Estimote).
  • The ability to generate an account with the vendor’s services programmatically (which I could see as being helpful to developers who want to incorporate these services into their own products).

Maybe I’ll create a sample and upload it to Github in the near future, as a more verbose example.

On a side note to this new standard, we can leave out some of those confusing and misspelled messages that are generated by Apple’s Location Manager. Who comes up with these things?

Advertisements

The Game that Could Be

Oh, I had such lofty aspirations when I came up with the idea for a haunted house game. I had been so sure that there was an existing technology whose SDK would fit my plan…and, at this point, maybe there is!

So, having found an indoor navigation system that didn’t require the purchase of peripheral beacons, I decided to actually give it a try (though, due to past experience, I didn’t get my hopes up). So, I followed their tutorial’s advice, and I constructed a map image of my home. I created the map to scale, in order to achieve optimum results. After I uploaded the plan to my Indoor Atlas account, I then proceeded to follow the next step: using their tracker app, I did two walkthroughs of my house, hitting over a dozen waypoints with various permutations of edges. (After all, you’re creating a directed graph for them.) With some assistance from the helpful people at Indoor Atlas, I got my settings and floor plan to be exactly as I needed them to be. Thanks Elina!

Since they didn’t have an app that helped demonstrate the power of their SDK, I sought an open source project that helped to showcase their tech, and after poking around a bit, I eventually found one. I pulled the project, and after making a few corrections and downloading the right parts (updates from Apple, Homebrew packages, required Cocoapods, etc.), I was able to compile and deploy the project to my iPad. (I have to admit that I love how XCode offers to fix your code when certain methods have been deprecated or renamed. I wish that other IDEs offered the same service.)

When I ran the demo, it did load my map image, and I was able to navigate around my place with the demo project in hand. Finally…I had achieved some form of success! Now that I had a feasible technology stack as a solution, I could reflect on this platform as a possible choice:

Pros:

  • The indoor-navigation functionality works well, even though it’s sometimes inaccurate in more confined spaces and smaller rooms.
  • The SDK is fairly easy to understand and integrate into your project.

Cons:

  • In order to integrate their tech stack into your project, there is an investment required, especially for any potential user of your product (generating a scaled map image, walking through your place, etc).
  • Your potential product will require the user to create an account with Indoor Atlas.

In the end, I’m not exactly sure if this particular solution is a best fit…but any potential is good news to me. I’ll have to play with it a bit more in order to find out.