Developing with ActiveLook: Getting Started !

Here is what you will find on this page :

  • What is ActiveLook: an introduction on the whole concept
  • Getting started: Up to speed on 10 minutes
  • A word on the Certification & promotion plan
  • Designing for ActiveLook: all good practices & requirements
  • Application, memory & firmware management guidelines

Enjoy !

What is Activelook ?

In a word, Activelook is a piece of hardware technology, the ‘optical module’ integrable in cool-looking eyewear. It also is an open protocol, aimed at addressing remote notification displays. It together delivers key information right in the field of vision of the user.


What is it made for ? 

Can you think of an activity that requires real time and “mission critical” information ? Gives not much space for the user to check a smartphone screen while in action ? A need to push some key information without impacting a movement or activity ? Give visual feedback on a physical activity?

Then you are in the right place.

And.. one more thing : 

All Activelook glasses share the same open API interface: your application will be able to connect and display its content on all Activelook certified devices (sport glasses, safety glasses, sports helmets, head-up display modules, goggles, …)

Check here the list of glasses featuring ActiveLook technology.

Walk through the below onboarding guide and get the whole idea about ActiveLook.

How does it work ? more than an architecture: a philosophy.


ActiveLook is minimal. That is the target, that is the challenge. 


Minimal in terms of footprint, size, power consumption. This means:

  • Minimal communication link (Bluetooth low energy), 
  • Limited local memory (say ~1MB per app), 
  • Minimal computing resources (Low power Cortex M0 MCU ).


ActiveLook optical module is everything but smart: *you* will be smart.


It is not a video screen, it is a notification display.


An image displayed in ActiveLook is a combination of :

  • 1) Icons
  • 2) Texts (you decide font & size)
  • 3) Geometrical shapes
  • 4) that’s it.


It is not a  display with a refresh rate (like regular video displays), it is a ‘memory’ display: you can update any pixel or fraction of the display as you would write a byte or page in a memory. What is not modified or erased remains displayed. It therefore is energy efficient for displaying content with little variation.


Addressing an ActiveLook device is done in 2 phases :


Phase 1- Setup: Pre-load your graphical resources on the glasses flash memory (icons, fonts etc.). This is done once for all, the first time your application connects to a given pair of ActiveLook glasses.


Phase 2- Play ! : Send display commands to the glasses to combine text and precharged icons. Note that you are not sending full images ‘live’ to the display, only graphical commands over bluetooth, such as : 

  • [‘display’; ‘this icon number’; ‘here’]
  • [‘write’; ‘this text’; ‘with this font’; ‘there’]


You therefore have to be smart in:

  • Defining & decomposing your UI as a set of graphical elements.
  • Identifying which minimal part of your UI will have to be updated, and when.
  • Minimizing the amount & frequency of display updates (like: refreshing 1/4th of the display every 1 second is a good target !) 


We also have ‘layout’ and ‘pages’ commands for you in order to club your updates into minimal commands.


Next thing for you: have a look at the ActiveLook Application certification plan: this program will grant the license to advertise your ActiveLook compatibility and guarantees your app will fit the ecosystem, and get promoted !


If you get this all, you get most of the idea.

How to start ? Up to speed in 10 minutes.

Register as a developer

First thing first: make sure you register as a developer on ActiveLook website, developper section. 


ActiveLook is young and our firmware will further evolve in the months to come. 


Registering will allow you to access the upcoming glass firmwares a few months before they are deployed in the field. That is a must have to ensure you can update and test your application prior to new FW deployment and align the release of your new application with the one of the latest firmware.


Information on new FW availability as well as access rights to the ‘developing FW’ repository will be provided to all ActiveLook registered developers.

Developing on mobile ?

You are lucky, we have some pre-cooked ressources for you. 

  • An SDK with all functions you need packaged and ready to use: Glass connection and hand checking, graphical ressources upload, sensor interactions & configuration.
  • A demo application featuring most -if not all- the functions in a ready-to-compile project.


Get the Android SDK :


Get the IOs SDK :

  • Install XCode 
  • Access SDK ressources here : https://github.com/ActiveLook/ios-sdk 
  • Run the example project: clone the repo, and open ActiveLookSDK.xcworkspace in XCode.
  • For more details, check the Read.me from our Github page.


Check out the demo application here : 

Developing on something else ? (watch, pod, bike computer, PC, GPS device, industrial equipment, connected toaster or anything..)


You can operate an ActiveLook pair of glasses from any BTLE enabled master device.


The API documentation is here. It leverages on the BTLE communication protocol. Find here the exhaustive list of services, characteristics and commands to operate an ActiveLook pair of glasses


