The past Storm and Firestorm projects explored how best to construct a low power 32-bit mote (i.e., low-power wireless embedded networked sensor) that could simultaneously handle complex tasks, but operate at extremely low power. The Hamilton project explores a third dimension in the design space: cost. Can you make a 32-bit mote suitable for applications such as building monitoring, with several years of battery lifetime, at a price point that makes the technology relevant? Furthermore, can the ancilliary technologies be cheap enough that the total cost of a securely deployed mote, including labor and maintenance, is reasonable? Under the DOE-sponsored Hamilton project, we have developed a $10 mote and are exploring technologies for secure and manageable large-scale deployments of wireless sensors in buildings.
System Architecture Directions for Post-SoC/32-bit Networked Sensors.
Hyung-Sin Kim, Michael P Andersen, Kaifei Chen, Sam Kumar, William J. Zhao, Kevin Ma, and David E. Culler.
16th ACM International Conference on Embedded Networked Sensor Systems (SenSys 2018).
Demo Abstract: Hamilton - A Cost-Effective, Low Power Networked Sensor for Indoor Environment Monitoring.
Michael P Andersen, Hyung-Sin Kim, and David E. Culler.
4th ACM International Conference on Systems for Energy-Efficient Built Environments (BuildSys 2017).
The "core" refers to processing, storage, and communication hardware—the bare minimum components for an embedded networked device. From our experiences with the Storm project, we noticed that the cost of manufacturing was, counterintuitively, dominated by the cost of assembly rather than the cost of materials. With this in mind, we designed the Hamilton core to make assembly inexpesive. This led us to make use of emerging System-on-Chip (SoC) technologies, which integrate traditionally separate hardware components into a single IC, reducing the number of components that must be assembled in the final PCB. Specifically, Hamilton uses the Atmel SAMR21 SoC, which combines a 32-bit Cortex M0+ processor, an AT86RF233 radio (for BLE or IEEE 802.15.4), and a serial flash module. Using this technique, we reduce the total cost of manufacture—including both materials and assembly—to under $10.
Traditionally, motes have taken "physical approach" to modularity. To extend the functionality of a device, one would traditionally attach one or more "daughter boards" (e.g., Arduino shields). To simplify the hardware design and reduce costs, Hamilton opts for a different approach. Instead of designing the Hamilton core so that daughter boards can be attached, we designed it as a composable module at the PCB design level. This allows more complex features to be built into a Hamilton-based platform when its PCB is design. The Hamilton core, then, can be viewed as a drop-in module in the design of networked sensors, that provides a consistent software ABI and programming environment.
Our hardware designs of boards including the Hamilton core are open-source and available on GitHub.
Traditionally, operating systems designed for low-power embedded networked sensors, such as TinyOS and Contiki, are structured differently from normal operating systems. Citing CPU constraints and the need for determinism on embedded platforms, these operating systems do not support threads, the standard unit of concurrency in most operating systems. Instead, they structure the entire operating system as an event loop that processes tasks serially, a technique called "event-driven execution". In addition, they may provide utilities, built on top of this event-driven core, that give the illusion of threads.
We observe that the processing capabilities of embedded networked devices have grown enormously over the past decade-and-a-half, since these operating systems were introduced. For Hamilton, we explore using "true" threads—preemptively scheduled, independently managed sequences of execution scheduled by the operating system—in the context of low-power, unattended, embedded operation. To that end, we use RIOT OS, as opposed to one of the established embedded operating systems. We have ported RIOT OS to the Hamilton platform, and are investigating whether the additional flexibility afforded by preemptive multithreading can be used to achieve more efficient operation in the context of CPU-heavy operations such as compression, cryptography, and throughput-bound packet processing.
To enable ultra low-power operation and achieve a long battery lifetime, Hamilton, like other low-power motes that came before it, supports low-power wireless technologies such as IEEE 802.15.4, as opposed to more conventional wireless technologies like WiFi. A useful paradigm in this space is that of a "mesh network." Sensors periodically communicate with each other to determine their topology, and automatically compute routes based on that topology. This allows the structure of the network to adapt as the topology changes (e.g., if motes are moved around). Furthermore, deployment of sensors is very simple in this paradigm. One simply places motes throughout a building, and as long as they are distributed densely enough, they will automatically form a wireless mesh network allowing sensor readings to be collected and sent over the network.
The standard protocol for forming such mesh networks is the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL). Although RPL was standardized by the IETF in 2012, complete implementations of RPL do not exist for embedded operating systems, and RPL has not seen wide adoption. We use Hamilton to investigate Thread as an alternative to RPL in the context of low-power embedded wireless networking. Our software stack for Hamilton includes OpenThread, a complete open-source implementation of Thread, ported to work with RIOT OS on Hamilton. In the course of our studies and deployments, we hope to understand the pros and cons of the designs of RPL and Thread, to further the understanding of mesh networks for low-power embedded devices.
We investigate the question: how does one take a complex embedded device, running a full Linux stack, that requires storing some mutable state and make it completely fail-proof, despite being unplugged and moved arbitrarily and left unattended for years at a time? We have developed a software distribution for the Raspberry Pi that leverages in-memory overlay filesystems to allow a dynamic software stack that is immune to filesystem corruption, and can recover from most common failure modes. This, combined with a radio adapter, is used as the border router in the Hamilton project.