Enhanced Reality Fieldwork: the Context Aware Archaeological Assistant

Nick Ryan, Jason Pascoe and David Morse

Computing Laboratory, University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, UK

Introduction

The Mobile Computing in a Fieldwork Environment (MCFE) project aims to develop context-aware tools for hand-held computers that will support the authoring, presentation and management of field notes. The project deliverables will be designed to support student fieldwork exercises and our initial targets are fieldwork training in archaeology and the environmental sciences. Despite this specialised orientation, we anticipate that many features of these tools will prove to be equally well suited to use in research data collection in these and other disciplines.

An important theme of the project is 'context awareness', a term that describes the ability of the computer to sense and act upon information about its environment, such as location, time, temperature or user identity. This information can be used not only to tag information as it is collected in the field, but also to enable selective responses such as triggering alarms or retrieving information relevant to the task at hand. Because of the importance of location in fieldwork applications, the hand-held computers used in the project are normally connected to a GPS receiver. Other environmental sensors could, of course, be added if required.

Approaches to the provision of on-line teaching and learning aids have, understandably, concentrated on classroom or laboratory based provision using desktop computers or terminals. Similarly, the concerns of many of those who are addressing the provision of distance learning materials have been focused on replicating or replacing such provision on individual, remote machines. In some cases, the material presented in such learning packages has been used to prepare students for fieldwork by developing skills such as map reading or the recognition of landscape features, flora or fauna (see, for example, earlier reports on the various TLTP projects, including Martlew and Cheetham 1995). There has, however, been less work on the role of portable computers and nomadic computing during the conduct of the fieldwork exercise itself.

Several disciplines have shown a growing interest in "virtual fieldwork laboratories", in some cases using virtual reality techniques to simulate fieldwork experiences (see, for example, Fisher et al. 1997). In contrast to these, our approach can be termed "Enhanced Reality". Here, the real fieldwork experience is enhanced by providing timely and appropriate information that can be tailored to the needs of the individual user.

Simple example applications include data collection forms, the control of sampling during fieldwalking, and locating features on remotely sensed images for a field survey team on the ground. A more complex system might provide a multimedia guide to the archaeological, geological or environmental features of a region. In each case the central requirement is for a continuous knowledge of location that provides a means of tagging collected data as well as a primary route for information retrieval.

The MCFE field notes model

The term 'field notes' is used here to cover a wide range of types of information that might be taken into the field, created or modified in the field, or consulted and analysed after returning from the field. In their simplest form, these notes might be plain text such as instructions to students or recorded descriptions. For many applications the 'notes' will need to be more complex. A typical requirement would be for data entry forms with text boxes, buttons, pick-lists and other interface objects commonly found in familiar graphical user interfaces. In many cases, raster and vector graphics should also be supported so that location maps or images can be included in the notes. At a somewhat more complex level, other possible note types include multimedia presentations and active, or executable, objects such as Java applets.

As with text, the graphics requirements apply to both presentation and authoring of notes. It should, for example, be possible to record sketches and, perhaps, images from a digital camera whilst in the field. Indeed, a field authoring facility is a general requirement for all types of notes. Data entry forms will normally be designed in advance, but few researchers can have escaped the need to modify their forms once data collection is in progress.

Individual notes rarely stand alone; they will often be interrelated and arranged in sequences, hierarchies, or more general networks. Cross-referencing between notes is therefore an essential requirement that can be provided by hypertext-style links. As witnessed by the increasing number of Web oriented submissions to this and other conferences, students and researchers are becoming practised users of the World Wide Web. Web browsers and HTML documents now provide the most widely known and familiar interface for accessing and navigating related information. This in itself is a strong argument for basing the look and feel of MCFE notes on that of WWW documents.

The overall management of collections of field notes is a task better suited to a conventional desktop machine. A 'notes database' will be required to serve as a repository for instructions and field exercises as well as for data collected in the field. This should provide straightforward means of data exchange with other database, GIS and analytical tools. Packages of tasks tailored to suit particular groups of students or research projects will then be selected for downloading to the mobile machines. In a pure research context, these field resources might often include information recorded during previous visits to the field site. On return from the field, exercise results and other recorded data will be uploaded to the desktop system where it will then be available for analysis and re-use.

