A component based, client-server navigation system, based on standard hardware and software technologies

Keywords: Navigation, GNSS, Client-Server, LBS

Tobias Dahinden
Institute of Cartography, ETH Zurich
Switzerland
dahinden@carto.net
http://www.karto.ethz.ch/dahinden/gps/

Biography

PhD student, Institute of Cartography - ETH Zurich Tobias Dahinden (b. 1973) studied geodesy. Currently he's a PHD student at the Institute of Cartography of the Swiss Federal Institute of Technology. He is working with SVG since spring 2000. He was part of the organization committee of the 1st SVGopen conference. He coaches students in works concerning SVG.

Andrea Terribilini
Institute of Cartography, ETH Zurich
Switzerland


Abstract


In this article we describe a client-server system. The system is able to read position data from a receiver. The Data are transformed to a 2D coordinate system, converted to an XML-String and send to a client per TCP (HTTP/UDP).

The advantage of the system is its modularity. It can adapt very fast new Hardware or receiver technologies. Data are send as system independent XML-String via the Internet. It is possible to use a normal web browser as client as well as a special navigation client that is able to show SVG.


Table of Contents


1. Introduction
     1.1 Target of the project
2. The components of the server
3. Different clients
     3.1 Web browser
     3.2 The Demo-Client
     3.3 The Navigation-Client
         3.3.1 SVG as format for the viewer
         3.3.2 A Personal Java SVG-Viewer
         3.3.3 Different possibilities for navigation
4. Test implementation
5. Conclusion, limitations and improvements
6. Bibliography

1. Introduction

Navigation systems are part of our daily live. A lot of money is invested in systems to survey fleets of vehicles. The Swiss Federal Institute of Technology (SFIT) developed a system that is able to read data from an arbitrary receiver and send it per Internet to a client. The development was done as a part of a Project of the European Community.

1.1 Target of the project

