Home Page Current Projects Embedding Jini Java to native compiler Previous Projects Java Nanokernel Embedded Java Soft-Instructions Java Network Camera Other Info People Publications

JavaCam At UCSC we have been exploring the use of Java in embedded systems. Among other features, Java provides mechanisms for remote execution allowing for dynamic updating and dynamic reconfiguration. All of these use the same underlying mechanism that makes possible Java Applets which are the primary source of attention to Java in the Internet community. Java Applets are programs (technically portions of programs) that are loaded from remote servers onto local machines and then executed inside of a browser that contains the Java Virtual Machine. Java provides mechanisms for the browser to safely execute unknown applets without fear of compromising the security of local machine resources. In the same way that remote Java applets are loaded into a locally executing Java based browser, local program fragments can be loaded into remote systems and executed remotely. These remotely executing program fragments are essentially incorporated into the remotely running Java program. In so doing the remotely running program could be updated with new versions of portions of the program or provided with new capabilities not originally configured into the system. One of our goals is to provide a network sensor that is fully programmable from across the network without ever shutting down the sensor. Our first demonstration of this is a Java enabled network camera. The ``network camera'' is a Connectix Quickcam connected to a single chip NS486 microprocessor from National Semiconductor. The NS486 is running a thin operating system called JN written at UCSC to support the Java Virtual Machine as implemented by Sun in the original JDK1.0. The JavaCam listens on a particular Internet port for requests to upload camera control servlets. A camera control servlet, if authorized, is instantiated with a reference to a camera object which provides access to the physical camera controls and a socket back to the client from whence the servlet was loaded. This is completely analagous to loading applets except that the initiator (the client) sends the servlet to the server whereas with applets, the client requests an applet from the server. Once intantiated and started, the camera control servlet can perform any desired processing of camera data before sending data back to the client. JavaCam servlets could perform novel compression algorithms, return only selected portions of the image, return images periodically, perform local filtering, or collect data on the images and never return any actual image data. One extreme example would be a servlet that only sent a message back to its originating host when the image changed indicating motion. Depending upon the storage capability of the JavaCam, serveral to possibly many simulataneous camera control servlets could be executing simultaneously serving differnt clients with different needs. Alternatively, a Javacam with very limited memory requirements might be written to only allow one camera control and connection at a time with each new camera control replacing the previous one. In this way a physically isolated camera could provide a range of capabilities exceeding its local storage capacity by multiplexing the servlets across time. When it is not being used for development purposes you can access JavaCam using an Applet Camera Controller we developed.