Open Data Kit Sensors: A Sensor Integration Framework
for Android at the Application-Level
Waylon Brunette, Rita Sodt, Rohit Chaudhri, Mayank Goel,
Michael Falcone, Jaylen VanOrden, Gaetano Borriello
Department of Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA 98195-2350
{wrb, rsodt, rohitc, mayank, mfalcone, dutchsct, gaetano}@cse.uw.edu}
ABSTRACT
Smartphones can now connect to a variety of external sensors over wired and wireless channels. However, ensuring proper device interaction can be burdensome, especially when a single application needs to integrate with a number of sensors using different communication channels and data formats. This paper presents a framework to simplify the interface between a variety of external sensors and consumer Android devices. The framework simplifies both application and driver development with abstractions that separate responsibilities between the user application, sensor framework, and device driver. These abstractions facilitate a componentized framework that allows developers to focus on writing minimal pieces of sensor-specific code enabling an ecosystem of reusable sensor drivers. The paper explores three alternative architectures for application-level drivers to understand trade-offs in performance, device portability, simplicity, and deployment ease. We explore these tradeoffs in the context of four sensing applications designed to support our work in the developing world. They highlight a range of sensor usage models for our application-level driver framework that vary data types, configuration methods, communication channels, and sampling rates to demonstrate the framework’s effectiveness.
Categories and Subject Descriptors
D.2.11 Software Architectures
General Terms
Design, Experimentation, Performance
Keywords
Mobile computing, drivers, smartphones, ICTD, sensing, Bluetooth, USB, Open Data Kit.
1.INTRODUCTION
Market penetration of smartphones as a computing and communications platform has increased significantly in recent years. Basic feature phones are gradually being replaced by relatively inexpensive smartphones in developing countries. For example, in Kenya the Android based Huawei Ideos is sold for approximately USD 80[27]. Researchers and practitioners in the information and communication technologies for development (ICTD) community are increasingly leveraging smartphones to improve information management in under-resourced environments. Our work is motivated by the platform shift from traditional PCs and standalone sensing appliances to mobile devices (e.g., smartphones, tablets) coupled with cloud services to create mobile information systems. There is an unprecedented opportunity to integrate consumer mobile devices with external sensors enabling the collection of data directly on these devices. However, unlike traditional personal computing devices, the new consumer devices are locked by service providers or manufacturers, and most end-users do not have the administrative rights, technical ability, or organizational capacity to modify or customize the operating system. As a result, relying on conventional in-kernel device driver frameworks to integrate external sensors with consumer smartphones is impractical. Our project explores ways to package software so that non-technical users can access external sensors from a locked mobile device running a stock version of the Android operating system. The framework assumes the consumer device is ‘locked down’ and an end-user only has the skills to install applications from a standard app marketplace such as Google Play (Google’s Android app store).
The ICTD community has begun investigating using phone-based sensing to perform in-situ and remote monitoring [3, 5, 9]. Even though capturing sensor data directly eliminates many of the errors that plague traditional data collection techniques, such as manual form-filling, it is still not widely used in developing regions because of the high level of technical expertise required to develop a mobile sensing application. The technical challenges include managing the details of different physical communication channels, processing sensor-specific data, developing a user interface and designing application control logic. Unfortunately, this level of expertise is usually not readily available in developing regions or even in developed regions on projects undertaken by resource-limited organizations (such as non-profits and community groups). Because of these complications, we hypothesize that including sensors in mobile data collection poses several technical barriers that, if reduced, would enable more applications to leverage sensors for data collection across varied domains. The Open Data Kit (ODK) Sensors framework aims to lower these barriers by simplifying the deployment of smartphone applications that use external sensors. More specifically, the goal of this work is four-fold:
1. Create a modular framework for adding new sensors by abstracting away management of discovery, communication channels, and data buffers. Integrating a new sensor should require adding only its data handling and configuration primitives.
2. Provide a high-degree of isolation between applications and sensor-specific code. Applications should continue to function even if sensor-specific code is buggy or a sensor becomes inoperative.
3. Understand the tradeoffs of several architectural approaches, especially modularity and performance.
4. Facilitate the integration of new sensors into applications by making it possible to download new sensor capabilities from an application market rather than requiring modifications to the OS configuration.
The ODK Sensors framework provides a single sensing interface for both built-in and external sensors. Having a single interface is appropriate for lightly trained technical workers because it hides a large number of the details involved in developing sensing applications. The framework also provides a simple, high- performing, and flexible abstraction on which to develop and deploy user-level device drivers on Android. While a device driver abstraction is a standard concept, the framework includes features that make development of device drivers easier by handling sensor state (e.g., connection, buffered data, threading) and only requiring driver developers to implement sensor-specific commands and data processing. To evaluate and demonstrate the efficacy of the framework we implemented four applications that are exemplars of different classes of sensor data collection. Three of these applications were previously deployed in developing regions and were ported to the framework leading to significant code simplifications. We discuss these applications and how they leverage the ODK Sensors framework in detail in our previous work [4]. Here we use the applications to demonstrate the benefits of the ODK Sensors framework and compare their minimum performance requirements to the framework’s throughput.
This paper examines the architectural implications of three alternative framework architectures that utilize different inter- process communication mechanisms. By comparing peak throughput across the: three framework versions, communication channels, and applications, we show that framework throughput is not the limiting factor of the sensing system. Therefore, our design choices are biased towards making it easier to create mobile sensing applications by focusing on how programming and deployment barriers can be reduced rather than on the relatively small differences in performance.
2.ODK and ODK SENSORS
Open Data Kit (ODK) [11] is a successful suite of mobile tools that exploit the rich interaction and high-performance computing capabilities of smartphones to improve information collection, distribution, and decision-support. ODK focuses on deployment contexts where conventional computing solutions (i.e., informed by concerns of the developed world) are often inappropriate due to constraints such as affordability, infrastructure, institutional capacity, and technical support. ODK Sensors expands ODK by creating a framework to ease the augmentation of a mobile consumer device with sensing capabilities. The ODK Sensors framework supports a variety of external sensors that vary by the type of data they collect, the communication channel over which they interact with the smartphone, and the rate at which they generate data. It provides a unified interface for sensing on Android devices by combining both built-in and external sensors into a single interface. While this design maximizes the variety of sensors available through a uniform interface, the gains in ease of development are more significant for external sensors as more programming is required to interface these as compared to built-in sensors. ODK Sensors focuses on ease-of-use, in general, with a particular focus on appropriateness to our target contexts.
The framework reduces the complexity of building sensor-based mobile applications by providing abstractions that encapsulate communication channels in addition to delineating user- application functionality from sensor communication. The framework has three constituencies: Application Users, Application Developers, and Sensor Driver Developers. A typical Application User is assumed to be the least technically proficient of the three and is only expected to be able to use applications on an Android device. An Application Developer is expected to know how to create new Android applications (design UIs and implement application domain logic), but is not expected to have detailed knowledge of the specifics of sensor control or how the sensors represent and communicate their data. A Sensor Driver Developer is the only constituent expected to understand the low- level protocol used by a specific sensor for configuration and data packaging, but is not expected to deal with communication channel setup or multiplexing. The delineation of application logic from framework logic leads to a clean separation of developer roles and allows an application developer to focus on higher-level application specific concepts while a driver developer focuses on creating sensor-specific drivers.
The goal of the ODK Sensors project is to shift as much responsibility as possible to the framework developers to simplify the creation of sensing application while maintaining a high-level of flexibility for integrating new sensor types. By creating a framework to isolate these three development roles we hope to make it easier to create sensing applications by isolating development tasks that can be fulfilled independently by people with the appropriate levels of technical skill. To encourage new driver development, the framework assumes as much responsibility as possible for aspects common to many sensors, including management of connection state and threads. Additionally, decomposing the system into modules enables more effective testing and code reuse, thereby improving overall system robustness which is particularly important for ICTD deployment settings (since once a system is deployed in remote locations updating it in the field becomes logistically difficult in terms of costs, time, and complexity).
For the framework to successfully enable an ecosystem of external sensors it must be:
1. easy to create sensor drivers, that is, minimizing the knowledge and amount of code required to create a driver,
2. easy to integrate/reuse external sensors in a wide variety of applications,
3. easy to deploy the framework and device drivers, shielding an end user from the technical details of the sensing infrastructure,
4. easy to upgrade the framework and sensor drivers, 5. hard for bad driver code to damage the framework since Sensor Driver Developers may not be expert Android developers,
6. easy for an Application User to discover available sensors through a streamlined user interface, and
7. easy to manage communication channel details such as proper handling of dropped connections.
ODK Sensors attempts to meet all the above requirements by creating an environment of reusable components for the development of mobile sensing applications
3.RELATED WORK
The variety and number of mobile applications has increased due to the popularity of smartphones and app stores. Despite this proliferation, there are still only a limited number of applications that make use of external sensing devices. This is in part due to the programming challenges of implementing communication between smartphones and external sensors and in part due to resource constraints that prevent adoption of these applications in under-resourced environments. This leads to two main areas of research: (1) reducing programming barriers [8, 21] and (2) making mobile sensing applications more efficient [22, 23, 26, 29]. Within these two areas, some related work focuses on on- device sensors, while other work seeks to expand communication to sensors not built into the phone itself. There is also a significant body of research in device driver design that examines tradeoffs of reliability, ease of use, and performance with user-level versus kernel-level drivers or a combination of the two [10, 17, 19, 20, 24, 25].
The concept of user-level drivers (or application-level) is not new; the L3 system incorporated user-level drivers in 1988 [20]. Leslie et al. [19] built user-level device drivers into Linux without significant performance degradation, even for high-bandwidth devices such as Ethernet, by implementing a framework that used shared data structures, batched work, and optimized event notification. Microdrivers [10] developed a program to split existing drivers into kernel-level and user-level parts by leaving critical path code in the kernel (e.g. data handling, I/O) and moving the rest of the driver code to a user-mode process. Similarly, Decaf Drivers [24] implemented ways to convert Linux kernel drivers to Java programs running in user mode. These systems demonstrated good performance, despite not using native kernel drivers. While ODK Sensors was influenced by these projects, it focuses on creating user-level drivers for locked consumer devices running Android. Therefore, unlike these projects we do not alter the kernel to provide the communication link between the OS and the user-level driver. Instead, ODK Sensors’ communication managers run as user-level threads and use Android’s APIs to handle sending and receiving data from the sensor and then forward the bytes to the appropriate device driver for processing.
The migration towards user-level drivers is in part motivated by the desire to make systems more fault tolerant and reliable in the face of driver-error. Maverick [25], a web-based system, provides security by using device drivers and frameworks that run as user- level web applications to support interacting with multiple USB devices. Alternatively, Carburizer [16] detects and tolerates interrupt-related bugs to proactively manage device failures for improved reliability in the presence of faulty devices. Like Maverick, ODK Sensors leverages user-level drivers to provide reliability and security; however, ODK Sensors runs each driver as a separate application causing each driver to be isolated in its own virtual machine.
Other frameworks similar to ODK Sensors have been proposed, but they seek to interface primarily with built-in sensors. Zhuang et al. [29] introduced an adaptive location-sensing framework that improves the energy efficiency of location-based applications through suppression or substitution of location requests from built-in GPS sensors. It seeks to increase energy efficiency of the system, which differs from our goal of lowering programming barriers.
Dandelion [21] supports building applications distributed across a Maemo Linux smartphone and wireless body sensors by providing abstractions that shield application developers from hardware specific code. Dandelion envisions a scenario where sensor vendors provide a runtime to enable a platform-agnostic programming abstraction called a ‘senselet’ written by application developers to run on the sensor itself. The ODK Sensors framework also shields application developers from sensor- specific hardware; however, the framework provides abstractions at a different level as sensor drivers execute on the smartphone and leverage the framework’s communication channel abstractions and sensor state management. The initial processing of sensor data occurs on the Android device in the sensor driver (removing this concern from the scope of application developers), whereas Dandelion requires data processing in the ‘senselet’ on the sensor that must be written by the application developer in this limited sensor environment. Additionally, ODK Sensors does not require sensor vendors to include a runtime enabling the framework to support any standard sensor that communicates via a supported communication channel. The Reflex [22] project (a fork of Dandelion) is a suite of runtime and compilation techniques that conceals the heterogeneous distributed nature of the system and reduces power consumption by offloading data processing to lower-power co-processors. While Reflex focuses on energy efficiency and performance in mobile-sensing applications, ODK Sensors focuses on lowering programming barriers for application developers and supporting different data and application types. The ODK Sensors driver executes within the framework rather than on a separate co-processor. LittleRock [23] and Turducken [26] have similar goals as Reflex, and present other architectures that offload continuous sensor data processing to dedicated low-power processors.
Gadgeteer [28] is a rapid prototyping platform that eases development with embedded hardware devices through the use of modular hardware components and object-oriented programming in C#. While Gadgeteer and ODK Sensors are both focused on making it easier for users to integrate with different external sensors, Gadgeteer achieves this by simplifying how different hardware pieces talk to each other, whereas ODK Sensors aims to make it easy for the mobile application developer to leverage a variety of sensors in their application without significant programming knowledge about the specific sensor.
IOIO [15] is a development board designed to work with Android phones through a USB connection. It abstracts the communication between external hardware and software running on the smartphone, enabling Android applications to directly control hardware attached to the IOIO board. It is different from ODK Sensors because IOIO provides an abstraction to Android applications at the level of I/O pins of the IOIO board
4.FRAMEWORK
The ODK Sensors framework simplifies the development of sensor-based mobile applications by creating a common abstraction point that enables all sensors to be accessed through a unified interface. Creating a single-interface reduces complexity since all external sensors as well as Android’s built-in sensors are exposed through a common interface regardless of the communication medium used. The interface encapsulates communication and delineates user-application code from sensor- specific driver code, freeing application developers from understanding the specifics of the underlying communication between an Android device and an external sensor. From a user’s perspective the overall architecture for ODK Sensors consists of three apps: the User-Application App, the ODK Sensors Framework App, and the Sensor Driver Apps. For the purposes of this paper an Android application (software downloaded from a market) is referred to as an “app”, whereas the word “application” is used to refer to usage/deployment examples. The ODK Sensors Framework App is responsible for managing low-level, channel- specific communications and providing abstractions to isolate sensor driver code.
5. CONCLUSION
The platform shift from traditional PCs to mobile devices with cloud services creates a need and opportunity to integrate these devices (e.g., smartphones, tablets) with external sensors and deploy applications in new settings. To address this, we created an application-level driver framework that enables convenient reuse of sensor-specific code between applications by logically separating the high-level application from the underlying sensor driver. The focus of ODK Sensors is on enabling the integration of data from a variety of sensors over both wired and wireless communication channels. It simplifies application development by creating a single interface that can control virtually any kind of sensor (both external and built-in) and reduces the amount of code needed to access a sensor. Applications that leverage the framework to communicate with external sensors can be implemented in fewer lines of code (Table 8) by removing sensor communication code - on the order of ten fewer Android Java modules (Tables 9 and 10). Additionally, the sensor framework automatically multiplexes the communication channels allowing different types of sensors to be used simultaneously by an application. For example, an application can easily use two USB and three Bluetooth sensors simultaneously to record several phenomena at once. The ODK Sensors framework is designed to flexibly meet any application’s needs regardless of data type, data collection rate and size, sensor configuration requirements, or communication channel.
After testing the three framework implementations, it was clear that performance was not the most important factor to consider when selecting the final design, as most sensing applications sample data at a significantly lower rate than the framework’s maximum throughput. The performance analysis showed that the system bottleneck is the throughput of the Bluetooth and USB communication channels rather than framework throughput. Since the three frameworks performed similarly, other factors were examined before deciding which is optimal. The V2 framework offered the best tradeoff in terms of programming ease, deployment ease, and performance. The separate driver app design makes it easier for end-users to dynamically add new drivers and V2 has better performance than V3. Performance may become more important in the future to accommodate applications that use high bandwidth sensors such as external cameras for medical devices.
This work is part of the larger Open Data Kit [11] project that seeks to develop a modular set of tools to magnify human resources through appropriately designed technology. One of ODK’s strengths is creating information systems that collect a wide variety of data types (e.g., location, images, audio, video, and barcodes) that are difficult to record on paper forms. By lowering the barriers to add external sensing components, we hope to expand mobile data collection applications to include an even richer set of data types. ODK Sensors increases the variation of input data types possible by simplifying access to sensing resources through the creation of a single interface that makes external sensors as easy to integrate as built-in sensors. By creating a framework designed to follow ODK’s modular components philosophy, we aim to expand the tool suite to allow end-users to easily augment their Android device with external sensing options. The component philosophy enables easy reuse of sensor drivers that will hopefully lead to an ecosystem of drivers further promoting the creation of novel mobile sensing applications. Using standard Android app distribution channels (e.g. Google Play) will make it easy for users to download functionality enhancements (application-level device drivers) to their unmodified Android OS. This simple method of deployment will hopefully lead to the creation of new sensing-based mobile data collection applications that improve information services in under-resourced contexts that typically lack a rich technology infrastructure (both physically and in terms of expertise).
Campus gift Assistant based on Android system
Campus gift assistant using the opening of the Android platform, provide a variety of gift’s strategies for the students, make students more handy in their interpersonal relationship,further more ,show you a matter of conscience for him(her).
The basic features include:
1) Dynamic display, such as the popular gift, wonderful messages and so on.
2)the choice of occations ,such as Valentine's day, Christmas, birthday, etc.
3) Gift selection, for greeting cards, delicate gifts, DIY gifts, etc.
4) Scanning bar codes, two-dimensional code to send voice, text, pictures, video, and other blessings.
5) Notepad function, records something has been done or is about to do .