The project had several targets:

  • 2. The components of the server

    The main component of the server is an interface with the name "ServerReceiver". This class is able to respond to HTTP or UDP requests. To generate an answer the class has to read a so called "Inputstream". To do this the class uses another class named "InputStream" as interface to access the serial port. The class "SerialPort" can read data from the serial port. But for this it uses a device dependent routine. With this routine the data from the receiver can be send to the main class.

    After that, the main class can interpret the data with a class "Protocol" and "Message". Depending on the receiver used the protocol related to this receiver has to be used. For a GPS receiver the protocol is called NMEA. We implemented the class "Message" in that way that the coordinates that are in a receiver dependent system (e.g. WGS84 for GPS) are transformed to another coordinate system. The advantage of this is that the client doesn't need to know which system is used on the receiver. The disadvantage is that it is only possible to get data in coordinate systems that are known by the server. The client has to tell the server which coordinate system should be used for the position data.

    If possible the server was programmed in Java an it can be interpreted with every Java Virtual Machine (JVM) that supports Java 1.1 or Personal Java. Yet the access to the serial port is device dependent, thus it was programmed in C. This part of the program has to be compiled for each device that should be supported. This is a blemish of this system.

    Figure Figure 1 shows the classes of the server in detail. Each class was build for itself and they are stored for them self in a JAR archive. Thus it's very easy to exchange a class with an extended class for another device.

    server.jpg

    Figure 1: The UML representation of the Server

    3. Different clients

    3.1 Web browser

    Because the server is able to response to HTTP requests, it is possible to access the server with an ordinary web browser. The address for a request is:

  • where MyServer is the IP address of the server. MyServerPort is set in the start file of the server. (As standard port we used port 4444. Normally this port is used by programs such as "kbr524" or "nv-video". If this programs are used on the server-side system, the port for the server has to be changed.) MyProjection is the projection system in which the data should be delivered to the client. The projection has to be implemented in the server.

    Figure Figure 3 shows a request via web browser to the server. The response is an XML-String, and all string is shown. But if the browser is able to interpret XML the answer looks like Figure Figure 4 . Old browsers are not able to interpret the XML-String. In newer browsers there is normally an option where one can select wheatear the XML-String should be interpreted or not.\par The XML-String is independent of the projection system. Further the String can include several additional informations from the receiver or the navigation system (such as the DOP or the number of satellites for GNSS).

    3.2 The Demo-Client

    It is not always recommended to read directly an XML-String. Thus we implemented a Java client that sends requests to a server after a regular time delay. The clients interprets the XML-String and shows a couple of numbers as result. This client was mainly build for test purposes.

    We programmed the client in that way that it runs with JVM 1.1. or Personal Java. the port number, a message, the projection and the IP address of the server can be set in a graphical user interface (GUI). Figure Figure 2 shows the client before starting the connection to the server, Figure Figure 2 shows it while receiving data. The relation between the rows are depending on the XML-String. If another receiver is accessed other informations are displayed on the client.

    democlient.jpg

    Figure 2: Demo-Client

    3.3 The Navigation-Client

    Coordinates in a numeric form, as they are shown on the Demo-Client, are not easy usable if the target is to find a certain position. Thus we implemented a client which shows the position as a point on a map. A target for this client was also that it is device independent.

    3.3.1 SVG as format for the viewer

    o show a position on a (screen-)map the map has to be stored in some way and it has to be shown in a viewer. For storing and showing the map we had the following requirements:

  • Item one indicates that maps should be stored in a vector format. But there are only two common vector formats in the web: a proprietary product of Macromedia called Flash and the W3C standard SVG (Scalable Vector Graphics). Flash was not in the scope of our project because it is not open. SVG has the advantage that it is an XML dialect and the XML-String can be integrated in the graphic in a very efficient way. Further the specification of SVG allows to integrate raster images such as PNG, JPG and GIF in the graphic.

    3.3.2 A Personal Java SVG-Viewer

    When we developed the program there was no open source SVG-Viewer that was running with JVM 1.1 or Personal Java. I.e. we had to write our own viewer for our project otherwise it would not be possible to support any PDA as Client. (Meanwhile an open source SVG-Viewer for Personal Java is developed at University of Minho.)

    The coordinates that were send from the server to the client have to be integrated in a map. Thus the map has to be georeferenced. The referencing is made with six parameters. Because several different maps may show the same area the user has the possibility to change the map in a pop-up menu.

    In addition we made a possibility to store a single or several points. It is possible to store additional data related to a point. This is useful for collecting data.

    3.3.3 Different possibilities for navigation

    A map is not always to optimal solution for navigation. So we implemented another possibility for navigating: It is possible to set a target position (coordinates) in the client. The client calculates distance and direction to the target position. A problem is that the direction is given relative to north (Figure Figure 5 ). Yet it's not always obvious where north is. Thus we made a function where an angle between north and the current position of the sun is calculated (Figure Figure 6 ). This option is only reasonable if the sun is shining. For a solution that is running everywhere a compass (e.g. DMC) would help to find the right direction.

    mozilla.jpg

    Figure 3: XML String

    opera.jpg

    Figure 4: Interpreted XML String

    nav1.jpg

    Figure 5: Navigation Client

    nav2.jpg

    Figure 6: Navigation Client with "sun" option

    4. Test implementation

    The server and client were build abstract. After that we made a test implementation for the software with the following hardware and maps:

  • The tests were successful. A difficulty was, as expected, the part of the server that was programmed in C. This part has to be compiled for each kind of processor. For the PDA we had to use cross-compile options. We had also several problems if the server was running on a Linux workstation and a navigation client wanted to access the server. On Windows the server was not running if it was on a remote hard-drive.

    Server and client run on the PDA. The size of server and client are less than 20 KB. Yet the maps use a lot of storage (3 MB) because they are stored as raster image.

    Figure Figure 2 shows a screenshot of a running Demo-Client. Figures Figure 8 and Figure 9 show the Navigation-Client.

    democlient.jpg

    Figure 7: The Democlient in running mode

    navclient.jpg

    Figure 8: The Navigation client

    pda.jpg

    Figure 9: The Navigation-Client on a Sharp Zaurus

    5. Conclusion, limitations and improvements

    The test implementation proved that the system is working. Because the system is abstract it is possible to adapt new hardware or a new receiver technology very fast. A problem is, as already mentioned, the program part in C. Yet the next steps of development could be:

  • 6. Bibliography

  • XHTML rendition created by gcapaper Web Publisher v2.1, © 2001-3 Schema Software Inc.