Date post: | 01-Feb-2017 |
Category: |
Documents |
Upload: | pedro-jose |
View: | 216 times |
Download: | 1 times |
Demonstration Abstract: A Lightweight, PortableDevice with Integrated USB-Host Support for
Reprogramming Wireless Sensor Nodes
Hugues Smeets, Tim Meurer, Chia-Yen Shih, Pedro Jose MarronNetworked Embedded Systems Group
University of Duisburg-Essen, Germany
Email: {hugues.smeets, tim.meurer, chia-yen.shih, pjmarron}@uni-due.de
Abstract—Node reprogramming serves as an important ser-vice to support post-deployment code management and mainte-nance for unattended wireless sensor networks or autonomousrobotics applications. We present a prototype of a design frame-work called SHAMPU, a Single chip Host for Autonomous MoteProgramming over USB. A SHAMPU device is portable and canbe paired with a sensor node for post-deployment reprogrammingthat is OS independent. Moreover, it is small, lightweight andenergy efficient. In the demo, we will present two scenarios, inwhich SHAMPU-paired Telosbs are integrated with a mobile fly-ing robot and locomotives for local autonomous reprogrammingby the flying robot and for network reprogramming with codedissemination via the data links on the tracks, respectively.
I. INTRODUCTION
Advances in sensing techniques have made rapidly increas-ing applications consider employing wireless sensor nodes andintegrate them into an “Internet of Things” to acquire physicalparameter measurements of real-life environments. In the typ-ical wireless sensor network applications, the deployed nodesare usually unattended and can only be managed remotely viawireless or wired connections. In the robotics applications, onthe other hand, autonomous robots integrate sensors nodes tomake themselves perceptive and “intelligent”. Moreover, in atestbed system [1], sensor nodes (static or mobile) are loadedwith specified programs by different applications to evaluatetheir performance in various scenarios. Node reprogrammingbecomes a common demand when code maintenance andupdates are required or when adjustment to the environmentis necessary during the deployment lifetime.
A sensor node can be programmed using a PC via program-mers (e.g., JTAG programmers) or serial interfaces (e.g., RS-232 or USB) with an on-board boot loader. For remote nodereprogramming, it is often infeasible and impossible to equipsuch PC-associated programming tools with the concerns ofdeployment cost, hardware size, weight, energy consumption(especially when the nodes are powered by batteries) andmobility (in the case of small moving robots). Even with anaffordable embedded PC, e.g., Raspberry Pi, at least 5 Wattsof power is required along with the power supply and cables.Reprogramming over the air is an alternative approach, how-ever it requires an application independent service to handlethe installation of the newly received program code, which istypically stored in an external flash memory (EEPROM). Suchservice is usually supported by the sensor operating system [3],e.g. Deluge [2] on TinyOS.
Fig. 1. SHAMPU-paired Telosbs Integrated with a Flying Robot and a Train
To enable cost efficient and OS independent node repro-gramming, we have developed a prototype of a design frame-work, Single chip Host for Autonomous Mote Programmingover USB (SHAMPU) that is portable and can be pairedwith each sensor node. A SHAMPU device can be flexiblyextended to connect with different wireless (e.g., Bluetoothor ZigBee) or wired (e.g., serial) communication mediumsfor code dissemination. It also offers code storage and man-agement utilities and interacts with the paired node for re-programming. The SHAMPU device is low-cost, lightweight,small and energy efficient. A basic SHAMPU device costsabout 15/10 Euros with/without radio, it weights around 30g.The dimension of the current prototype is 3 × 3 × 10cm3
(compare to 8.5 × 5.6 × 2.1cm3 for the bare Raspberry Piboard), and the final package will be 3×5×1cm3. The currentprototype is built based on PIC24FJ64GB002, which is a 16-bit microcontroller by Microchip Solutions. It has 64 KB ofFlash memory and 8KB of SRAM and we added a 512KBexternal RAM for code storage. This low power chip runs at3.3 Volt (and < 20mA) and it offers an on-board USB 2.0On-The-Go (OTG) controller that can play the role of a USBhost, at up to 12Mbits/s. For the compatibility with the USBvoltage, the chip also provides 5.5V tolerant pins. We havepaired SHAMPU devices with Telosb motes and integratedthem with a flying robot and the locomotives in our TrainSensetestbeds [4] (see Figure 1). In the following sections, we detailthe design of SHAMPU and the demo scenarios for nodereprogramming.
II. THE SHAMPU FRAMEWORK
The SHAMPU framework includes the following modules:
Code Reception To reprogram a node, the new program isdisseminated via wired or wireless mediums. The main taskof this module is to implement the specific protocol (e.g.,
978-1-4799-3146-0/14/$31.00 ©2014 IEEE 333
Bluetooth or RS-232) used by the underlying communicationchannel in order to receive disseminated program code. Wecurrently support three standards: serial, Bluetooth and theMarklin/Motorola I (MM1) associated with S88N (a standardprotocol for digital model trains used on TrainSense). Notethat although SAMPU can be flexibly extended with differentinterfaces, minor additional cost for hardware will be added:5-10 Euros for the Bluetooth module and less than an Eurofor a voltage level converter for the RS-232 connection. Thetotal code size for the PIC controller is below 15KB, whichleaves room to implement other features.
Program Management and Storage Upon receiving dissemi-nated program records, the Code Reception module forwardsthese records to this module (associated with an external RAMof 512KB), which stores the records or the entire programimage depending on how SHAMPU is used. For Bluetooth orRS-232, the records can be programmed directly; for MM1,the program image has to be first stored due to the limitedcapability of the PIC processor to receive/decode an MM1signal and to program over the USB simultaneously. In thecase where SHAMPU holds a whole library of programs, theRAM can be loaded in advance using the serial port (RS-232)or Bluetooth. The RAM is powered by an on-board battery, itscurrent consumption on stand-by is negligible.
Feedback/ACK This module interacts with the disseminatingpeer for the status of reception to ensure that the requiredprogram image is successfully received. It does not involve asignificant amount of software nor hardware. Only the S88Nbus requires a few components for allowing SHAMPU toswitch between drawing two specific amounts of current inorder to send one bit of information as feedback. (Note: S88Nis a synchronous bus and reads all the feedbacks from all themotes in a constant time at 200 microseconds per mote).
Programming Logic: this software module sends the storedbytes in sequence over the USB to the mote in order to makethe MCU of the mote switch into the programming mode.Then the program image can be sent to the MCU over aserial data line to perform reprogramming. If the node failsto be reprogrammed, this module is notified to initiate anotherprogram image transfer until the new image is installed.
USB Host: this module is mostly provided by Microchip andis an event-based generic software system that controls theUSB host hardware interface. Our contribution is to add thespecific support for the FTDI chip (the UART-USB converter),which is not available in the Microchip libraries, on the mote.This development required a substantial amount of reverseengineering while programming a mote with the standard toolson a regular PC.
It is worth noting that SHAMPU can not only be used asa programmer but also as a debugger for the paired mote.
III. DEMO
We propose two scenarios to demonstrate the usage ofSHAMPU to support node reprogramming for an autonomousmobile robot and deployed sensor networks, respectively. Inthe first scenario, a SHAMPU-paired mote is integrated withthe flying robot, Parrot AR.Drone 2.0 [5] (as shown previ-ously), which autonomously performs different remote sensing
Fig. 2. Overview of the SHAMPU Framework
Fig. 3. Reprogramming SHAMPU-Paired Mobile Nodes in TrainSense
operations at different locations. The SHAMPU device is pre-loaded with several programs for various sensing tasks. Codeswitching is triggered by the Drone when it reaches anotherdesignated location for a different sensing task. The Drone theninteracts with the SHAMPU device to reprogram the pairedmote with the target sensing program. In the second scenario,we show three locomotives, each of which is integrated withits SHAMPU-paired mote and is deployed on the tracks ofour TrainSense testbed running the same installed program forthe experiments. Then the new program is disseminated by thePC via the data link on the tracks to reprogram the deployedmotes in parallel. Figure 3 illustrates this scenario setting ofthe SHAMPU integrated TrainSense testbed.
REFERENCES
[1] Handziski, Vlado and Kpke, Andreas and Willig, Andreas and Wolisz,Adam. TWIST: a scalable and reconfigurable testbed for wireless indoorexperiments with sensor networks. In proceeding of REALMAN 2006
[2] Jonathan W. Hui and David Culler. 2004. The dynamic behavior of adata dissemination protocol for network programming at scale. In Pro-ceedings of the 2nd international conference on Embedded networkedsensor systems (SenSys ’04)
[3] Qiang Wang; Yaoyao Zhu; Liang Cheng, Reprogramming wirelesssensor networks: challenges and approaches. Network, IEEE , vol.20,no.3, pp.48,55, May-June 2006
[4] Hugues Smeets, Chia-Yen Shih, Marco Zuniga, Tobias Hagemeier andPedro Jose Marron, TrainSense: A Novel Infrastructure to SupportMobility in Wireless Sensor Networks., in the Proceedings of 10thEuropean Conference on Wireless Sensor Networks (EWSN’ 13)
[5] Parrot AR.Drone 2.0, http://ardrone2.parrot.com
334