Ishtar : a flexible and lightweight software for remote data access

Antoine Beyeler† Stephane Magnenat∗ Alexandre Habersaat†

Ecole Polytechnique Federale de Lausanne (EPFL)†Laboratory of Intelligent Systems, Station 11∗Laboratoire de Systemes Robotiques, Station 9

CH-1015 Lausanne, Switzerland

antoine.beyeler@epfl.ch

Abstract

In this paper, we present Ishtar, a lightweight andversatile collection of software for remote data accessand monitoring. The monitoring architecture is cru-cial during the development and experimentation of au-tonomous systems like Micro Air Vehicles. Ishtar com-prises a flexible communication layer that allows enu-meration, inspection and modification of data in the re-mote system. The protocol is designed to be robust tothe data loss and corruption that typically arises withsmall autonomous system, while remaining efficient inits bandwidth use.

In addition to the communication layer, Ishtar offersa flexible graphical software that allows to monitor theremote system, graph and log its data and display themusing a completely customisable cockpit. Emphasis isput on the flexibility to allow Ishtar to be used with arbi-trary platforms and experimental paradigms. The soft-ware is designed to be cross-platform (compatible withWindows, Mac OS and Linux) and cross-architecture (itis compatible with both microcontroller- and embedded-PC-based remote systems). Finally, Ishtar is opensource and can therefore be extended and customisedfreely by the user community.

1 Introduction

The monitoring architecture is crucial during the devel-opment and experimentation of autonomous systems.This is particularly true in the context of micro airvehicles (mav), where the required capabilities of themonitoring architecture usually includes inspection ofinternal variables, modification of flight parameters, andlogging of sensor data. It is also used to remotely controlof the aircraft in case of emergency.

In the context of mavs, weight and power consump-tion requirements lead designers to select communica-tion hardware that only tightly fits the range and band-width specifications. This often translates into commu-

nication links that are not always perfect in terms ofdata integrity and sometimes exhibit data loss and/orcorruption. These limitations call for a communicationlayer that is both immune to data corruption and ableto transmit payload with a minimum of overhead. Thislayer should also be compatible with a wide range ofcommunication hardware to allow flexible adaptation ofthe flying platform to new experiments and missions.

The requirements for flexibility are not limited tocommunication hardware. In order to streamline de-velopment and experimentation, a monitoring systemshould handle a wide range of flying platforms and ex-perimental scenarios. This calls for a generic architec-ture that allows inspection of arbitrary data content,that is compatible with a wide range of underlying hard-ware, and that provides a customisable graphical userinterface (gui).

In this paper, we present Ishtar, a lightweight andversatile collection of software for remote data accessthat addresses the requirements of communication ro-bustness and flexible operations. Ishtar includes a com-munication layer that implements a generic protocolable to handle arbitrary data structures while retain-ing efficient bandwidth use and robustness against dataloss and corruption. This layer exposes an applicationprogramming interface (api) both for the server (i.e. theremote system) and for the client (i.e. the monitoringstation).

On top of the client api, Ishtar offers a flexible gui.This software allows to inspect and plot remote dataand build custom cockpits tailored to arbitrary platformand experimental setup by linking reusable widgets tospecific variables in the remote system.

The next section describes the communication archi-tecture implemented in Ishtar; Section 3 describes thegui layered on top of the communication architecture;and Section 4 presents an application of Ishtar for themonitoring of a lightweight mav.

1.1 Related work

We can classify remote data access software in three cat-egories. The first is ad hoc serialization/deserializationmechanisms developed for a specific platform or exper-imental paradigm, with no attempt at a generic design.While such solution may efficiently solve some problems,they usually do not offer the same level of flexibility asIshtar.

The second encompasses a wide range of solutionsthat are usually referred to as remote method invoca-tion. In this this type of architecture, the remote tar-get is considered as an object with related methods, ina way that is similar to object oriented programminglanguages. This provides a natural way of interactingwith the remote target, but is not always optimal froma bandwidth and latency viewpoint. Indeed, the clientinitiates all the transfers, and it must thus poll the targetfor reading any data; and the request-answer cycle addslatency compared to a model where the target streamsthe data, which is typically desirable for the monitor-ing of mav. Most of these systems are based on corba[8, 1, 7], but some use http [6], and others have devel-oped their own communication layers [2, 5].