For longer stays in the field it will be more appropriate to use a laptop as a surrogate for the desktop machine and to provide regular backup facilities for the hand-held devices. In principal, there is no reason to limit the mobile machines to autonomous operation. Given suitable data links, such as a radio modem or GSM mobile phone, forms might be used as remote database access tools or as a remote 'window' on a Geographical Information System hosted on a remote server. Indeed, the possibility arises of using the mobile hand-held computers as nodes in a 'field network', perhaps with a laptop acting as a local 'field server' to provide bulk storage and to buffer communications with the main system back at base.

Stick-e notes

One of the main inspirations behind this project has been Peter Brown's Stick-e note metaphor [Brown 1995]. This defines a means of delivery for context-aware information that is particularly suited to mobile applications. Notes are associated with an environmental context and become active when the user enters that context. They are an electronic equivalent of the 'Post-it' note. Examples of the elements of a stick-e note context include location, states of external sensors or of the computer itself, imaginary companions or temporal events. Thus context is understood to have both physical and logical domains.

Brown has successfully completed a general implementation of stick-e notes. One of its strengths is that it allows authors to produce and publish materials without any need for programming skills. Notes are prepared in SGML form and look similar to WWW pages, but with extra fields specifying context (at some location, during some time-period, etc.). This work, together with a prototype implementation by Jason Pascoe, has provided the initial architectural model for context-aware applications used in the current project (Pascoe 1997). However, we have adopted a different encoding format for our field notes.

Field Notes in HTML

Despite the relative ease with which notes can be prepared in SGML format, we are aware that many of our potential user groups might not be familiar with SGML. Although appropriate editing and viewing tools exist, they are virtually unknown outside of the highly specialised electronic publishing and text processing communities. Even though the two languages are closely related -- HTML is defined in terms of SGML -- we decided to examine the possibility of a mobile context-aware note system based on the now well known format of World Wide Web pages written in HTML.

Current HTML browsers running on desktop machines and extended where necessary by helper applications can support all of the different types of note envisaged above. There are limitations in the current browser implementations for hand-held devices. Most are very basic and do not support many of the more recently developed features of HTML. However, we anticipate rapid developments in this area, at least for the more powerful PDAs such as those running Windows CE or the new generation of Apple MessagePads. In the meantime, several of the less powerful devices should still be able to support simple browsers with limited graphical capabilities.

There are clearly a number of benefits to our project that arise from using HTML as the language for implementing field notes. The most immediately significant are the widespread familiarity with HTML amongst our target user community and a reduced need for software development. Reliance on an existing standard should ease the adoption of unfamiliar tools, and existing authoring programs and browsers can be used wherever possible. A desktop note authoring and editing system was originally seen as a major development effort, one that can be largely avoided by adopting this approach.

Context as metadata

There was, of course, one fundamental problem that needed to be solved if we were to develop an HTML based note system. Brown's SGML form provides special purpose fields to hold the contextual information needed to trigger a note. How could we represent this information in HTML? The solution came from the realisation that there is a close correspondence between context-awareness and resource discovery, and that context can be seen as a form of resource discovery metadata.

Resource discovery is a topic more normally associated with library catalogues and Internet search engines. Users of mobile context-aware applications are also engaging in a resource discovery activity. Firstly, they would register a set of contexts in which they were interested, for example, location and temporal period. This corresponds to the entry of keywords or other terms in a search engine. Then, as they move about their environment, the system tracks their location and retrieves information appropriate to their current location. For example, when returning to the site of a DMV visited the previous summer, one user might apply the following constraints:

        Subject: earthwork, building
        Temporal coverage: medieval
        Created by: Nick Ryan
        Date created: 1996-06-01 ~ 1996-09-30
