Friday, December 22, 2006

Crickets –Our First Experience

I recently bought a copy of the Cricket’s package and tried it out at our local elementary school, Cedar Creek, with the cooperation of the teacher who runs the robotics class. Robolab starts at third grade and really kicks in at the fourth and fifth grade level. My daughter while interested in mathematics is not so interested in Legos. She likes arts and crafts. I chose the Crickets because it combined programming with a crafts approach.

We tried it out on one of the machines in the room with a student that already had done the Robolab work. He was able to pick up the programming almost immediately. The graphical symbols are color coded. Light and sound icons are in blue. Motor icons are in green. Sensor icons are in purple, and so forth. Dataflow icons are in orange. These include functions such as Wait, Wait-until, Repeat, etc. This is where Crickets starts to teach programming concepts. The kids have to think about what they want it to do and then choose the right dataflow icon for their program.

The icons were more than simple blocks but had molded shapes showing how you might stack one icon on another to create a sequence of programmatic steps. You can then run one step or the whole sequence by clicking on it with a “magic wand.” This made debugging easy and the kids found it fun to see something happen immediately.

Probably the most fun came when we reached the “melodies” block which opened up a player piano-like interface that let the kids write their own song by clicking on a grid that played a note at a specific pitch. They then encapsulated the melody into a program from which they could choose the instrument and the tempo of the song. This inspired some creative thinking.

The Crickets came with simple instructions for setup. The biggest mistake we made was not inserting the three AAA batteries required by the “sending” which is the device that communicates between the computer and the Cricket blocks. Once we figure that out, everything worked pretty much as the manual described.

The biggest benefit is that Crickets lends itself to a broader range of craft-like applications. I’m sure my daughter will go further with it than the Lego blocks at her age. Next semester we’re expanding the program to reach out to more students.

Best regards,
Hall T.

Friday, December 15, 2006

Wireless Sensor Network Technologies – Agilla, Deluge, Mate

With continual funding of wireless sensor network research at the university level, a number of tools have surfaced which merit review. In the area of in-network reprogramming, there is Agilla. Agilla is a middleware program that provides a mobile-agent paradigm which allows a node to migrate its code and state across a wireless sensor network. Agilla is based on TinyOS and allows a wireless sensor network to be reprogrammed with a minimal of computational and communication resources. While it’s a university-level research tool, it does start to create a list of functions and features a robust wireless sensor network program should have.

Another key tool is called Deluge which reprograms an entire wireless sensor network by copying a new image into each node’s ROM in an energy/communication efficient way. You can download a copy here.

Boston University came up with an improved version of Deluge which they called NOSY (Network Observation SYstem) which combines Deluge with a variable report rate for adjusting the nodes report rate, remote control so one can program individual nodes, and a watchdog timer for rebooting nodes that haven’t responded within a certain amount of time.

A team at Berkeley came up with an improved cryptography scheme for Deluge. The paper here describes how an “advertisement” message is sent to the network with a hash code that references a second message which also contains a hash code that references the third message, and so on. This way the network can authorize a stream of messages rather than one message at a time.

Mate is a virtual machine designed for sensor networks which uses complex programs in a small amount of code (< 100 bytes). Mate code can be broken up and packetized for distribution throughout the network. It’s a byte code interpreter that encapsulates 24 instructions per packet. Each command is routed to its destination node and processed at the node automatically. Mate uses a stack architecture similar to FORTH which was also a memory efficient structure for handling data and operands. Events fall into three categories: clock timers, message reception, and message send requests. Operands fall into three categories: values, sensor readings, and messages. Future uses of Mate focus on application-specific flavors.

Research into Wireless Sensor Networks reveals a variety of software efforts – some at the node level, and some at the application level, but from this review it’s clear there is a layer of middleware software that will be key to enabling robust applications.

Best regards,
Hall T.

Friday, December 08, 2006

Wireless Sensor Networks at UCLA’s CENS Initiative with Bill Kaiser