A third category takes a data centric approach. Itresembles the previous category, except that communi-cation is seen as explicit data access rather than methodcalls. This allows additional possibilities such as asyn-chronous data transfer [4], or streaming of data from thetarget, as Ishtar is capable.

Many mav-oriented monitoring gui have been de-veloped to complement autopilot systems, for exampleby Procerus Technologies1, Schiebel2 or CDL-Systems3.However, they are all tightly coupled to the correspond-ing autopilot hardware and limit the possibilities for cus-tomisation due to their closed-source nature.

The Paparazzi project4 has similar goals and features,but has the potential for more customisation as it is opensource. However, this solution is also tightly integratedto its autopilot system and does not offer the flexibilityof a generic system like Ishtar.

2 Communication layer

Ishtar include a lightweight communication layer for dy-namically accessing remote data. Its architecture isasymmetric client-server: the servers expose the datathe clients access (Figure 1, e and b).

At the high-level (Figure 1, c and Figure 2), the pro-tocol handles the enumeration of available data, as wellas the reading and writing. Ishtar also allows a clientto request a specified subset of data to be sent at reg-ular intervals. This feature – the snapshot – allows the

1http://www.procerusuav.com/productsGroundControl.php2http://www.schiebel.net/3http://www.cdlsystems.com/index.php/vcs45864http://paparazzi.enac.fr/wiki/index.php

GUI User code on remote system

Client API Server API

Figure 1: The software architecture of Ishtar. The cellswith gray background represent elements that are partof Ishtar. Servers contain the data and clients connectto them.

Hello

Client Server

protocol version

embedded/normal connectionHello

Initia

lizat

ion

Enu

mer

atio

n Enumerate availables variables

Variables listvariables names, size, and types

Write variables contentvariables identifiers and dataW

rite

Rea

d

Read variables contentrequest and variables identifiers

request identifier, variables dataVariables content

Figure 2: The high-level protocol of Ishtar. The arrowsindicate the direction of transmission. Over the arrows,the name of the message is in black and its content ingrey. This figure shows the four phases of the protocol.Any phase can safely arise at any time, and their mes-sages can be interleaved. For each phases, this protocolis safe with respect to packets loss. In the enumerationphases, requests to the server can be resent until an an-swer is received. In the write data phase, if a packetis dropped, the data to write are lost but the protocoldoes not deadlock. In the read data phase, requests havea unique identifier, and corresponding answers includesit. This allows the client to interpret the structure of in-coming data without explicit description in the message.This saves bandwidth while maintaining robustness topackets loss.

2

server to stream data to the client, which is useful in thecontext of telemetry.

To minimise bandwidth use, Ishtar remembers its re-cent data queries by associating each of them with aunique identifier. When data are received, the queryidentifier is transmitted alongside, which allows Ishtarto interpret their structure. As Ishtar remembers allqueries that it has not received data for, this mecha-nism is robust to packet loss.

The data are organised as a set of typed vectorsof fixed size, called variables. This structure is gen-eral enough for most applications while being suffi-ciently simple for low-footprint embedded implementa-tions. Servers indicate the amount, names, and types ofvectors upon connection of a new client.

At the low-level (Figure 1, d), Ishtar provides robust-ness against data corruption by optionally adding check-sums to each packet. This allows recovery of operationseven in cases where arbitrary data loss or corruptioncan happen. To reduce the overhead when using a safetransport layer, such as tcp sockets, this feature is ne-gotiated upon connections and used only if necessary.At the lowest level, Ishtar uses Dashel5, a low-level ab-straction library that allows cross-platform connectionover arbitrary transport link (tcp, serial, etc.).

