Channels ▼
RSS

Mobile

Hacking for Fun: Programming a Wearable Android Device


If you had the chance to watch (or were even one of the lucky attendees at) the Google I/O 2012 opening keynote, you may recall the exciting moment when Sergey Brin proclaimed the arrival of the Google Glass prototypes to the attendees. Alas, Glass prototype pre-orders cost a cool $1,500 for some future delivery date. This led many developers, including me, to reassess their desire to build an Android-centric, HUD-based application.

But for the astute developers attending the remainder of the conference or watching the real-time streams of the various sessions, all was not entirely lost. Of the announcements being made, one company offered developers a competitively priced Android-based heads-up display (HUD) system that was ready and open for business. Canadian-based Recon Instruments created the first release of their MOD Live system to be predominantly used by high-tech skiers and snowboarding enthusiasts.

Recon Instruments was co-founded in 2008 by four students at the University of British Columbia. One of those students is the company's CEO, Dan Eisenhardt. Being a competitive swimmer, his initial plan was to develop a HUD for swimmers. However, due to the complexities and potential damage of electronic components in water, he refocused the company's efforts on snow sports instead.


Figure 1: MODLive Bluetooth Low Energy (BLE) remote.

By tucking their 428x240 pixel WQVGA heads-up display in the lower right corner of ski goggles, Recon has effectively created an unobtrusive HUD with a decent 600 MHz ARM Cortex A8 processor running Android 2.3.3 (Gingerbread). Network connections can be made via a Bluetooth-paired Android smartphone running Recon's MOD Live application. The app also provides the ability to answer phone calls, receive and read SMS messages, control audio playback, and map and store GPS coordinates for ski run playback and review.


Figure 2: Inside the MODLive Goggles with the Heads-Up Display (HUD) in the lower right corner.

MOD Live's interface is manipulated via a 4-way directional wireless Bluetooth Low Energy (BLE) remote. This remote can be strapped on like a wrist watch, and is water resistant to withstand being wrapped around the outside sleeve of a ski jacket. The BLE remote houses the temperature sensor, and the control buttons are easy enough to find and press even while wearing thick gloves. In general, the whole system is intended to withstand a rugged, snowy outdoor excursion. And yet, because it can have its processor housing and LCD display inconspicuously seated in Recon-ready snow goggles like the Briko Veloce, developers can obtain MOD Live today and immediately start building the HUD apps of their dreams.


Figure 3: A close-up of the Recon Instruments MODLive water resistant remote.

Note that MOD Live isn't intended to replicate the Google Glass experience. Unlike Glass, MOD Live does not sport an integrated webcam (though a Contour+ Bluetooth video streaming camera can be added if you're willing to spend an additional $500 for the privilege). It also doesn't have any on-board audio device and instead relies on a paired Bluetooth phone for controlled audio output. MOD Live also does not have any WiFi or cellular radios on board. Instead, network connections need to proxy through a Bluetooth connection and rely upon the paired Android smartphone to perform network handshakes and data retrieval.

Given its small, lightweight size and the unlikely scenario of a WiFi access point in range of a swiftly moving outdoor snow sport enthusiast, these restrictions are understandable. Still, after reviewing the Android-based WIMM One watch and witnessing how power-efficient the WiFi chip was in that small wearable product, the addition of such a radio in the MOD Live would have certainly made developing apps for the MOD Live platform a little easier.


Figure 4: A view of the MODLive Dashboard icon.

Developing a MOD Live App

After getting acquainted with the MOD Live hardware, I started dreaming up useful applications that would effectively leverage the platform while utilizing the variety of functions available in the MOD Live SDK. While the primary use case for the device is intended for snow sports requiring goggles, I thought about an app that could be used in skiing, snowboarding, motocross, snowmobiling, and other long-distance outdoor events that make wearing goggles nearly mandatory.

Having recalled a time when I unknowingly ventured out into the snow shortly before the onset of a blizzard, I would have greatly benefited from that knowledge with an app telling me that a snowstorm was coming straight for me and would hit in half an hour. Sure, I could repeatedly scrape the national weather forecast website for current conditions, but that would have been expensive in terms of both battery and bandwidth.

Fortunately, iOS app developer The Dark Sky Company has already done all the hard work of weather data collection and statistical analysis and packaged it in a tidy JSON-based Web service. Their app for iOS, called "Dark Sky," uses this SDK and it works surprisingly well. I have been using it for months, and it still amazes me how uncannily accurate it has been in predicting when rainfall will start and stop in my area within minutes of the real-world event.