I recently had the opportunity to visit Bill Kaiser and the UCLA lab focused on Wireless Sensor Networks. The CENS, Center for Embedded Network Sensing researches emerging technologies for wireless sensor network applications, in particular for environmental monitoring and biomedical.

Their research focuses on
1. Algorithm development & system development
2. Embedded computing
3. Signal processing
4. Control systems

Most wireless sensor network research focuses almost exclusively on conserving battery power and how to trade off performance for power savings. It was refreshing to hear Bill Kaiser’s focus on powered sensors – high performance/high accuracy sensors which use external power for functions such as noise reduction, actuation, and calibration.

He doesn’t ignore power conservation but seeks energy efficiency using energy scheduling and accountability in the network. By making heterogeneous network nodes, one can select the right hardware for an operation. If the application requires a small workload then one can apply a simple sensor with a microcontroller unit. For high workload operations, one should use a high performance CPU. By making more complicated silicon one can save energy usage in a network setting.

Bill calls this the LEAP approach -- diverse sensor systems with fine grained platform instrumentation. They interfaced LabVIEW to LEAP for integrating signal processing, control systems, and embedded network sensing.

The LEAP includes a processor for energy management and accounting in addition to the host processor module. The additional silicon reduces the overall usage of energy. In the last six months they are now creating a new generation of the LEAP system called LEAP2 which seeks platform scalability – the number of current sensors must scale with the platform configuration.

All the hardware and software components are open source and publicly licensed. Their goal is energy profiling for online algorithm refinement. By understanding where the energy is going, they can optimize the network. Their research hopes to answer questions such as how do I change my algorithm to be more energy efficient? Manually, off-line automatic scheduling and compilation, or online adaptation to change task schedule and behavior.

Their current activities including Seismic sensor nodes, Environmental sensor nods, and Marine Systems—new wireless buoys deployed in the Catalina channel.

Bill sees WIFI as a key element in building wireless sensor networks. With a large wireless footprint, anyone can place a node into an area and network it into the system.

Bill’s team is using LabVIEW for developing algorithms and reducing debugging time. LabVIEW opens up the applications for non-engineers to use sensor networks. He and his team will be working on the detailed VI’s this coming year.

Best regards,
Hall T.

Friday, December 01, 2006

Open Source and Virtual Instrumentation

I recently received an email request from a reader who wanted to know more about Open Source tools related to Virtual Instrumentation. I hadn’t looked into Open Source in some time and thought now may be a good time to review it.

One of the tools the reader mentioned is the Freescale Freemaster Tool.
It was initially called PC Master and it’s a GUI which lets the user remotely control an embedded application. It has a web browser interface as well.

LabVIEW itself is not an open source program (you can’t see the code behind the graphical interface), but the concept of open source programming is relevant to its users. Jeffrey Travis outlines the concept in great detail here. In it he first defines the meaning of free software (it’s free to copy and distribute but not necessarily free to use) which he equates with open source. Open source brings benefits to operating systems and languages by making them more understandable because one has access to the source and the ability to change it. LabVIEW users benefit from an Open Source practice by sharing LabVIEW VIs with one another making the modified versions freely available. The original developer may maintain license to the original work, but derivatives are free and freely used.

In researching it further, Open Source material is available in the world of virtual instrumentation. There’s the OpenG group which hosts a number of forums for open source topics related to LabVIEW. Jim Kring is a big proponent of Open Source and runs a blog called Thinking in G. Jeffrey Travis runs the LabVIEW Open Source Tools (L.O.S.T.) site which offers a number of open source programs such as an SQL database access, remote control of a VI over the web, and a LabVIEW to Perl communication program. Sourceforge had a number of Open Source LabVIEW tools including a database builder, an Excel toolkit, and an OpenG toolkit. Sourceforge also has an XML toolkit for LabVIEW which can be downloaded from here.

If you know of any other open source resources please drop me a note.

Best regards,
Hall T.