A similarly equipped companion might apply a different set of constraints:
        Subject: flora, fauna
        Temporal coverage: 1996
        Created by: David Morse
        Date created: 1996-06-01 ~ 1996-09-30
Then, when walking over the same ground, the two users would be presented with quite different sets of notes corresponding to their different interests.

With a conventional search engine, one might restrict the required location to a comparatively large area and the search result might contain a very large number of hits. Alternatively, many separate queries could be submitted, each referencing only a very small area. The context-aware system can be thought of as taking the second approach, but with the repetitive querying being handled automatically.

The huge volume of resources available on the Internet is a major factor in the recent growth in interest in cataloguing and resource discovery metadata. Amongst the more promising of these developments is the Dublin Core. This comprises fifteen basic elements suitable for describing a wide range of resources. Although not intended to be limited to describing Web resources, much of the early work on the Dublin Core has used metadata examples embedded in HTML META tags and there has been agreement on a suitable syntax. We have taken this syntax as a starting point for defining our own set of contextual elements to form an MCFE field note metadata schema that closely follows the pattern of the basic Dublin Core elements. An extended discussion of this aspect of the project and the definition of the MCFE field note metadata elements is available on the project web site.

Prototype applications

In the early stages of the project we have concentrated on evaluating earlier work, gathering requirements, evaluating possible hardware platforms and developing simple prototypes. The requirements gathering stage benefited from collaboration with a number of colleagues in archaeology and other fieldwork oriented disciplines.

During this time we were also able to carry out a field evaluation of a simple stick-e note system developed by Jason Pascoe as part of his doctoral research. This ran on a Hewlett Packard HP200LX, essentially a miniature MS-DOS based computer, and provided much of the basic functionality that we would expect to see in a context-aware system. Starting from this prototype we were able to concentrate rapidly on application requirements. Amongst those identified were a need to handle many types of input, including free text, forms and sketches. Field notes are not always associated with simple point locations; for many applications the ability to record the route taken along a linear earthwork, or the boundary of an enclosure are equally important. Also immediately apparent was a need for a background map on which sketch detail could be superimposed, with the capability of indicating the locations of available notes in the area of interest.

Hardware

In addition to application requirements, this early system also pointed to a number of hardware issues. It became clear that, for many purposes, a keyboard was not the most appropriate input device for use in the field, particularly for graphical input. Indeed, the conventional 'clam shell' design of the HP200LX and similar machines made it difficult to hold in one hand, and it is most easy to operate when seated. Although it was easily pocketable, had a far greater battery life and was far lighter than a laptop computer, it shared several disadvantages with the larger machines.

These considerations led us to an evaluation of hand-held machines capable of pen rather than keyboard input. Although we concluded that the ideal hand-held field computer does not yet exist, at least at an affordable price, the Apple Newton MessagePad and the US Robotics Pilot both offered a reasonable approximation to our requirements. We are continuing to watch the hand-held market with interest, while using both of these machines for application development. Both machines have distinct benefits and disadvantages. The Newton is quite large and relatively heavy, but this is offset by a large clear screen and, in the more recent MP2000 model by a very powerful processor. The Pilot has a very small screen but is also inexpensive, light and able to fit in a shirt pocket.

Apple handwriting recognition has improved significantly in recent years while the Pilot uses the 'Graffiti' method of recognising simplified character shapes. The Graffiti software is also available for the Newton. Both machines also provide straightforward means of recording sketches as graphical shapes.

GPS equipment

Many archaeologists will probably associate the use of GPS with high precision survey work. However, whilst expensive survey quality equipment is appropriate for tasks such as locating grids for excavation or geophysical survey, there are many circumstances in which lower precision is acceptable. Whilst we anticipate applications of context awareness in precision survey applications, the remit of this project is to investigate the use of relatively low-cost devices, so we have chosen two quite different types of 'navigational quality' devices, manufactured by Garmin and Trimble.

