I always think about circling back to my haunted house game, especially since it seems that the tech stack gets a little closer each year to making the design viable. And now, just a few days ago, the IEEE standard for precise locations was announced to be released in March! That means silicon designs could be just around the corner, right…?
…right?
Oh, let’s be honest. At this rate, I’ll be one of the ghosts in my game before this damn thing ever gets done.
For the most part, I tend to regard the idea of my ghost invasion game as simply vaporware…but every now and again, some kind of news comes out that makes me think on the contrary.
A device that can track people through walls? As a medical monitoring device, it has enormous potential. Of course, though, there are the creepy possibilities that could become the stuff of Orwellian nightmares…but for a moment, let’s ignore it. I’d like to think of the other potential uses for it…namely my game! So, Ms. Katabi, as much as I’m afraid of your electromagnetic Eye of Sauron, I can share your vision of its more benevolent usage. I only have one question: can I get a development kit before governments of mass surveillance become clients and raise the price?
So, it’s been a while since I talked about indoor navigation. It’s one of those things that I always come back to, especially since that idea for the ghost game always comes back to me now and again. After a conversation with a hardware grad student in a PhD program, I got excited about the idea again and went looking once more for a software solution. As it turns out, Microsoft wants in on the action. After playing with it for a while, though, there’s only one problem: much like other indoor navigation solutions, it doesn’t work exactly.
In my apartment several stories up and which occupies only one floor, I will walk several feet. Then it will suddenly prompt me, asking me which floor I’m headed to. Apparently, it thinks that I’m in an elevator or on an escalator.
With all the difficulties amassed between AR and navigation, it’s no wonder that Project Tango was closed by Google. And it’s no wonder that this Microsoft navigation project apparently hasn’t been updated for a year now. After all, AR and indoor navigation are tough subjects to tackle.
So, it’s refreshing to hear that Microsoft might be rethinking some of its past approaches. After having experimented with their earlier iterations of Windows IoT, I found it an interesting foray for Microsoft. However, I didn’t really believe that it’d be adopted by manufacturers and (especially) developers. It seems that Microsoft has had the same realization recently, and it’s now pursuing a new project to revamp their IoT (and mobile, to some degree) portfolio called Azure Sphere. Now, this initiative could maybe breathe new life into some of that confused tech. If somebody out there creates a kit for Azure Sphere, I’m a taker. I’m looking at you, Adafruit!
Usually, I don’t find OS updates particularly exciting, and I generally favor waiting for everyone else to take the hit in becoming a first adopter. However, I found this particular note about Android P very interesting, enough so that I might sit in the front row of class and raise my hand:
Today’s preview includes the following new APIs and features (but you can expect much more; this is just the first preview, after all): Display cutout support; HDR VP9 Video, HEIF image compression, and Media APIs; HEIF (heic) images encoding has been added to the platform; multi-camera API; ImageDecoder for bitmaps and drawables; Improved messaging notifications; Data cost sensitivity in JobScheduler; indoor positioning with Wi-Fi RTT: Platform support for the IEEE 802.11mc WiFi protocol — also known as WiFi Round-Trip-Time (RTT) — lets you take advantage of indoor positioning in your apps.
INDOOR POSITIONING!? Well, that might change the whole situation. Maybe I should dust off the old code, crack some knuckles, and get to work!
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:
Cons:
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.
So, as for the waiting addressed in the last post (i.e., the latest about the Haunted House saga), it ended when the next package of beacons finally reached my house. Almost immediately upon arrival, I registered the beacons using my Estimote account, and now having a total accumulation of six beacons, I placed them around my home and started the Indoor Location app on my iPad. As excited as Ralpie Parker with his BB gun in A Christmas Story, I started the app and followed the tutorial. “Okay, now I just need to create a location with the ‘Add new location’ button…where is that button…” After a minute of being unable to find it, I looked online and found nothing to assist me, feeling a little like a newb for not being able to resolve my problem.
Defeated (and now feeling more like Ralphie when he shot his eye out), I sent an email to Estimote so that they could enlighten me. Now, they did respond quickly with an explanation…but it wasn’t exactly the one that I had wanted to hear. It seems that the iPad could only navigate an indoor location with their app; if you wanted to setup a location with their app, you needed to have an iPhone. “Say what?” Yes, you’ll want to navigate a location using an iPad’s wide display, but you’ll have to create the location with the phone. It is, for the most part, a two-device solution. (My only guess is that the Bluetooth capability of the phone is more powerful than the pad.) Of course, one can imagine how happy that answer made me, but in fairness to Estimote, they empathized with my plight by refunding the cost of the beacons to me. Still, I would recommend that they explain the hardware requirements in flashing red letters on their site for future customers, since that might be something of interest to them before making a purchase.
So, back on the hunt I went. I was definitely finished with looking for a hardware-specific solution, and after looking around a bit more, I found a compelling product that needed no peripheral hardware at all: Indoor Atlas (i.e., IA). Interestingly, their solution did not need beacons since instead of using Bluetooth or GPS, it relies mainly on the electromagnetic fields that exist within the confines of a building. Based on my limited time spent reading (i.e., scanning every other word) and as I understand it, it seems that each room has an unique signature in terms of its EM field, and if you walk around your appartment with scattered waypoints, it can create a traversal graph based on your walk, with the unique EM fields being nodes. (If some WiFi is available on the premises, that can be of some help as well.) And all you need is your phone and nothing else. Cool! Even though I’d been let down so many times before, I got excited once again, and I downloaded their Map Creator app in order to get crackin’.
So, creating a map went fairly smoothly, with me walking from waypoint to waypoint in order to exhaust all permutations of possible navigation. In fact, as you create all possible edges between vertices in this messy graph, the app shows you its estimation of where you are, and with each new edge, it does seem to get smarter. Once I was done with my walkthroughs, I uploaded the data from the MapCreator app to my Indoor Atlas account, and I proceeded to generate a map of my place. The only question was: how can I use it? With Estimote, they had an app to showcase their tech, so that you could watch it in action before writing one line to call their API…but not so with IA, it appears. Basically, if you want to navigate your generated map, you’re going to need to get dirty: create your own app and access the map through the Indoor Atlas API. Since IA supports both Android and iOS, I was hoping for some sort of Xamarin solution…but, unlike Estimote again, no dice. It looks like I’ll be blowing the dust off my buddy’s aging MacBook in order to see what I can cook up on my own.
So, in my last post about the Haunted House saga, I had finally found a product that offered me hope when it came to a technical foundation for creating and tracking objects in a very local space. (Just the thought of pouring over books about math and Bluetooth hardware gave me a headache.) So, with joy, I started to read about the services offered by Estimote. Basically, they supplied both IoT devices (i.e., beacons) and a SDK that enabled you to detect their beacons (which you would deploy yourself around a space). That was interesting by itself…but then I found the mother lode: their Indoor SDK package. Basically, with that SDK, they provided the software that created a 3-dimensional model in your app…and helped you track someone/something in it! And their platform was available for both iOS and Android…and Xamarin had even created components for both platforms! Oh Mommy!
Since their business office is here in New York, I got the opportunity to have coffee with one of their sales people, and he was kind enough to offer me a discount on my initial purchase. Excited, I bought a kit of 3 location beacons, and once they arrived, I set them up using their online tutorial and downloaded some of those Xamarin Android projects. (When you create your online account, you can change your beacons’ settings through your account, and then the Estimote app on your phone pushes those settings onto the beacons from the cloud.) First, though, I started by playing with the Estimote app (in order to confirm my beacons were working properly), and even though the app did notify me when I had approached one of my beacons, it seemed to have a hard time with estimating distance…and it seemed to think that I was moving when I wasn’t. Nonetheless, it was working, and I was building a prototype for a game, not a rocket! So, with some positive results as fuel, I dove into their Xamarin projects with more simple functionality, like notifications. I got mixed results, but again, I was prepared to get my hands dirty if needed. Indoor SDK, here I come! Oh, wait a minute…something is not right…I need 4 of these beacons that are sold in packs of 3? And the Indoor SDK is only available on iOS??? Grumble, grumble, grumble… Well, kids, take this lesson to heart: always read the fine print first before you get too excited.
Of course, when I thought about it, it made perfect sense: Android hardware is too varied in quality and specification to write accurate libraries for all of them. I get it..So, at this point, I asked myself the simple question: do I call it quits here? Uhhh…is my name Quitter McQuitFace? Exactly. So, I went ahead and ordered another pack of 3 beacons, bought a refurbished iPad, and arranged to get an old MacBook loaner from a friend. While waiting for my next beacon package to arrive, I’ve played with some of their more fundamental iOS code samples, since it would be a while before I would get to play with the samples for the Indoor SDK. Again, as I noticed when initially playing with the Estimote app, some of my results were anomolous. For example, when playing with a notifications sample deployed to the iPad, I seemed to receive inconsistent alerts when approaching or leaving a beacon’s domain; in fact, at times, it seemed to tell me that I was approaching a beacon when I had walked away from it! Hmmmm…I’m slightly concerned, but my curiosity and optimism is too high to be knocked down. Now, in order to get to the good stuff (i.e., the Indoor SDK), I just need those extra beacons. “Oh, and the waiting is the hardest part…”
So, while I’m still waiting for the Android port to Raspberry Pi, I did a little more homework, making some notes about calculations that would eventually be needed for my project. More importantly, I started to reconsider the whole idea of having a platform-dependent solution to the sensor for the Haunted House game. I mean, there has to be something out there, right? Something cross-platform like JavaScript…hey, wait, Google has the Bluetooth Chrome API! That’s perfect!
Excited yet again, I started to look over the documentation, and I started to play with the samples. So far, so good! Using the API, I could detect my smartphone when the Bluetooth was enabled…and I didn’t even need to pair it! Now I just needed to read the RSSI value on the Device class, and using the calculations, I could create a proper sensor capable of estimating the distance to nearby Bluetooth devices. “Wow, this is going to be so great!” But then I noticed that there was no value being populated for that property. Hmmm…oh well…maybe I wasn’t doing something right. So, I poked around on the Chromium site, and it revealed to me…oh no…
https://bugs.chromium.org/p/chromium/issues/detail?id=552268
So, the developers of the API are debating how to properly set the RSSI value for the signal, since there are nuances when it comes to the detection of the device. They haven’t come to a consensus yet…so, for now, the property remains unpopulated. Which brings me back to square one yet again.
I’m getting used to the disappointment…
…but the darkest hour is just before the dawn! And that was confirmed when I found Estimote while preparing to jump off a cliff. My manic ride is at an apex once again, and I’m looking forward to performing a few experiments in the future.
So, just like the previous time, my wise patience (or so I’ll proclaim from now on, despite any attempts to discredit me) has returned on my investment. It seems that the Raspberry Pi will have yet another option soon enough: Android!
Which means, for me, that I could still potentially rely on C# and Xamarin to create/deploy my sensor app onto a RP device for the Haunted House game. The Git tree is empty for now…but when actual code starts to show up, I’m gonna start dancing a jig like Bruce Willis in The Last Boy Scout.
After my enjoyable round with the Windows IoT projects, I decided to continue my pursuit of the Bluetooth-powered prototype mentioned beforehand. After doing a bit of looking around, I discovered a popular .NET library called 32 Feet, and looking at a few code samples, I downloaded the Nuget package into Visual Studio 2015. I was eager to get cracking on my project, confident my goal was near. Haunted House, here I come! However, upon completion of the download, I noticed an immediate, cryptic error when compiling a simple code sample using 32 Feet. After a bit of research done to decipher the error, I finally learned a lesson about Universal Windows Platforms (i.e., UMP): older Nuget packages are not compatible with the new UWP framework. So, unfortunately, the 32 Feet package became an unviable choice. “Oh well…I guess that I need to find a UWP-compatible library.”
Moving on, I found Microsoft’s answer to my Bluetooth conundrum: the Windows.Devices.Bluetooth namespace. When I saw the available usage of the BluetoothSignalStrengthFilter class and the Windows.Devices.Bluetooth.Advertisement namespace, I became excited once again at the prospect of my prototype’s potential success. Pulling down the entire roster of UMP samples, I began to scrutinize the code so that I may apply whatever lessons to my modest prototype. (Interestingly, when I downloaded the compressed file of code samples to a nested subdirectory, I received an error about the filepath being too long. I considered that strange since I’ve haven’t seen such an error on a Windows system in a long while. Did they change something with Windows 10?) After the preliminary steps of enabling Bluetooth on my phone and using the admin panel to pair the phone with my Raspberry Pi 2 (i.e., RP2), I was able to deploy and run one sample…and, yes, it was able to detect my phone from the RP2! Victory! And with that, I put the device away for the day (which doesn’t exactly fit well in the Adafruit plastic casing), and all was right with the world…
Until the next day. When I attempted to boot the RP2 again with my Windows IoT card, it failed to start normally. Instead, it simply flashed the Active LED (i.e., green) light 7 times, and then it repeated that sequence over and over. Curious as to the issue, I did a search in order to diagnose the problem, and nothing was to be found except for some consolation on a few scattered pages. Disheartened, I now had to accept the facts: it seems that Windows IoT has some ways to go before becoming a mature platform. And I had wanted to believe that things were going to be so easy! So I went ahead and ordered a card with Raspberry Wheezy Linux, preparing myself for the long road ahead of me. Since the future isn’t quite here yet, it’s time to go back to old school and get my hands dirty with some command lines.
Meta Data Dojo 