The standard implementation of Ishtar is in C++(Figure 1, a to e). This implementation is both efficientand readable, and makes use of C++ standard templatelibrary containers. In particular, it is very easy to ex-pose a C++ variable through an Ishtar server, using theserver api (Figure 1, e). Likewise, for its client api (Fig-ure 1, b), Ishtar provides a C++ class that integratesseamlessly with third party user code through inheri-tance. In addition, a compact C implementation of theserver, limited to a single connection, allows the use ofIshtar on embedded platforms, such as microcontroller-based mavs (Figure 1, f).

3 Monitoring interface

Built on its client api, Ishtar includes a monitoring gui.This software has been designed to be adapted to a widerange of platforms and experimental scenarios. Its inter-face6 is organised in several components, as representedin Figure 3. First, the variables exposed by the con-nected server is hierarchically displayed in a list thatallows to read and set the values (Figure 3, a). Eachof these variables can be plotted in real time in one ormore graph windows (Figure 3, b), either against timeor against another variable (e.g. to plot trajectories). Ifthe connected robot is equipped with a positioning sys-tem, it can be displayed on a map (Figure 3, c) that usesimagery automatically downloaded from Google Map7.

5Dashel: http://gna.org/projects/dashel6Demo video available at: http://download.gna.org/ishtar/

vid/demo.avi7Google Map: http://map.google.com

The map also displays navigation waypoints when theyare supported by the connected platform, and allows tomodify their location in real time using drag-and-drop.Finally, the gui can display one or more custom cockpits(Figure 3, d) tailored to the platform and experimentalsetup. These cockpits are built from a collection of userinterface elements called widgets. A configuration filespecifies the layout of the cockpit and the connectionsbetween specific variables in the remote system and thevarious gauges and indicators of the widgets. If required,widgets specific to a new platform can easily be imple-mented and added to the collection.

Finally, Ishtar being open source and based on a richand open gui toolkit8, everyone can extend and adaptit to their particular needs9.

4 Application

We present in this section the application of Ishtar toa mav participating to the EMAV ’08 flight competi-tion. It is based on the Swift II R/C model from MSComposit10. The total weight is about 350 g and thewingspan has been reduced from 82 cm to 75 cm tofit the requirements of the competition. The aircraft isequipped with a dsPIC-based11 autopilot, called Aeropic6 12, developed at the Laboratory of Intelligent Systems,EPFL [3]. The Aeropic board uses for stabilisation andnavigation a GPS, two pressure sensors (airspeed andaltitude), three accelerometers and three gyroscopes.A downward-looking ultra-sonic sensor has also beenadded to the aircraft for low-altitude terrain following,as well as a wireless camera (2.4 Ghz) for vision-basednavigation and target detection. The aircraft communi-cates with the monitoring station with a XBee link (2.4Ghz).

On the monitoring station (see Figure 3), a cockpithas been customised using both generic and custom wid-gets to monitor the different sensors and the decisionsof the navigation algorithm of the aircraft. The primaryflight display provides information about the estimatedangles of the mav, the altitude and the airspeed, andthe autopilot target for these parameters. The autopilotpanel has been created entirely using the available but-tons and spin boxes, each mapped to the correspondingvariable on the mav. Several internal variables of thenavigation algorithm are also displayed for debuggingpurposes. The battery level is shown on a multi-coloredbar and sounds are emitted to warn the operator whenthe voltage reaches a critical value. Three red/greenlights have been mapped to critical variables (corre-sponding to battery level, GPS fix and radio-receiver

8Qt: http://www.trolltech.com9The project is hosted here: http://gna.org/projects/

ishtar/10Swift II: http://www.mscomposit.com/11dsPic: http://www.microchip.com12Aeropic: http://lis.epfl.ch/smavs

3

(a) Variables

(b) Graph (c) Map

(d) Cockpit

Figure 3: Screenshot of the monitoring gui included in Ishtar. Its main components are (a) a list of the variablesavailable on the remote system, (b) real-time plots of arbitrary variables, (c) a map with the mav and navigationwaypoints represented and (d) a completely customisable cockpit to represent and control the mav.

signal strength) and are used during the pre-take-offchecks. Among the widgets that have been specially de-veloped for the mav, the status display shows the stateof the ailerons and the motor power of the platform.