The main limitation in the positional accuracy of these devices comes from the deliberate introduction of errors in the satellite signals by the US Department of Defense. This error component, known as Selective Availability, ensures that 95% of computed locations are within 100 metres of the true location. Accuracy can be improved by long term averaging of readings, typically over several hours, or by differential correction using a second receiver at a known location. Averaging methods typically give an accuracy better than 30 metres and differential correction can achieve 10-15 metres, or better. For a basic introduction to GPS, see Trimble 1997, and for detailed coverage of GPS navigation and survey techniques, see Leick 1995.

The Garmin GPS45XL is one of several inexpensive hand-held receivers readily available from marine and outdoor equipment shops. It is capable of tracking up to eight satellites and generates machine-readable output in NMEA form (note 2). This format is intended for communication between marine and aircraft navigation systems, but includes generally useful information such as current time and position.

The precision of these devices is limited by Selective Availability, but they are capable of accepting differential correction input from an RTCM-104 beacon transmitter (RTCM 1994). Most of these beacons are on or near coasts to serve the marine navigation community, and in some countries a fee is charged for their use. Accuracy is typically better than 15 metres, but the added costs of receivers and reception licences would represent a two to three times increase in the cost of our equipment, and add significantly to its bulk.

The Trimble 'SVeeSix-CM3' and 'Lassen-SK8' devices are both bare printed circuit board devices intended for use in a variety of applications including vehicle navigation systems. The cost of the board is similar to that of the complete Garmin hand-held system, and it must be built into a box with an appropriate power supply and interface electronics. Details of the electrical interface can be found on the project web site (note 1).

Command input and data output is in Trimble Serial Interface Protocol (TSIP), a proprietary format employing binary command and report packets. Both accept RTCM-104 correction data input on a second serial port. On the SVeeSix-CM3, the second port is used for input only whereas the Lassen-SK8 outputs NMEA format on this port.

The main benefit gained from using TSIP is in the range of data that it makes available. Access is provided not only to computed position, but also to all satellite data including orbital parameters and the raw 'pseudorange' data from which position can be computed. When this information is recorded, it is possible to apply differential corrections by post-processing techniques. If the corrected locations are required whilst in the field, a second receiver located at a known fixed location at or near the field site can supply the necessary corrections. However, high precision observations are also made at many sites around the world and are readily available via the Internet. In either case the method is not dependent on the availability of differential beacon transmitters.

Software applications

Prototype applications have been developed for both the Newton and Pilot machines. The development of these has been largely independent, but to a common basic specification. This approach has enabled the two developers to concentrate on different aspects of context aware applications, with the intention that the experience gained from the two prototypes can later be combined in a single design for the second generation tools.
Figure 1: Prototype context aware application running on a US Robotics Pilot computer.

The Pilot application builds on the earlier HP200LX software and has been designed to help investigation of note triggering and rapid data entry using simple forms (figure 1). It is particularly suited to recording multiple similar observations at a single point, or whilst walking along a transect. This approach should make it equally suited to a range of tasks from wildlife censuses to archaeological fieldwalking. Notes are stored in a compact internal format on the Pilot and converted to and from HTML when they are exchanged with the desktop machine.

At present, the Pilot application can only be used with the NMEA format navigational messages from the GPS units. This makes it best suited to use as a low-cost device in combination with a simple hand-held device such as the Garmin GPS45. However, accuracy is limited by Selective Availability unless position averaging at a fixed location or a live feed from a differential beacon receiver can be used.

Figure 2: Creating a text note with the Newton field note application.

The main tasks addressed in the Newton prototype are the use of native HTML notes, an active map display, co-ordinate transformation to UTM or Ordnance Survey grid, and improved locational accuracy. The system is currently limited to storing text notes, but these are automatically generated in HTML form, together with all associated metadata (figure 2).

Figure 3:Newton map display showing track, current position (heavy circle) and the location of nearby field notes (diamonds).

Notes and their metadata can be retrieved by clicking on icons displayed on the map, which also indicates the users track and current position (figure 3). The notes are stored using the built-in 'notepad' application and can be edited in this (figure 4), or within the application. For read access, notes can be opened using a shareware HTML browser, Newt's Cape (Weyer 1997) (figure 5).