https://github.com/ActiveLook/Activelook-API-Documentation 


Get your development kit !

While your first app is compiling, take 5min to order your development kit. Despite having a Wysiwyg somewhere in our development roadmap, we will always recommend you check your development by connecting to a real pair of glasses. Readability of your AR content needs to be confirmed with a real background.


The Development kit is a real, fully functional pair of ActiveLook glasses. The exact model & design of glass we will send to you will depend on stock & availability. 


You will be able to upload on this development kit the Beta release of each FW in order to develop/test your application a few months before each new FW is released in the field.

Get my app visible, certified & promoted: How to ?


Targeting ActiveLook certification is a great way to ensure that your application or services is successful within the ActiveLook ecosystem. 


Follow this link and get all information you need on our certification program: (link)


Having your app ActiveLook certified will guarantee to gain in visibility, ensure its robustness and a smooth integration in ActiveLook ecosystem.

Development good practices and requirements

Here are the key requirements regarding application and service development, this ensures your application will deliver an exciting experience.

Designing for a ‘Augmented reality’ display

In augmented reality (virtual image projected on top of the user's environment) what is ‘black’ in your image will appear totally transparent. What is brighter will be the most visible. Think of watching the reflection of a television screen into a glass window. 

ActiveLook display is monochrome Yellow. Focussing all the light energy on one single color / wavelength allows a far higher light efficiency and brightness than we would have with a color display. That allows also optimizing the whole optical design (filters, coatings etc) to maximize readability and contrast in daylight, still maintaining a radically low power consumption. 


The display offers 16 greyscales values (16 yellow scales in fact).

What is ‘changing’, what is ‘fixed’ in your UI?

As stated above ActiveLook features a memory display that won’t change if you do not ‘write’ any new content. You need to leverage on this.

As you design it, visualise your interface as a combination of both fixed and ‘changing’ areas. 

  • You will only refresh the data (icons or text) where and when required => avoid using full-page systematic update or any kind of ‘video’ mode.
  • If a subset of your display can be defined by "1 fixed image" + "1 changing text string", then using the ‘Layout’ feature will simplify its management (see below)

General UI design guidelines

ActiveLook® features a micro-projector. Its compact form factor and integration implies optical trade-offs. To limit visible flare or parasitic reflections it is recommended to:

  • Limit the percentage of bright content in the image: Do not display ‘full page’ or ‘photograph’ type of content. Do not display black content on a “white” background, but “white” content on a black background.
  • Limit the use of long lines or geometries that could appear distorted
  • Prefer using the central area of the display and limit content in display corners.
  • Do not touch borders/corners: to keep a ‘floating image’ impression do not materialise the border of the screen.

No video & animation

ActiveLook has been designed as a minimal (or, say, ‘optimal’) system in order to be light, non-intrusive and long lasting. It uses a low throughput BTLE link and small battery (90mAh for 12 to 15hours autonomy)

Both technical constraints make it not the right candidate for displaying video. Loading a single image over BTLE would take several seconds so your video will not be super fluid.


Addressing an ActiveLook device implies *preloading* your graphical icons and images on the memory glasses. That is done once for all the first time your app connects to a new pair of glasses. Then you will send commands to display the icon you like. Doing this, you may manage to build some stylish ‘animated gif’ but consider this as a maximum.

Maximizing glass autonomy

ActiveLook gives 12 to 15h autonomy in continuous display mode.

If you want your application to reach this kind of performance, consider reducing the frequency of graphical updates and leave the system sleep in between your refreshes.


Targeting ~1 update per second, and using pages & layout commands to group your updates will ensure maximization of battery life time.

Also, note that the gesture sensor is consuming half the device power. Disabling the gesture sensor 

Keep it fluid 

The bluetooth link is a tiny link. In order to keep the graphical latency low and smoothen the display updates, ensure you maximize your use of ‘layout’ commands and ‘pages’, rather than sending individual commands for placement of each graphical item (image, text etc.)

Think ‘erasing’

ActiveLook® is a memory display: previous content will remain displayed unless you explicitly overlay new opaque content.

  • Use icons of the same size so that overlaying a new icon will fully erase the previous one (or draw black rectangles before redrawing).
  • Use fixed-size text so that a black rectangle can be displayed to erase it

To clear content, you can:

  • Overlay content of the same size
  • Display a “Black Paint” rectangle of the same size (color 0)
  • Display the same text, at the same place, with “Black Paint”
  • Use ‘Layouts’ (see below) and proceed with each layout display with the layoutClear command of the defined area
  • Erase the whole display with the clear command

Aligning text

Aligning text may be cumbersome. One may use a padding character to shift your text by a fixed number of pixels. The 0xFF value is used as an empty space.

Use a ‘effective display’ area

In order to accommodate the different personal face features to the optical eye box, it is recommended not to use the whole display area and keep "margins" on all sides. 

As done by the ActiveLook application, consider creating a "reserved" area of 30 pixels on either horizontal side and 25 pixels on either vertical sides. This makes an effective useful area of 244 x 206 pixels (See "Adjust screen offset" in the "settings" section and image below)

The shift command (see above) is useful to manage the visual margins.

 

Layouts and Pages

To simplify the use of graphical elements, it is possible to save a list of graphical commands as “layouts”. These layouts are identified by a simple number and allow displaying a value (passed as function's argument) as text or another graphical element (image, circle…).

Pages are defined as a set of layouts to be displayed together on the screen. Usually, a layout is used to display a certain type of information, for instance, the speed or the time. Depending on the application and on user settings different layouts can be displayed with a page.

Keeping your application up to date 

ActiveLook aims at being one unified ecosystem of cross-compatible applications (sources) and devices (displays). 


This is ensured by deploying on all ActiveLook compatible devices (glasses) one unified firmware that ensures a consistent behavior whatever the device brand. ActiveLook firmware will continuously evolve and improve. New firmwares are deployed in the field from 1 to ~4 times per year (see next section for firmware check/update process description).


In order to remain available to the community, your ActiveLook application needs to be maintained aligned to the latest firmware functionality as they deploy. 


It is required to set up a mechanism checking that your application is compatible with the latest FW deployed in the field (using first 2 digits of FW version number). and prompt your user of the need to upgrade their application if a mismatch is detected. 


Ideally, your application can then leverage on latest and new functionalities, and, at minimum, it will ensure your application remains functional in case of FW behavior discontinuity.


Most firmware upgrades will be neutral for API but some upgrades may deprecate or modify some pre-existing functions or behavior. This will induce release of a “major” version. Obviously, we will try to minimise the occurrence of these major releases (you may budget a maximum frequency of once per year). 


Such major releases will be announced 6 months before deployment. Corresponding new FW and SDK will be made available as ‘development’ versions 3 months before firmware field deployment.


Corresponding communication will be circulated to the developer mailing list and will allow all developers to plan for an application adjustment ahead of new FW deployment. 


Exact FW deployment date will be circulated upfront so that you can synchronize your new application deployment. 

Firmware upgrade and anti-fragmentation guidelines

Ensuring that all glasses run the same firmware, is a shared responsibility of all ActiveLook applications. That ensures that the ecosystem will not ‘fragment’, with users facing bugs with app & firmware misaligned versions.


As of now, the glass firmware upgrade itself is solely performed by ‘ActiveLook sports application’, the native ActiveLook companion application developed by Microoled.


ActiveLook applications are requested to systematically check the firmware version when pairing to any glasses. If a FW mismatch is detected, the application should prompt the user for a FW upgrade. 


Here is detailed process: (draft version)

  • Prompt glasses on FW currently loaded on the glasses
  • Prompt ActiveLook FW server on FW currently deployed in the field
  • If server FW is newer than glass FW, 
  • Inform your user on the need to upgrade the FW by connecting his glasses to ActiveLook sports application
  • Invite to install the ActiveLook application and provide a direct link to ActiveLook application (application store page).

Managing memory & resources

As described above, on a first connection to a given pair of glasses, an application needs to pre-load the graphical ressources it will later require in order to operate. 


This set of bitmaps and layouts loading commands is here called the initial ‘configuration’ for your application.


A given pair of glasses can then host configurations (set of graphical ressources) coming from several applications. 


That implies some simple yet clean process to manage resources and memory on board.


From FW rel.4.0 onwards (avail. June 2021) the flash memory is organized using a filesystem: each application is allocated a private configuration directory in which all its resources will be stored.


At first connection to a given pair of glasses, and after the FW version checking (as described in previous section), your application will:

  • Check amount of free flash memory,
  • Create free space as required, by removing the least used configuration,
  • Upload its graphical configuration.


Detailed processes and commands are described in SDK & API documentations.


Note that the default ‘system’ configuration (used by ActiveLook sports application) is ~40kB. The embedded flash offers ~3MB free space. So configuration cleaning is not expected to happen very frequently.

That’s it !

We missed something here ? Anything unclear. Please let us know by filling the ‘tell us’ form (link)


Marc
July 9, 2021

Other News