Showcase

The following list shows several platform components and tools we have implemented so far. Keep in mind that some of them are early prototypes or pilot studies.

Uplink Node

Developer: Stefan Kaufmann

The diretto uplink node is the reference implementation for a portable device connecting a DSLR camera to an diretto endpoint by means of Wireless Wide Area Network (WWAN) connectivity, for instance through UMTS or WMNs. Incoming images from the camera can be rotated and resized, if necessary, outfitted with location information gathered through a connected GPS device and uploaded to any diretto server. This reference implementation is not meant to satisfy all requirements one might have, but as an example to what is fundamentally possible.

The core of the system consists of a standard netbook. Our reference design makes use of the MSI Wind U100 model, although using different models with longer battery runtimes is highly recommended. While still needing a way to carry, using a netbook for the reference implementation seemed to be the logical choice due to their relatively low weight and cost, as well as the long battery runtime. To meet the requirements in terms of ruggedness, a special protection frame had to be built. The original plan was to use plastic junction boxes used in domestic electrical wiring, which usually meet IP codes (Protection Codes as specified in IEC 60529) up to –4 or –5. Thus, the netbook would have been protected against water, as was specified in the project requirements. However, junction boxes large enough to accomodate 10 inch netbooks turned out to be made of metal, thus being rather heavy and expensive. Furthermore, we feared the netbook would overheat when confined to a more or less hermetically sealed environment with little additional space. Thus, the decision was made to leave the water protection aspect to the outer enclosing, i.e., the backpack itself, and let the inner protection frame (see Figure 12.5 care only about physical stress such as blows or drops from medium height. Preliminary tests showed that with the netbook placed within the backpack, Central Processing Unit (CPU) loads exceeding 50 %, and the WLAN interface being used continually to up- and download data, CPU temperature rose to about 50° C and stayed there for more than three hours without exceeding the 60° C mark. The protection frame was crafted by the Wissenschaftliche Werkstatt/Feinwerkstatt Uni Ulm (Scientifical Workshop/Precision Workshop) as per rough specifications given by us – unfortunately, the workshop chose to rate the “ruggedness” feature higher than the “portability” aspect. The case is made from steel plates with a piano hinge and air vents (see Figure); the netbook is held in its place by foam material with cutouts for the cabling, air intake and exhaust. With the case being a full metal enclosure, it is also necessary to leave all equipment operating with radio waves – meaning the GPS, WLAN and/or UMTS adapters – outside the inner enclosure. Since those parts are, in contrast to the netbook, relatively inexpensive and not easily prone to mechanical damage, this should not pose any problems. To provide feedback to the user in case of critical errors, loss of GPS information or WWAN connectivity, a regular earplug can be guided out of the backpack to the user.

The client’s software solution consists of three separate components. WWAN connectivity is left to the operating system itself, since almost all operating systems incorporate such a solution in one way or another, with free software being available to improve this functionality, if necessary. Tethered shooting is accomplished through a simple shell script making use of the gphoto2 command. Unfortunately, “real” event-based tethering for all cameras is, as of now, reserved to the domain of commercial, closed-source Windows software. Documentation of the Picture Transfer Protocol (PTP) commands used in the camera manufacturers’ own tethering software is basically non-existent, and the commands are known to change between different camera generations. Thus, implementing tethering support for a wider range of camera brands and models turned out to be a hopeless undertaking. The current approach for cameras not supporting event-based tethering via gphoto2 is crude, but comparatively reliable: The camera is polled every 15 seconds; images are automatically downloaded to the hard drive and erased from the camera’s memory. The client software itself looks for newly created files within one specified directory, i.e., the directory the tethering script is started from. Once a new file is detected, its EXIF information is extracted and a working copy is created in a different directory. If the camera provides orientation information, the incoming image is rotated, if necessary. If specified in the configuration XML file, the image is then resized and uploaded to the diretto servers. Internally, extracting the EXIF information, rotating the images, annotating metadata and uploading the imagery is realized with queues. Upon application start, all serial ports are probed for GPS input. In parallel to all operations, incoming NMEA 0183 sentences are parsed and converted to floating-point latitude and longitude coordinates, along with Dilution of Precision (DOP) values. All incoming imagery is then outfitted with matching coordinates and precision information before further processing.

AnDiretto

Developer: Christian Koch

AnDiretto was implemented as a smartphone client running on the Android platform. It’s main Activity, which means application in the Android context, is a map, showing reported media documents. The map is updated in a constant interval, not using the diretto PubSubHubbub capabilities for performance reasons. Capturing media is supported using the internal capture Activities of Android Devices, currently capturing Photos and Video are implemented. Once media has been captured, the user can tag the documents with keywords. The application tries to estimate the current position of the user, using localization information provided by GPS, WiFi- or GSM-network information, dependent on the settings of the user. The document is then uploaded into diretto together with it’s estimated position and capture time. In case of a successful upload the user is notified in the smartphone’s status bar, if errors occur during transmission the device retries to upload the document in a regular interval.

RichWebClient (v1)

Developers: Achim Strauß, David Langer & Tobias Schlecht

This web application allows browser-based access to the API functionalities and provides a rich user interface that enables an extensive analysis and interpretation of the gathered documents. In this way, the web application itself acts as a client for the diretto platform. The figure shows an example screenshot of the implementation. The rich web application is a Java-based application running inside a Servlet container. The application has been developed using Vaadin, a Java framework for building modern web applications. It internally extends the Google Web Toolkit and allows to develope web applications entirely in Java. The platform hides complexity by compiling Java code partially to HTML, CSS and JavaScript automatically.