Figure 4: HTML source for a field note stored in the built-in notepad application on the Newton.
Figure 5: Viewing a field note in the Newt’s Cape HTML browser.

The Newton application has been designed to work with the Trimble GPS units and so can record computed positions as well as the raw 'pseudorange' measurements from each satellite. Although a live differential feed can be used with these units, we can achieve higher accuracy at much lower cost by post-processing the raw measurements.

The next stage of the project

After further development of the prototype software described above, the next steps will involve extensive field trials in a variety of different areas. Members of the project team will be working with colleagues from a range of disciplines to test the prototypes in several graduate training and research situations.

With colleagues in the environmental sciences we will be taking part in graduate training and research programmes including bird censuses on the Isle of Mull and giraffe feeding behaviour in Kenya. Archaeological and historical fieldwork will include taking part in research surveys of a roman town in Andalusia and 17-19th century seasonal pastoral settlements in the mountains of southern Corsica. We also plan to produce several collections of field notes covering the natural and archaeological environment around our base at Canterbury. These and other field trials will be reported at future conferences and interim reports will also appear on the project Web pages.

Following this period of field testing, the second year of the project will concentrate on three main areas:

Conclusions

Context-awareness is a widely applicable concept. Many users of desktop and mobile computer systems are familiar with diary and 'personal organiser' software that is able to provide reminders of meetings and other events through a limited temporal awareness. With a computer that is also able to determine location such systems could be extended to provide only those reminders that are appropriate to a location. For example, a reminder to go to a particular shop or library when the user next visits London.

By generalising this view of context to cover a range of physical and logical attributes of the user's environment, such as particular subjects, authorship of information or temporal coverage, we are able to produce a powerful and flexible platform for field applications. The nature of mobile computing is changing very rapidly. With the increasing capabilities of hand-held computers and the equally rapid development of mobile communications and small, low power consumption GPS units, we anticipate greater integration of these components in mass-produced units. We believe that context awareness can make a significant contribution to the application of such equipment and offer an ideal basis for the development of fieldwork applications.

Acknowledgements

We are indebted to the following for their helpful collaboration and the opportunity to participate in their various fieldwork activities:

References

Brown 1995: P. J. Brown, "The electronic post-it note: a metaphor for mobile computing applications", IEE Colloquium on Mobile Computing and its Applications, 1995.

Fisher et al. 1997:The Virtual Field Course: URL: http://www.geog.le.ac.uk/vfc/

Martlew and Cheetham 1995: R. D. Martlew and P. N. Cheetham, "The development and implementation of a computer-based learning package in archaeology", in J. Huggett and N. S. Ryan (eds.), Computer Applications and Quantitative Methods in Archaeology 1994, BAR International Series 600, Tempvs Reparatvm, Oxford, 1995.

Pascoe 1997: Pascoe, J. "The stick-e note architectecture: extending the interface beyond the user", International Conference on Intelligent User Interfaces, January 6-9, 1997, Orlando, Florida, USA.

RTCM 1994: RTCM Recommended Standards for Differential Navstar GPS Service, Version 2.1, Radio Technical Commission for Maritime Services, Washington, USA.

Trimble 1997: All About GPS, URL: http://www.trimble.com/gps/

Leick 1995: Leick, A. GPS Satellite Surveying, Wiley, New York, USA.

Weyer 1997: Weyer, S., Newt’s Cape web browser: URL: http://members.bellatlantic.net/~sweyer/newton/index.htm

Notes:

  1. "Mobile Computing in a Fieldwork Environment" (MCFE) is a two-year project funded by the JISC Technology Application Program (JTAP), grant number JTAP-3/217. The MCFE project web pages are at http://www.cs.ukc.ac.uk/research/infosys/mobicomp/
  2. The National Maritime Electronics Association home page is at: http://www4.coastalnet.com/nmea/default.html
  3. The Dublin Core Metadata Element Set home page is at http://purl.org/metadata/dublin_core/