The mav exposes 143 variables through Ishtar. Thesevariables are sensor values, commands, or parametersfor the stabilisation and navigation algorithm. In typicaloperational scenarios, 89 variables are sent in snapshots,at a rate of 10 Hz. These packets are 264-byte long andcontain 15 bytes of overhead (or less than 6%) for dataintegrity and protocol structure. For the uplink, val-ues are sent only occasionally when a button is pressed.In these cases, the relative overhead is much more sig-nificant as the data payload is very small (15 bytes ofoverhead for one or two bytes of payload). However thishappens rarely compared to the rate of snapshot mes-sages.

During a typical 30-minute preparation flight for theEMAV ’08 flight competition, less than 10 packets aretypically dropped due to data loss or corruption, but theconsistency of the communication is never disrupted andthe operations are, in practice, not affected.

5 Conclusion

Ishtar is a generic remote data access solution that issuitable for a wide range of scenarios. We showed witha real example that its capabilities fit well the require-ments for the monitoring of mavs. It also streamlinesthe development process by making no assumption on

the nature of the transport link nor on the internal dataorganisation of the remote system.

Mav monitoring is not the only domain that can ben-efit from such architecture; monitoring of any type ofrobotic system can be implemented using Ishtar. Fur-thermore, the minimal footprint on server allows Ishtarto be used for remote monitoring of arbitrary softwaresystem. For example, we use Ishtar in our laboratoryto dynamically inspect and configure large simulationsrunning on computer clusters.

Acknowledgements

We thank Francesco Mondada, Michael Bonani, andDario Floreano for their support on the original ver-sion of Ishtar. The original version of Ishtar was sup-ported by the Swarm-bots and the ECAgents projects,which are funded by the Future and Emerging Technolo-gies program (IST-FET) of the European Community.The information provided is the sole responsibility ofthe authors and does not reflect the Community’s opin-ion. The Community is not responsible for any use thatmight be made of data appearing in this publication.

References

[1] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku,and Woo-Keun Yoon. Rt-middleware: distributedcomponent middleware for rt (robot technology).

4

In International Conference on Intelligent Robotsand Systems (IROS), pages 3933–3938. IEEE Press,2005.

[2] B. Gerkey, R.T. Vaughan, and A. Howard. Theplayerstage project: Tools for multi-robot and dis-tributed sensor systems. In International Conferenceon Advanced Robotics (ICAR), pages 317–323. IEEEPress, 2003.

[3] S. Leven, J.-C. Zufferey, and D. Floreano. A Simpleand Robust Fixed-Wing Platform for Outdoor Fly-ing Robot Experiments. In International Symposiumon Flying Insects and Robots, pages 69–70, 2007.

[4] Stephane Magnenat, Valentin Longchamp, andFrancesco Mondada. Aseba, an event-based mid-dleware for distributed robot control. In Workshopsand Tutorials CD - IEEE/RSJ 2007 InternationalConference on Intelligent Robots and Systems, 2007.

[5] A. Makarenko, A. Brooks, and T. Kaupp. Orca:Components for robotics. In International Con-ference on Intelligent Robots and Systems (IROS),pages 163–168. IEEE Press, 2006.

[6] Makoto Mizukawa, Hideo Matsuka, ToshihikoKoyama, Toshihiro Inukai, Akio Nodad, HirohisaTezuka, Yasuhiko Noguch, and Nobuyuki Otera.Orin: Open robot interface for the network. In SICE,pages 925–928. IEEE Press, 2002.

[7] H. Utz, S. Sablatnog, S. Enderle, and G. Kraet-zschmar. Miro - middleware for mobile robot ap-plications. Robotics and Automation, IEEE Trans-actions on, 18(4):493–497, Aug 2002.

[8] S. Vinoski. Corba: integrating diverse applica-tions within distributedheterogeneous environments.Communications Magazine, IEEE, 35(2):46–55, Feb1997.

5