ECCSE 2002 Research Experience for Undergraduates (REU) Final Report

Real-time Interactive Visualization of Remote Environmental Monitoring Systems for Researchers and Educators: The EcoViz Project

October, 2002
Vahid Pazirandeh
SDSU NPACI Education Center on Computational Science and Engineering

Goals
(View original REU proposal)

The goal of the EcoViz Project is to develop more affordable and accessible methods of visualizing (in 3D) environmental monitoring data obtained in real-time from remote sensor stations at the Santa Margarita Ecological Reserve. These sensor stations record data such as air temperature, wind speed/direction, precipitation, ground soil heat flux, soil moisture, atmospheric pressure, and transmit it via pc’s connected to a hi-speed wireless research and education network. Features include the user’s ability to view this information at any given point in time, or over a period of time to observe changes represented visually using a range of rendering options including shape, motion, color, or sound.

Results

Phase 1
The initial design was to construct a NeatTools package that would provide a constant flow of real-time data. It was our hope that with minimal configuration, NeatTools could acquire data straight from the same COM port to which the sensor’s micro-datalogger was connected. NeatTools is a program that creates robust network data flows between the various input/output ports on a pc, such as the COM, SCSI, or Parallel ports. If NeatTools could not be configured to acquire data directly from the serial port, we would have secondary option of accessing the data from an external Comma-Separated-Values (CSV) file created by the micro-datalogger, and this was in fact the strategy that was best in order to avoid an extensive development effort writing source code to build a module that would communicate directly with the micro-datalogger. Unfortunately, the NeatTools CSV reader module could only handle 10 channels of data input, so we submitted a request to the NeatTools developers for a modification to this module so that it reads 40 channels in order to accommodate the 38 channels of input saved to the CSV file from the micro-datalogger. While we waited on this upgraded module we proceeded to Phase 2.

Phase 2
Our focus in Phase 2 was the creation of a Java applet to communicate with the NeatTools package via socket communication to obtain the real-time data and visualize it. We began work on a NeatTools module that was needed to be able to communicate with Java in a plain-text protocol. The default socket communication module in NeatTools used a proprietary NeatTools protocol. Coding a Java-based NeatTools protocol class would not have been robust, extensible, or as simple as a plain-text protocol. Thus, the decision was made that a new NeatTools module should be coded which can send and receive data in plain text. Our strategy was to use the "VizClient" module (in C++) that had a workable one-way, plain text communication implemented, as a resource. A Java-based socket server was coded and we were able to communicate with the VizClient in plain text. What we needed next was a Java-based socket client and a NeatTools socket server.

We researched other avenues such as the ability for NeatTools to communicate with its NeatView renderer. NeatView is a 3D visualization program that uses the VRML standard and renders 3D images from NeatTools' input. As mentioned above, this is done with socket communication and the NeatTools VizClient module. In addition, NeatTools developers presented our team with a design to have an embedded web server in the renderer. This allowed us to have client machines with NeatView and a web-browser to submit a form and POST it to their own renderer (an alternative to using Java 3D as described in phase 3 below). Though workable, this was only half of the project: we still needed to retrieve the data from the sensors. Down the line we were informed that a CSV file of all pertinent sensor data was available via FTP access and that it was automatically updated on the server. The file contained an archive of all data the sensors' data. Though we were informed about the file's availability late into the project, but we immediately began development. This led us into our next two phases.

Phase 3
The next design was to use the Comma Separated Value (CSV) file that the sensors logged to, as the source of our data and create a Java 3D applet interface. The design and implementation of how to retrieve the desired data and visualize it while sustaining a smooth 3D animation has been one of our milestones. The ECCSE development team wrote a Java class that parses the recorded data (which is in CSV format) and allows the driver program to retrieve data from a specific date or a period of time (two dates). I wrote three classes to make use of parsing class and visualize it (Figures 1 and 2):

Class 1) DataFeeder which uses Mark's SHDataParser class. This class introduces new data into the animation in real time.
Class 2) an Animation class which constructs all the Java 3D aspects and visualizes the data. This class is typically hacked-up code from the Java 3D examples and is very open to new features such as what shapes/motions/sounds/colors to use so the user can better interpret changes in data.
Class 3) Finally there is a driver class that manages the DataFeeder and the Animation so that as new data is being introduced, the animation does not pause -- seamless data feeding. This managing class can be implemented as an applet and makes the data feeder and the actual Java 3D animation classes into threads. The use of threads is key to disallow pauses in the animation while new data is being introduced, and appletizing allows for a Web interface to the project.

Phase 4
The NeatTools development team finally responded near the end of this project by providing us with a newly developed module to read in Comma Separated Values of up to 40 channels from an external text file, such as those saved by the Santa Margarita Ecological Reserve’s remote sensor stations. With the addition of this module, we were finally able to transmit and visualize, in real-time, data streaming from the remote sensor station on a pc. By merging the NeatView modules already constructed with the CSV modules now available, we were at last able to visualize data in an exploratory abstract manner directly off of the remote sensor station computer (Figures 3 and 4). Even though this visualization was not within a web browser, by making these NeatTools modules available for download via a web browser, our system offers the next best thing. Overall, our progress was insufficient to actually attain one of our goals: to integrate a web-based feature into the NACSE prototype web interface. However, we have performed most of the necessary steps to complete this final step.

Pertinent Resources

REU 2002 Project Web Site: http://www.edcenter.sdsu.edu/projects/reu2002/

This site includes our initial REU 2002 proposal, this final report, the figures below, and zip archives of all of the java 3D code generated for this project.

Downloadable zip archives of pertinent java code:

Data parsing java classes

Java 3D interactive visualization applets

NeatTools web site (downloads, tutorials, etc.)

Figures

Figure 1: Terrain data for the Santa Margarita Reserve (elevation exaggerated). Spatial coordinates of objects such as the red sphere may be controlled by data streaming in from an external CSV file. (click to enlarge)

Figure 2: Rotation rate of cube varies (not apparent in this still image) as a function of data from a single channel of data specified by the user and streaming from an external text file. (click to enlarge)

Figure 3: NeatTools network with the CSV reader modules integrated with the NeatView network. (click to enlarge)

Figure 4: NeatView visualization of remote field station data. 18 separate parameters drive the different visual cues in realtime for this complex 3D object. (click to enlarge)