Context Management System

The research publication Charting Past, Present, and Future Research in Ubiquitous Computing by Gregory Abowd and Elizabeth Maynatt talked about the importance, representation and ubiquity of context, and coupling it with awareness, natural interaction and automated capture. Reading this paper got us deeply interested in creating a system that gathers this kind of context, because often, that is the first step to making context-aware solutions.

For our design to be practical as a ubiquitous system, we had to work around some constraints.

• The system has to be small enough to fit on/in other appliances and devices
• The sampling frequency should not be so high that the system draws too much power, but also not low enough that it contains stale information about the current state
• The components used to build the system should consume as little power as possible
• It should have an interface to obtain energy and communicate with other devices
• It should balance the accuracy of indoor localization against size and power consumption - research to be done about the exact accuracy
• Should not be constrained by technology available now, but should have modularity to support future technology (like Bluetooth Grid) for each of these components

My first form was a small cube with electrical contacts on one side, attaching magnetically to whatever device it was talking to. After playing with some mockups, I discovered that the form is not stable enough, and would be easy to lose. I gathered a few other objects around my desk to see if any of them would serve as a good starting point for design. These included a Mini Wireless Router, a Screen Fluid spray bottle, a bike light with rubber loops at the back, a remote control and so on.

I had once found this discarded Fitbit Ultra and thought it would be an interesting design to explore. This second-generation device was created after complaints from users about losing their fitbits, so it was supposed to be a tighter hinge. It also contained several sensors inside, along with a rechargeable battery and a radio that talked to the base station using the ANT protocol.

Therefore, while creating the recommendation for the final form, we would keep this as the reference design, with the wireless radio, battery and accelerometer-based wakeup mechanism while redesigning the contacts for power and data, as well as interaction mechanisms to have it as close to zero-workflow as possible.

The What, a self-referential ID:

• String of arbitrary character length stored on the device to be sent from (more human readable)
• A binary ID field, possibly 16 bits, that is mapped on the server to the names, for an overall possibility of 65,536 possible addresses (less data transfer overhead, fewer bits sent)

The When, a timestamp obtained from the Internet or maintained locally:

• The timestamp in UNIX format, example: 1970-01-01T00:00:00Z (more human readable)
• Epoch time, that is, number of seconds since midnight of January 1 1970. As of writing this webpage, time is 1517780033. (more efficient for data transfer)

The Where, a localized coordinate with respect to some reference point:

• Three unidirectional radio transmitters placed at 120° angles to calculate polar coordinates from the radio cluster (requires custom design, outside of experience for me and my team mates, but does not need to be trained at each new deployment)
• MIT's 'The Cricket' indoor localization system, (a legacy system, hard to source and build, unknown power constraints, legacy interfaces)
• Camera based localization, for example, with AWS Rekognition models (requires training at each new deployment, but relatively easy to use with no custom design)
• Bluetooth LE Beacons, the industry standard of doing indoor localization in modern times (well documented and proven, but not the greatest accuracy)

The Who, the person or entity making use of this object:

• NFC (easily available, but short range, bulky and power intensive)
• RFID (easily available, but requires antennas and special physical properties, strength is affected by material)
• Bioacoustics, inspired by a recent Ubicomp research paper from Cheng Zhang, Thad Starner and others: using the human body as a communication channel to propagate information, modulating the frequency so it is unique to each individual.

The How, metadata about usage:

• Collected by our device (power intensive, may be unnecessary depending on object)
• Wired communication, sent by device (sent on per-need basis, advantages of also having other means to supply power for the transmission of extra information)
• Wireless communication with device (power intensive, in most cases, unnecessary)

The Why, to infer intent:

• Our system does not worry about this, because it is very compute intensive and is ideal to be done at the server with machine learning. Not a task for a power-constrained embedded system.

When to Wake up:

• Always on (unnecessary - only last known position is needed)
• Wake up by Bioacoustics (if the user of the system is not Bioacoustics enabled, the state may be lost and objects no longer tracked)
• Wake up by accelerometer (possibly a better solution than the above two, wakes up when an object is moved, even by someone not recognized by the system)

Details will be added once implementation starts.

We plan to implement a voice interface and a Slack based bot as example applications that can answer simple questions like "Where is my ****" or "Who used this **** last?"