The developers of Dark Sky offer free API keys to interested developers for testing and development purposes. Of course, the hope is that you will incorporate their Web service into your app and ultimately offer a percentage of your apps sales as a result. But in the meantime, all you need to do to obtain an API key is visit their developer site and submit your name, email address, and account password so they can send you an API key. You can revoke and request new keys at any time by logging in with your Dark Sky account credentials.

Coding the App

Similar to my experiences developing for other Android embedded hardware like the WIMM One watch or the Parrot Asteroid car radio, I had to recalibrate my application expectations when writing an Android application for the MOD Live platform.

I first had to create a Android Virtual Device (AVD) that matched MOD Live's 428x240 pixel context. Recon Instruments notes that a MOD Live emulator is one of the SDK items on their to-do list, but for now, Android developers will need to either attempt to simulate the MOD Live display via a custom AVD or push and debug the app on to the MOD Live hardware itself.


Figure 5: Coding the MODLive Dark Sky API assisted application.

In addition to limited network connectivity, power and storage constraints, Recon Instruments have extended the Android UI classes to account for the small viewing surface of the HUD. Fortunately, these custom classes go a long way toward improving the user experience, especially when it comes to reading numerical values. In my case, I needed to convey the probability of adverse weather conditions within a 60 minute timeframe based on the MOD Live's GPS latitude and longitude coordinates.

The Dark Sky API also supplies several other values, including current temperature, weather conditions (clear, rain, sleet, snow), a concise 24-hour forecast, and a stream of probabilities of inclement weather occurring over the next couple hours. Since the MOD Live BLE remote has a temperature sensor embedded in it, I opted to use that data source rather than the value being supplied by Dark Sky. I also narrowed the forecast results to the next hour, since that would be most appropriate for those already outdoors and on the slopes or race circuit to determine if they have enough time to get that last run in before bad weather hits.

After studying the nicely documented sample Recon SDK Application, I sketched the layout of the single screen UI of the program. Next, I launched Eclipse and created a new Android 2.3.3 (Gingerbread API Level 9) application. Then, in addition to the usual Android app, content, OS, and widget libraries, I imported Recon's SDK and custom Web API libraries:

import com.reconinstruments.ReconSDK.*;
import com.reconinstruments.webapi.SDKWebService;
import com.reconinstruments.webapi.SDKWebService.ResponseListener;
import com.reconinstruments.webapi.WebRequestMessage.WebMethod;
import com.reconinstruments.webapi.WebRequestMessage.WebRequestBundle;

The first call I made to the ReconSDK was to poll the remote's on-board temperature sensor from the SDK's onReceiveCompleted event. Being in the U.S., where we have to be different from the rest of the world that uses the Celsius scale for temperature, I had to convert the value to Fahrenheit for the display value:

public void onReceiveCompleted(int status, ReconDataResult result)
{
	// check status first
  	if (status != ReconSDKManager.STATUS_OK)
  	{
Toast toast = Toast.makeText(this, 
     "Communication Failure with Transcend Service",    
     Toast.LENGTH_LONG);
  		toast.show();
  		return;
  	}
  		
  	// Grab on-board temperature sensor reading and convert to Fahrenheit
  	ReconTemperature temp = (ReconTemperature)result.arrItems.get(0);
  	the_current_temp = String.format(" %.2f", (temp.GetTemperature() * 1.8) + 32 );
  	mCurrentTemp.setText("Currently: " + the_current_temp + "F");
}

I also needed to capture the current latitude and longitude GPS coordinates from the MOD Live wrist remote so I could pass these values to the Dark Sky API for the current weather forecast information:

LocationManager locationManager;
String context = Context.LOCATION_SERVICE;
locationManager = (LocationManager)getSystemService(context); 

Criteria mycriteria = new Criteria(); 
mycriteria.setAccuracy(Criteria.ACCURACY_FINE); 
mycriteria.setAltitudeRequired(false); 
mycriteria.setBearingRequired(false); 
mycriteria.setCostAllowed(true); 
mycriteria.setPowerRequirement(Criteria.POWER_LOW); 
String provider = locationManager.getBestProvider(mycriteria, true); 

Location location = locationManager.getLastKnownLocation(provider); 
updateWithNewLocation(location); 
locationManager.requestLocationUpdates(provider, 1000, 0, locationListener); 


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video