Roger Meike's Blog: Sun Labs and Beyond

Scratch is a great visual programming environment for kids created by some folks at MIT. Randy has put together a little code to connect Sun SPOTs to Scratch and has released a video (below) to show you how to do it.

Its easy and fun! Try it out!

If you were a high school student on summer vacation before heading to college and you had a little extra time and some Sun SPOTs, what would you do? How about sending a Sun SPOT to near space?

  

The whole project is chronicled here: http://hibal.org/missions/apteryx/

They have made their source code available here: http://kenai.com/projects/hibal-spot

Hmmm.... It reminds me a bit of another project

SPOT Toys

Those of you who know me know that I'm a sucker for new gadgets. There have been a few new Sun SPOT accessories that I think are worth mentioning here.

Breadboard for the Sun SPOT

First from our friends at Circuit Monkey is the breadboard for the Sun SPOT. In a similar vein to the very popular Breakout Board the new breadboard allows you to have direct access to all the signals from the Sun SPOT eDemo board and provides a nice little prototyping area for you to design your own circuit. I think that Circuit Monkey has another hit on their hands with this one. Its on sale right now for under $30, so its reasonably priced as well. I've been playing with one of these for a while and I must say its very flexible and lots of fun. It brings out all the signals from the eDemo board (A0-A3, D0-D4, H0-H3, Vh, SW1, SW2, 3V ref., 5V ref ). It also includes probe hooks on the sides of the board so that you can easily connect a scope. Vcc is brought out on 4 connectors and has an LED to confirm that you are getting external power. Quite convenient and very useful. You can get it and other SPOT accessories from Circuit Monkey site.

Roomba Meet Sun SPOT

For the robot enthusiasts in the crowd, here is a Sun SPOT add-on that you might like. As you know, on several occasions I've mentioned the IARoc competition where students compete to perform tasks using Sun SPOTs and iRobot Creates. The Create is basically a version of the iRobot Roomba but without the vacuum cleaner part. Its a really great robot platform and with a Sun SPOT to control it, it becomes a really fun platform to program as well. The robot simulator in Solarium is based on this combination. The folks who put on the IARoc competition every year, Wintriss Techncial School, have made their interface available for others to use. It does the level shifting for the serial interface between the Create and the Sun SPOT as well as provides an interface to an ultrasonic sensor. You can buy it from their online store.

Technorati Tags: spaughts

An Exercise in Hardware for Software People

A lot of people who use Sun SPOTs are software programmers who are interested in connecting the virtual world of software with the physical world around us. Sun SPOTs are a great platform for this, but often people don't know how to get started. Especially for those of you who have very little experience with hardware, its hard to know where to start. Sun SPOT team member David Simmons has some good "Stupid SPOT tricks" in his blog that help with this. Along those same lines I present here my experiences using Sun SPOTs to help grow tomatoes in hopes that it will give a few software folks the courage to meddle a bit with hardware. You see, we've always had bad luck growing tomatoes, but this year, our plants have been doing much better. Now we are in the tricky time when we need to monitor the water that we feed to the tomatoes to make sure we get the optimal development of fruit. I'd like to use Sun SPOTs to make sure that our watering schedule is appropriate.

Choosing a Sensor

I recently wanted to use Sun SPOTs to monitor our garden. A Sun SPOT with and eDemo board can measure light and temperature which is good, but I was also interested in figuring out whether to not to water the garden. To do this, I needed a moisture sensor that could tell me how wet the soil was. With a little web searching I found the VG400 by Vegetronix. It is fairly inexpensive and seems designed to give me the information I want - soil moisture. The first thing to do when evaluating an external sensor like this is to understand how you interface to it. In this case, the specifications on the web site tell us that it requires 800  at 3-12v to operate and that it produces a 0 - 3v analog voltage that varies with the amount of moisture it senses. We can consult the Sun SPOT Theory of Operation to see if this will work with the eDemo board. On page 20 we can see the the eDemo board is able to supply 3 or 5 volts at 100mA. This means we have more than enough power to provide the VG400 the power that it needs. On the top of page 22 we see that Sun SPOT analog inputs A0-A3 measure the voltage range between 0 and 3V. This is a perfect match for the VG400. Theoretically, we could connect up to 4 moisture sensors with a single eDemo board using A0, A1, A2 and A3.

Vegetronix also has a low power version, the VG400-LV, that uses slightly less power (600 ), but it only puts out 0 - 1.8V. This would also work, with the eDemo board analog inputs, however, it would limit the resolution of our measurement. Here's why. Looking at the equation on page 22 we see:

is 3V on the eDemo board. The values will range from 0 - 1023 because it is a 10-bit analog to digital converter and is 1024. This means that a voltage of 3.0V will produce a value of 1023. A voltage of 0V will produce a value of 0. A voltage of 1.8V will produce a value of 614. So the whole range of dry to wet will be represented by values from 0-1023 on the VG400 and from 0-614 on the VG400-LV. That means the scale of the VG400-LV will be compressed into 614 values instead of 1024. Other than those differences the two sensors will be identical. They will connect to the same inputs on Sun SPOT and generally work the same way.

The probe can be used to measure water level and even water volume. The capacitive principle that the probe is based on changes value as the probe is immersed in water. The further it is immersed, the more it changes. This means you could mount several of these in a tank and, with a little calibration, monitor levels inside the tank. I have done only few tests, but it seems quite viable. In the ground, since the water is suspended in the dirt, the probe measures moisture in the area around the probe. Maybe after tomato season I'll try some more experiments to see what other capabilities this sensor has.

Making the Connection

Armed with this information I placed an order with Vegetronix for the VG400. A few days later an unimposing manilla envelope showed up in the mailbox. Inside was the VG400 sensor, just as promised. The disconcerting part was that there was nothing else in the package. No documentation, no receipt, no nothing. For the novice this could be cause for alarm, but have no fear. Closer examination shows that all the documentation we need is conveniently printed directly on the sensor itself. It says:

RED: +V

BLACK: OUT

BARE: GROUND

This makes connecting easy. We just connect the red wire to the pin labelled +5 along the bottom row. The black wire is connected to pin A0 (the analog input that we will use in our software. It could just as easily be any of the other analog input pins. Finally we connect the bare wire to one of the pins on the right side labelled GND.

That's it! No circuit to design. No resistors, capacitors or transistors. Instead, its just wires connected to the Sun SPOT. I used a pair of pliers to bend the wires and just poked them into the connector on my eDemo board. For my purposes, a short term installation, I don't even worry about soldering the connections. I just plugged the wires in and let it go at that.

Software

Next step is the software. This too proves to be fairly straight forward. I started with the SendDataDemo. We will use two parts of this demo, the onSPOT part that runs on the Sun SPOT device and the GUIonDesktop part that displays a graph of the data received. We will need to change the code a little in the onSPOT side to make read the analog input instead of the light sensor which is what it reads by default. For a quick and dirty check of our hardware, I changed one line. On line 56 of sensorSampler.java it gets the lightSensor:

   IScalarInput lightSensor = EDemoBoard.getInstance().getLightSensor();

Instead we'd like to get the analog input:
   IScalarInput lightSensor = EDemoBoard.getInstance().getScalarInputs()[EDemoBoard.A0];

Please note that this is VERY temporary. I should really rename the variable lightSensor to be a bit more descriptive of its new function, but this is just a test. With just that one line change, we can run that code on the Sun SPOT device and connect a base station and run SendData-GUIonDesktop. We get the following output:
You can see that at first the readings were very low. Then I put the sensor in a glass of water and the reading shot up. After about a minute, I removed the sensor from the water and it dropped back down to the approximately the previous value. It looks like it is working!
From here, you can get as fancy as you want, but first lets review what we have accomplished so far. We've gone from identifying a sensor on the web to connecting it by just connecting 3 wires and then changing one line of code in a demo program.. and now we're looking at graphs of data we collected wirelessly. Not too bad!
Of course, for a more permanent installation, there are other things to think about.
One other consideration of some importance is the item in the specification sheet labelled "Power on to Output stable." This is the amount of time between giving the probe power and the time it has valid output. This time is rated at 400mS. Just to be sure I have the enough time, I wake the Sun SPOT up half a second before I take readings from the probes. The Sun SPOT has a nice feature that it shuts the power off during deep sleep, but keeps it on during shallow sleep. This means that I can wake up, disable deep sleep, then go back to shallow sleep while the probe stabilizes.
   sleepManager.disableDeepSleep (); // Assure that we will be awake to power the moisture sensor
   Utils.sleep (STABILZATION_PERIOD); // give the sensor time to stabilize

then later after taking the readings go into deep sleep

   // Go to sleep to conserve battery
   sleepManager.enableDeepSleep ();
   try {
   sleepManager.ensureDeepSleep((SAMPLE_PERIOD - STABILZATION_PERIOD) - (System.currentTimeMillis() - now));
   } catch( UnableToDeepSleepException ex ){
   ex.printStackTrace();     Utils.sleep((SAMPLE_PERIOD - STABILZATION_PERIOD) - (System.currentTimeMillis() - now));
   }

There are a few things to do to make sure that deep sleep works properly:

• First, make sure that no other applications are running when your application is running. Having multiple threads and isolates is an amazing feature of Sun SPOTs, but if you want to save power you need to keep them under control.

• Second make sure that OTA is turned off.

• Third set the routing policy to ENDNODE so that you don't spend energy routing other node's packets

   RoutingPolicy rp = new RoutingPolicy(RoutingPolicy.ENDNODE);
   RoutingPolicyManager.getInstance().policyHasChanged(rp);
Based on what I've measured so far, when I set the Sun SPOT to report all the values every 5 minutes I get a duty cycle with over 99% deep sleep. Of the 1% that is left, most of that time is in deep sleep. The moisture probes don't use very much power, so I anticipate several months of operation between battery charges.
Installation
The sensor seems to suit my purposes well. It certainly easy to use. I got a second probe so that I can monitor the moisture in two places simultaneously. This was fairly straight forward. I just had to repeat the process I did for the first probe on a second analog input (A1). While I was at it, I modified the application to send light, temperature and battery levels as well as the moisture reading. I've modified the host side of the application to plot all of these values plus write them out as a CSV file to the disk drive.
I put a cable tie around the Sun SPOT device to hold the wires in place. Next I screwed an eSPOT mounting clip to a piece of PVC pipe and clipped the eSPOT in place. I put this on the end of a 6 foot tall piece of pipe stuck in the ground. Next I cut the top off an old Costco ibuprofen container and inverted it over the eSPOT. It is waterproof and translucent enough to be able to get diffused light readings right through the container. In fact, in direct sunlight it is still enough to saturate the light sensor. I buried the moisture sensors a few inches down in the dirt.
Now I have a complete system to monitor light, temperature, and moisture in two locations in the garden. I'm recording data every 5 minutes. Finally I'll be able to collect scientific data about optimal watering schedules. Is it better to have daily short waterings or less frequent deeper waterings? I should be able to find out how long it takes for the soil to return to a baseline condition after watering and from that infer how often I need to water. My goal for now is to keep the soil moisture over multiple days from trending up or down. I want to water enough to keep the over moisture level approximately constant.

Issues and Future Enhancements
The temperature readings are not very accurate. I know that the built-in temperature sensor is really measuring the temperature of the ADC chip, but I've found that if you have applications that sleep a lot and then take the temperature reading immediately after waking from deep sleep, you can get fairly accurate readings (this only works for eSPOTs that are NOT plugged in. In this case I'm actually using the ADC and I'm taking the temperature reading after waiting for half a second to stabilize the probe. I'll have to play around with this to see if I can get more accurate readings.
In the future I hope to be able to send this data to a public server where I can view the data from anywhere and adjust the watering schedule while I'm on the road. I'd also like to be able measure the soil temperature early in the season so that I can tell when its time to plant.
In a future post, I'll make the code available in case anyone else wants to poke around with it a bit more.

Location, Location, Location (Radio)

This post is a follow-on to my previous post about determining location using the accelerometer. That post proved to be quite popular, and at the time I promised to follow up with a post about finding location via the radio. Well that was some time ago, but finally, here's more about location. This time, as promised, we will talk about how to derive location from a radio. Can you tell where a Sun SPOT device is, using its radio? As with the accelerometer, unfortunately, the news isn't very good. Its quite difficult to get an accurate position from the Sun SPOT radio, but we'll talk through some of the techniques used to figure out where you are in radio space. We'll talk quite a bit about radio propagation. We'll toss in a little math, but nothing too complicated I promise. I hope you enjoy it.

Generally, to find a location using the radio, we want to find our position relative to other devices of known location. There are two basic techniques. Either we need to figure out the distance and bearing to another device of known location (a vector), or we need to find the distance to multiple devices and triangulate to infer a location.

Direction and Distance to a Known Location

In the first technique we need three things to establish the location of the Sun SPOT. We must know the 1) Bearing and 2) Distance to a 3) station of known location. In the diagram above I call the station of known location station, "Home Base." In order to figure out its bearing we need to calculate an angle relative to a known direction. If we had some way to directionally detect radio waves, we could use a magnetometer to get an absolute direction to compare to and then calculate a bearing off of that. Of course, this would mean that we would need to use a directional antenna or other means of determining the direction of the radio signal from the Home Base. Since we don't have a servo controlled, directional antenna on the Sun SPOT, nor a magnetometer, this is very difficult to measure.

Distance to Multiple Known Locations

Since direction is not likely to be an easy thing to calculate, we can take another approach. Perhaps it would be easier to determine our position by simply using distance to multiple known locations. In the image above, if we know that we are 100 meters to Green Base, then we know we are somewhere on 100m diameter sphere (remember radio waves propagate in 3 dimensions, not just a two dimensional circle) with the Green Base as a center. If we also know that we are 80 meters from the red base, then we know that we are somewhere along the intersection of the green sphere and an 80m diameter sphere with the Red Base as a center. The intersection of two spheres is an ellipse, with three spheres you get two points and finally with a known distance from four other devices, you should be able to pinpoint your location. Of course, most methods of measuring distance in the real world are not completely accurate, so more distances makes for more accuracy in your estimation of position.

One common problem with this technique is that it usually takes time to get these distances. To put it another way you cannot get all the distances simultaneously. If you move between measurements it will affect the accuracy of your estimate. The process assumes that you don't move between measurements. So we must either assume that both our device and the devices we are measuring are stopped during the measurement or apply a level of uncertainty relative to the total amount we and the reference locations could move during the measurement.

Time of Flight

Great, now we've reduced the location problem to just being able to measure distance. This should be easier right? A logical way to measure distance would be by calculating "time of flight" of the radio signal. In other words, calculate how long it takes the signal to get from transmitter to receiver. Let's take a look at this. Radio waves propagate at the speed of light or about 299,792,458 m/sec. This means that a radio wave covers one meter in about 0.000000003334 seconds or just over 3.3 nanoseconds. So, it can cover 3 times the radio range of a typical Sun SPOT in a single microsecond. One thing for sure is that we will need very accurate timings if there is any chance of getting reasonable accuracy to our measurements. The current eSPOT has a 180 MHz clock, or just over 5.5 nanaoseconds/clock. This means that every clock cycle corresponds to about 1.7 meters of radio propagation. Furthermore, the IEEE 802.15.4 radio standard that the eSPOT uses can transmit at 250kbits/sec. That means that a single bit has nearly 1200 meters between its start and finish. Or to put it another way, since the Sun SPOT range is roughly 100m, the start of a bit is always received long before the end of a bit is sent. This isn't strictly true because IEEE 802.15.4 radios use a more complex coding scheme than just sending a bit as an on or off (I explain this amore below), but the point still stands. A bit is much too large a resolution within a few meters.

For this method of measuring distance to have any chance of working we must measure the onset of the leading or trailing end of a bit - some sort of an instantaneous synchronization signal. It would be quite difficult to get any accuracy at all if any software were in the loop because timing is so critical. In order for this to be practical, we would need to have the ability to time tag arriving packets in hardware and not wait a potentially variable amount of time for something like an interrupt to get serviced. Additionally, we would probably need something similar on the output so that we could time tag packets as they are actually being sent. Its not good enough to time stamp them as they are put into the queue to be sent, they would need to be stamped as they are sent out.

However, even if you were able to get the exact time that a packet leaves one device and the exact time that it is received by another, there is still the problem of synchronizing clocks. It would appear that we would have to have clocks that are synchronized to the nanosecond. This seems like another very difficult task until you consider the following. Lets assume that at time Sun SPOT device has a clock time of while Sun SPOT has a clock time of . At exactly this moment, sends our synchronization signal over the radio. We would like to know the propagation time . We know that will receive the signal at time where

the problem is we don't know . We don't know the exact reading of another Sun SPOT device's clock at any given time. Either together with the synchronization signal or in a separate message can tell what time it believes the signal was sent (ie ). Since the clocks are not calibrated, this may have little relation to the time on the other Sun SPOT device. Using the information available to it, could calculate a preliminary propagation time () as:

Unless by dumb luck the clocks are synchronized to the nanosecond (not likely), we know that is incorrect. Let's suppose further that the difference between the two clocks is .

We know that the true propagation time, , is different from the calculated one, , by .

We really need to know the difference in the clocks, , before we can calculate the true propagation time, . Suppose that we repeat the experiment going the opposite direction. Then if we assume that the clocks do not drift with respect to each other (a big if at this level) and that the next synchronization signal is sent at and received at then we get:

Now if we make further assumptions that the devices have not moved and that the speed of light has remained basically constant (which for our purposes it is probably reasonable to assume), then we can assume that the propagation time is also incorrect by but in the opposite direction.

thus

Therefore now that we know , we can plug it in to get the true propagation time:

These values can be measures, so new we have the true propagation time, . Now we just divide by the speed of light to get the distance in meters:

This means that in theory, with proper hardware support we should be able to determine the distance to another device by measuring the time of flight of the radio signal. Practically however, even with hardware assistance, its hard to see how we would get more than about ten of meters of accuracy under good conditions, which is one tenth of the range of an eSPOT. Actually measuring with this precision and accuracy proves quite difficult.

However, our problems with this method aren't over yet. To most computer scientists, the idea sending a bit over a radio seems quite natural, but actually radio waves aren't digital. Digital bits are a convenient simplification that we apply to the real analog world. The signal that is sent is not a bit but an analog encoding of a bit. In 2.4 GHz IEEE 802.15.4 radios used by the eSPOT, data is encoded using Offset Quadrature Phase-Shift Keying (OQPSK). This encoding scheme must be decoded by the receiver and turned into bits. As the signal travels in the air and is affected by its surroundings, other signals and general noise, the characteristic of this signal can change. This means that the receiver needs to do some work to interpret the signal it is receiving. It needs to listen to it long enough to interpret what it is hearing. While this happens very quickly, the time required to notice the signal changes could actually vary slightly depending on the shape of the received signal. Even a few nanoseconds of variations will affect the accuracy of our distance estimations.

The current eSPOT hardware does include some ability to time stamp received packets in hardware, but its not clear to me that is has anything like the required accuracy or precision for the task of measuring time of flight.

Distance From Signal Strength

This leaves us looking for other ways of measuring distance using the radio. Perhaps the most promising is the use of Radio Signal Strength (RSS). It seems intuitive that RSS and distance transmitted are related by the inverse square law. In theory as distance goes up, RSS goes down and vice versa. As I've often found in life, the difference between theory and practice in much greater in practice than it is in theory. In the real world we find this is not strictly true.

One of the early programs that we wrote for the Sun SPOTs was a simple Therimin simulation. The Therimin is a unique electronic instrument that lets the user play music by waving their hands near two antennas that protrude from the device. One controls the volume and the other controls the pitch. Our version was inspired by this, but quite a bit simpler. It simply translated RSS values between two Sun SPOT devices into pitch values for a MIDI synthesizer. Unfortunately, we found it very frustrating to play because there was no strict mapping between distance and the notes that were played. We could start with the two Sun SPOT devices far apart and then slowly bring them together. We would expect this to create an increasing musical scale on the MIDI keyboard. While it was true that holding the SPOTs close together would cause a high note to play and holding them far apart would cause a low note to play, the transition from far to near was full of ups and downs. We double checked our code, but everything seemed to be in order. What was going on?

The problem was that radio propagation is fairly complex thing. At the 2.4GHz frequency range that the eSPOT uses for its radio, the signal propagates by line-of-sight. This generally means that if two eSPOTs are within visual range of each other and <~100m from each other, then should be able to communicate. The problem is that many factors can affect this signal propagation. Early on in the life of the Sun SPOT project, many of our demonstrations would be working perfectly until a crowd of people entered the room to see the demo. We experienced our own little version of a Heisenbug (a bug whose behavior changes when you try to observe it). These, "ugly bags of mostly water" (as Enterprise computer once referred to humans) tend to absorb radio signals. Remember that microwave ovens work in a similar frequency range. The eSPOT radios don't put out anywhere near enough energy to cook a hotdog or much or anything, but people and other water based items in the vicinity can absorb signals. Our observers changed the radio characteristics of our demonstration area just enough to upset our demo.

It turns out that line-of-sight propagation is much more than it may seem. A Sun SPOT does not have a highly directional antenna, so it transmits in all directions, not just toward the intended receiver. While some of this signal finds its way directly to the receiver, more of it will wander off in other directions. If one of these wandering signals bounces in such as way that the bounced signal also finds its way to the receiver, it will have taken a slightly longer path to the receiver than the direct signal. Because of this, it will arrive slightly out of phase with the direct signal. When a signal is received along two or more different routes, the condition is called multipath propagation. The receiver receives a mixture of these tow signals. The amount that the multiple paths affect the signal will change depending on the amount of delay and the strength of the signals experiences being mixed, as shown in the figures below:

       

The receiver will receive a signal that is the direct signal and the reflected signal mixed together. In mathematical terms this means the signals are added. The first graph shows two signals that are received slightly out of phase with each other (the same signal, just delayed slightly) and the red line is the sum of these signals. The RSS is measured as the amplitude (difference between the lowest and highest values) of the signal received. As you can see, the red line has more amplitude, and so a device receiving this signal will register a stronger signal strength than a device just receiving a direct line-of-sight signal. However, the signals don't always mix in a way that has a positive effect on signal strength.

Sometimes the way these signals add has a net negative effect on the signal strength. In the second graph, the two signals in black add to produce a red signal that has lower amplitude (and signal strength) than either signal individually. They are canceling each other out. You can imagine a situation where the reflected signal is delayed by exactly half a wavelength and thus effectively cancels the original signal completely. In addition to the phase shift caused by the delay, there is usually a bit of difference in amplitude between the signals because the direct signal is usually stronger than the reflected signal. This, and the fact that there are usually many reflected signals, will often keep the signal from being completely cancelled out, so in practice signals will vary significantly and in ways that are difficult to predict, but rarely will cancel completely.

There is something called the Fresnel zone (pronounced fray-NELL) that is an ellipsoid area around of the direct line between two communicating devices. The zones help to define the effects of the reflections. You can calculate the size of radius of the Fresnel zone with the following equation:

where is the distance in meters between the devices, is the frequency in GHz, is the Fresnel zone and is the radius in meters. So for example, if two Sun SPOT devices are 100m apart, and they use the built-in 2.4GHz radios, we get a value for of 1.77m for zone 1. This is the radius of the zone at its widest point (in the middle). Reflections in Fresnel zone 1 tend to cancel the original signal. Along an ellipsoid shape that is zone 2 (2.5m in our case) the signals will tend to add. Fresnel zone 3 would produce an value of 3.06m, and so on. In general, reflections in odd numbered zones tend to cancel the direct signal while signals in the even number zones tend to add to the signal strength. It is good to keep at least Fresnel zone 1 clear if possible.

Of course, if the two devices are closer together, then is smaller. So, for example, if the two devices are only 1 meter apart, then zone 1 would be a mere 17cm. Zone 2 would be 25cm. So moving something reflective to radio waves that is half way between the two devices only 8cm can make the difference between a very strong signal and a very weak signal. Of course, something closer to either device (the end of the ellipsoid) would have to move even less to have a similar effect. Near either of the devices, something moving only a few centimeters could completely change the signal characteristics. Similarly, moving a Sun SPOT device only a few centimeters could completely change the characteristics of the multi-path signal that is reaching it.

We can construct a hypothetical extreme case. The wavelength of the radio signals sent by the eSPOT is about 12.5 cm. This means that in the extreme case of a direct signal and a reflected signal of equal amplitude at right angles to each other, you can go from double signal strength to no signal at all in half a wavelength which is just over 6 cm. Note that this will be true regardless of how far away the two devices are from each other. This makes it very difficult to find a correlation between distance and Radio Signal Strength.

This brings up another question about these radio waves. What types of materials will affect the propagation of a radio signal? We know that they travel optimally through open air (or a vacuum). We know that, at this high frequency, many things tend to affect the signal. In general, metal will reflect signals and water will absorb it, but most things will do some amount of each. Plastic, paper and drywall tend to have little effect on the signal since they aren't metallic and have little water in them. A metal white board in a room can have a large effect on radio propagation. One of the most important materials is the ground. It can both absorb and reflect. Reflections from the ground are a common cause of interference. If we want to keep Fresnel zone 1 clear and get 100m of transmission, then we know from the calculation above that we need to keep them at least 1.7m off the ground and would prefer to be closer to 2.5m.

The story gets even more complicated when we look more closely at the what is going on. There are three phenomena at work when the radio waves encounter a an obstacle: reflection, diffraction and refraction. We discussed reflection earlier. Diffraction occurs when a wave passes by an obstacle or through a small opening and appears to bend. Refraction is the change in direction as a result of a change in speed of a wave as it travels through different media. Refraction is the least common since the speed of light is fairly constant within the realm where we working. However, the diffraction has a real effect. In particular, there is a phenomenon called Edge Diffraction that applies to radio propagation in these frequencies.

Imagine a Sun SPOT device transmitting a signal over a an open area with a single obstruction in it that can block the radio waves. One would expect that the obstruction would create a a radio "shadow" where no signal can reach. Instead, the signal at this point creates a new wavefront at the edge of the obstruction that propagates into the shadow area providing a weak, but sometimes usable diffracted signal. The area of direct propagation just beyond the top of the obstruction now exhibits an interference pattern with the refracted signal causing sporadic losses in the area labeled diffraction loss. Also, some of the signal will be reflected and this will create an interference pattern with the direct propagation wave in the area in front of the obstacle. All these affect signal strength. A similar condition occurs with a radio signal goes through a small opening. Diffraction occurs at the edges and interference patterns result that cause difficult to predict changes in signal strength.

If we want to get really esoteric, there are atmospheric conditions that can affect signal propagation. For instance humidity in the air can affect signal strength. Remember, water tends to absorb radio signals. This means that in addition to objects in the vicinity of the propagation path, even changes in the weather can affect signal strength. This effect is usually not as strong as some of the others mentioned above, but is can be noticeable. In some cases it can cause an effect known as Tropospheric Ducting where signals find paths through "pipes in the sky" created by certain atmospheric conditions that can go on for thousands of miles. This can cause otherwise line of sight signals to travel great distances around the earth. I've never heard of anything like this happening with a radio signal from an eSPOT, but it does show the counter intuitive nature of radio propagation. Besides, "Tropospheric Ducting" is just a cool term to be able to throw out in conversation, so I thought I'd tell you a little about it.

Radio Space Shape

As if all this weren't enough, most of these schemes assume a uniform signal radiating in all directions from the Sun SPOT device. This is simply not true in practice. The diagram at left shows the actual measured propagation pattern of the eSPOT antenna. If it were very uniform, we would see a spherical shape. Instead we see an indescribable shape with all sorts of different lobes and divots. You can see a > 10dB difference between the strongest and weakest edges of the signal. This means that you can change the signal strength can easily more than double just by changing the rotation of the Sun SPOT device. So the orientation of an eSPOT is very important in controlling for signal strength.

Of course, given what we've learned about diffraction and reflection of radio signals, you can see that this also means that in some cases a stronger signal may be aimed as a reflection rather than a direct route which will cause all sorts of confusion when it comes to signal interference and cancellation.

So where does this leave us? Just like with the accelerometer, finding the location of a Sun SPOT using the radio does not look very promising. In theory, we might be able to determine location if the following conditions were met:

1) There are no obstacles anywhere near the Sun SPOT devices or the area between them (for many Fresnel zones) that could reflect, refract, diffract or absorb the signal.

2) The Sun SPOT devices are many meters off the ground

3) The Sun SPOT devices do not change orientation with respect to each other.

4) The Sun SPOT devices don't move between measurements

If ANY of these rules is broken the result is a radio space that is for all practical purposes nearly impossible to predict. On a large scale, the closer devices are the greater their signal strength, but locally this will not hold true.

I'd be happy to be proven wrong. As always, all my gloom and doom may inspire someone to figure out a good way around these limitations and prove that you can measure location with radio and/or acceleration. Sometimes there is no greater motivation than saying it can't be done. Have fun. In the mean time, if you get unexpected readings of radio signal strength, now you may at least have an idea why it is happening.

I stand by now for your questions and comments.

Sun SPOT V5.0 Red Release

Its been a busy summertime so far and I realized that I haven't yet mentioned our new release here... so, here's the scoop: The new v5.0 Red release is available now from SPOTManager.  As always, remember it includes an emulator so you can play with it even if you don't have any physical Sun SPOT devices.

Here are a few interesting things to check out in the new release:

Updates to Solarium

Solarium includes several new views that add significantly to its usefulness. Radio View, Robot Simulator and Deployment View. Each is described below. Also, there is a new demo that shows how to add your own extentions to Solarium (SolariumExtensionDemo ).

Robot Simulator

Solarium now includes a robot simulator that lets you program a virtual Sun SPOT-based robot to navigate a maze and other virtual obstacles. These robots are based roughly on the iRobot Create which is a fine little robotics platform used in the IAROC competition among other things. From Solarium, simply open the RobotView and then click on "Add Robot." This will create a robot and virtual Sun SPOT to control it. You can even run multiple robots at the same time in the simulator. Its quite fun. Try the tutorial here.

RadioView

Radio View give you a visualization of the radio space of your Sun SPOTs. Its tells you which devices can talk to each other and the relative signal strength of the connection in each direction. This makes it much easier to construct multi-hop experiments and understand issues with your network topology. Click on a node to get information about its transmit power, MAC filtering and routing manager. Click on a link to get information about the strength ofJust open a Radio View from within Solarium to try it out.

Deployment View is a tool for managing the code on networks of Sun SPOT devices within Solarium. Think of it as a three things, an abstract way to define your network in terms of the roles that the different devices on your network, a way to assign devices to those roles and finally a distributed make-like tool for keeping the software up to date on your network. For example, I do a lot of demonstrations that including showing off the Bouncing Ball demo. Abstractly I can set up a deployment that includes two Sun SPOTs that each play the role I'll call ball bouncers. When I need to do a demo I can pick any two Sun SPOTs that happen to have charged batteries and OTA and assign them to these roles. Then I simply click the "Deploy & Run All" and the appropriate code is deployed to the Sun SPOTs that I have assigned. The power of this tool becomes apparent when imagine more complex scenarios where many devices have many different roles. Individual Sun SPOT devices can have multiple roles and individuals roles can be assigned to multiple devices for flexibility.The real place that this tool shines is during development. Here it acts like a distributed "make" tool. When you change your source code, the deployment view will figure out which of your devices need to have been affected by the changes you made to your code. It will then automatically deploy and start the new code to the devices that need updating. This means that a single click of a button can update the code to your entire network. This tool is in its infancy, so we hope to get a lot of feedback on how it could evolve to be more useful. This release includes major improvements to the reliability of radio transmissions. Additionally, the radio stack includes a new default routing protocol called the Link Quality Routing Protocol (LQRP). This routing protocol takes into account the not just connectivity, but also the quality of the connections when choosing a route. Previously, the system would choose the route with the least number of hops. Sometimes that would include long hops that had very poor link quality. Now the protocol includes the intelligence to choose a route that makes uses good quality links in order to maximize the overall quality of the link. This change is not interoperable with previous releases of Sun SPOT software. In fact, can show some confusing behavior because broadcast is compatible between V4.0 Blue and V5.0 Red while direct messages are NOT compatible. This means that protocols use broadcast to find services and then follow up with direct messages will get confused unless all participants are running the same version of software.

Crypto Library

The Sun SPOT platform includes advanced cryptographic capabilities. Many people don't even know that they are using Elliptic Curve Cryptography every time they deploy code to their Sun SPOTs, but they are. The system verifies the owner and validity of the code during deployment.

Now there is a demonstration of the SSL library for the Sun SPOTs based on the code in Sun's reference implementation of Java ME for cell phone. The Sun SPOT SSL library includes support for TLS 1.0, support for server-side SSL/TLS, support for Elliptic Curve Cryptography cipher suites (for now, only ECDH-ECDSA-RC4-SHA and secp160r1 are supported).

SPOT Web

SPOTWebDemo is a host application that starts up a simple web server and lets remote users interact with a collection of SPOTs in the vicinty of the attached basestation using a standard web browser. Authorized remote users can monitor the state of sensors, applications and other system statistics. They can also install, start, pause, resume, stop and remove applications. This allows you to do many of the functions that you would do in Solarium, via a standard web browser.

Yggdrasil

Many applications on Sun SPOT devices collect data. Yggdrasil is a data collection framework to allow you to stream sensor data to a centralized repository. The demo provides libraries and sample code to use the framework. The way that Yggdrasil works, the Sun SPOT sends sensor samples to host for the first time. The host does not recognize the sensor, so it queries the Sun SPOT. The Sun SPOT responds with handshake information and metadata about the sensor. Now the host knows about the sensor and begins to print out the sample data as it arrives.

AirStore

AirStore is an experimental shared data repository for Sun SPOT applications. It is designed to make a common usage of Sun SPOTs much easier... sharing simple data. Currently, when you write a program and want it to share data with another Sun SPOT over the radio, you have write some code to set up and transmit your data. Similarly, you have to write code to receive the data on the other side. AirStore attempts to make this much easier. With simple one line puts and gets, distributed applications can share primitive Java data types. One Sun SPOT application can set a variable x with

AirStore.put(x, 17);

and another can get x with

int x = AirStore.getInt(x);

The system works in cases where all devices are within broadcast range of each other and do not sleep. Thus for UI experiments or simple robot control, this method can work well. The data types supported are: int, double, String, boolean, byte, long, plus arrays of these types.

If you look in the demos folder you will find documentation, and inspector (host application) as well as several example programs including a rather interesting integration of Sun SPOT with a popular programming environment for kids called Scratch.

Other Enhancements

TWI (two-wire interface) is now supported to both the eDemoBoard and main ARM9 processor board.

You can now limit received radio packets to those from a sender on a whitelist or not on a blacklist.

Amusing Ourselves with Sensors in the Field

My son's math/science club had an opportunity to see a real rocket launch at Vandenberg Air Force Base this week. Unfortunately, the weather was bad enough that our NASA hosts decided not to attend the launch which took away our inside track to the day's activities. We were already half way to Vandenberg (approximately 250miles away) when we found this out. Faced with the prospect of a long trip with the chance of seeing nothing through the fog we decided to change our plans, so we vectored off to Santa Cruz and its famous beach boardwalk for a little Sun SPOT-based physics fun.

You see, Santa Cruz boardwalk includes a bunch of amusement park rides. Our crack team of researchers (the 4th & 5th grade math/science club) decided to use the Sun SPOTs to measure the G forces experienced in some of these amusement park rides. Fortunately, the standard Sun SPOT Telemetry Demo is just perfect for this application. It displays, in real time, the output of all three axes of the accelerometer and a total G force reading. By simply putting a Sun SPOT in someone's pocket while they ride the ride, we can see what G forces their body is being exposed to. We measured 5 different rides:

• Starfish - a spinning ride
• SeaSwing - a large rotating swing ride
• Bumper Cars
  
• Hurricane - a roller coaster
• Drop Zone - a vertical drop ride

Lets take a look at the project in a little more detail and see what we can learn.

Accelerometer Background

We used the eSPOT 3-axis accelerometer to monitor the motion. The Telemetry Demo application consists of two parts, one that runs on the eSPOT device and one that runs on the host computer. The application that runs in the eSPOT device takes accelerometer readings of all three dimensions and sends them over the base station to the where the data is received and plotted live on a laptop computer and saved for later analysis. (Yes, as you may have guessed, this implies that I was carrying a laptop computer around an amusement park - I wear my geek badge proudly)

The accelerometer on the eDemoBoard is actually 3 separate accelerometers, one for each dimension. The accelerometers are very tiny Micro Electro-Mechanical Systems (MEMS) devices hidden in a computer chip package. You can imagine that an accelerometer is made of two main parts suspended between two mounts. One of the parts connects to both mounts; we'll call it a bridge. The other only connects to one of the mounts, we'll call it the diving board. There is a mass on the end of the diving board so that it will wiggle around with respect to the bridge when the accelerometer is moved.

If you were to grab this device by the two mounts and wiggle it up and down you can imagine that the diving board would bend slightly. When a charge is applied to the bridge and diving board, it creates a sort of capacitor. As that diving board bends ever so slightly, it changes the capacitance between those parts and this can be measured. This allows the accelerometer to report a signal that corresponds to the movement of the device in one dimension. Also, note that the diving board can only bend in on dimension (up and down in the diagram), not side to side. If you imagine three of these packed very tightly together, each oriented 90 degrees from the other, that is a useful model for what goes on inside the accelerometer.

You can also imagine that when a eSPOT device is lying on its back, just sitting stationary, the the Z axis diving board will be bent down slightly by gravity. In fact, it will have 1G (or 9.8 m/sec^2) of bend to it. Now if you turned it over so that it was lying on it's sun roof, that same Z-axis accelerometer would have its diving board board bending the other direction. Therefore, it would measure -1G (or -9.8 m/sec^2). Meanwhile, in both of these orientations, the X and Y axis accelerometers would have no gravity working on them so they would have a zero reading.

In fact, it is interesting to note that when the Sun SPOT device is not accelerating (or decelerating), the accelerometers an tell you how the device is tilted. In other words, it can tell you which way is down. That is because the square root of the sum the squares of all the values will add to 1G in a downward direction no matter what way you tilt it. If the X axis accelerometer is measuring a non-zero value and the Y axis accelerometer is measuring a non-zero value, but the Z axis accelerometer measures 0G then Z axis must be parallel to the horizon.

The Telemetry-onSpot samples the three accelerometers every 10 milliseconds and packages the readings into a wireless network packet to be sent to the host application. The Telemetry-onHost application receives these packets and plots them on a moving graph. The green, blue and red lines represent the X, Y and Z axes respectively. It also calculates the the sum of the absolute values of all three readings together. This can be useful in determining the over acceleration applied to the device.

The Experiment

We were interested in measuring the amount of acceleration that our subject's body is exposed to as it rides the amusement park rides. It is easy to max out the 6G accelerometer readings by just waving a Sun SPOT back and forth vigorously in your hand. Clearly this would not mean that the subject's entire body was experiencing many Gs worth of force, only their hand. So we determined that it is important to make sure that the device is securely fastened somewhere near subject's center of gravity. We found a front pants pocket to be a fine place put it. Also, it is handy that the Telemetry-onHost application provides some smoothing functions that can reduce some of the noise due to ride vibration.

Now its time to ride some rides.

Starfish

A CSV file of the raw data is available here: starfish.csv.zip

Sea Swing

A CSV file of the raw data is available here: seaswing.csv

Bumper Cars

A CSV file of the raw data is available here: bumper2.csv

Hurricane

A CSV file of the raw data is available here: hurricane.csv.zip

Drop Zone

A CSV file of the raw data for the two runs are available here: dropzone1.csv dropzone2.csv

Your Challenge

Take some of this data and see if you can analyze it further. In particular the DropZone ride is appropriately constrained to provide an interesting area for further exploration. An interesting exercise would be to take this data and calculate how high you think the ride lifts you and how fast you go up and down. Let me know what you come up with.

If there is interest, I can analyze the data in more detail and see what we come up with in a future blog.

Don't let anyone ever tell you that research isn't fun!

There is now a new Beta version of the Sun SPOT software available.

It includes the latest features like:

• Radio View - wireless network analysis tool
• Robot View - Robot Simulation
• Link Quality Routing Protocol - more reliable wireless communication
• SPOT Web demo - web integrated sensors
• Optional encryption library and demos
• Yggdrasil data collection framework and demos
• more

Its freely available, easy to install and you can always revert back to previous versions. Take a look for yourself and let us know what you think on the forums. If you haven't installed the development kit yet, you can do so here.

Once you have done that, you can get the beta version using SPOT Manager by clicking on the "Preferences" tab and choosing "Beta Update Center"

Then go to the "SDKs" tab, choose the lasted release and click "Install." Its very easy.

Have Fun!

I have Two bits of news:

We are looking for your Sun SPOT project video

JavaOne is coming up and Sun SPOTs will be featured in talks and a "Birds of a Feather" as well as at the Change (Y)our World section of the main floor. One of the things that we will have in on the show floor is a large screen showing some of the projects that the Sun SPOT community has done with Sun SPOTs. If you have a project, and would like to make a short video of it in the next two weeks, we may show it on the big screen. Submit your videos to YouTube with the tag "spaughts" and drop me a line to let me know that you'd like participate. No project is too big or two small. Just give us a short video that shows us anything fun, cool, interesting you have done with Sun SPOTs.

Students get in Free!

If you are a student and you are interested in attending JavaOne, you can get in for free. I just learned about this program for students. In fact educators who bring 10 students can also get in for free. That's a pretty sweet deal.

Hope to see you there.

Money is tight these days. If you would like to go to JavaOne, but don't have the means, make a video about why you should go to JavaOne and you could win a conference pass and money to offset travel expenses.

Check out information about the contest here.

Remember, Sun SPOTs might be worth extra credit.

We have some pretty exciting new features planned for upcoming Red (V5.0) release of the Sun SPOT software environment. In particular I'm really pleased with some of the improvements in the radio stack. We have improved the performance of the system over multiple hops significantly. One of the main difficulties of programming these distributed wireless devices is that it is often debugging communications. The current development release of the Sun SPOT Java Development Kit includes a new Solarium view called RadioVIew. It shows the current state of the network of Sun SPOT devices.

The RadioView is built into Solarium and allows you to see the topology of your radio-space. What deivces can "hear" each other and what ones can't. This can help debug some of those nasty mutihop radio bugs and aid you in tracking down dead points in your radio space. Additionally, you can get information about each node and each link from the view to see what the signal strength is like for any particular link.

How to try it out for yourself

Since our development is completely open, you can take a sneak peek at some of these features now as we develop them. First make sure that you have installed the Sun SPOT Java Development Kit. In the SPOT Manager Tool, select "Dev Preview" under the "Preferences" tab of SPOT Manager.

Once you have selected "Dev Preview" return to the SDK tab and you will find all the developer releases under "Available SDKs." Install the latest red-XXXXXX release. Then upgrade your Sun SPOT devices. Remember, its an unstable developer build, but any time you run into too many bugs you can always revert back to your previous version of the SDK.

Once you are up and running, open Solarium and create a RadioView under the "Views" menu. It takes a few seconds for it to interrogate the network, but once you see your devices there, click around to get information about what is happening.

Also, don't forget that, as with any other Solarium view, Radio View can be "docked" to other Solarium views or made into an independent window simply by clicking and dragging on the area just below the titlebar of the window.

Enjoy!

Here's another contest for anyone 17 or under who uses open source technology (like the Sun SPOTs hint hint). The contest, called Digital Open, is sponsored by the Institute for the Future, Boing Boing and Sun Microsystems.

Submissions are being accepted for anyone under 18 who creates open projects in the following categories:

• Open Code

• Open Community

• Open Discovery

• Open Earth

• Open Entrepreneurs

• Open Gear

• Open Media

• Open Play

It seems to me that Sun SPOT projects would fit in multiple categories!! Have fun!

Take a look at Digital Open. If you don't qualify, pass the info on to a nearby teenagers who would.

We've got our share of uncertainty these days. The global economic downturn has caused a whole lot of uncertainty. Many people are losing jobs and the economy that thrives on hope is full of doubt. Yet there is a silver lining. More than ever people are reevaluating their work and their lives. They are figuring out new ways to increase efficiency, streamline their work, focus on what is important, in short reevaluate everything. Some people who are laid off from one job are finding the time right for starting up a new venture, something they might never have taken the initiative to do before. Others are finding better strategies to make themselves more competitive.

We got a large does of uncertainty yesterday as it was announced that Oracle planning to buy Sun. This is an official proclamation, not a rumor.

&

Several people have been asking about how the news of Oracle buying Sun will affect the various projects here in Sun Labs. What are the implications to open source? What about Oracle's view on research in general? The short answer is that we don't really know what course this will take but there are a few important things we can say now. First is that up until the deal closes (or doesn't) this summer, we are two independent companies. We will be going about our business with our Sun-oriented priorities just as we have before. Don't expect us to be suddenly change the direction of our research or anything. Second, it will probably take some time for the news to settle in and for all the implications to follow their course. At this point no one knows the details because they don't exist. I believe that one of the reasons Oracle is interested in us is because of Sun's strong history of innovation and it's certainly my hope that Sun Labs will plays a strong part in the future as well.

..but enough about us...

Because so many of our projects in Sun Labs are community-based open source, our communities have a significant stake in this too. For those of you who have invested your valuable time and energy into our technology, what does this mean?

Let me start by saying that research labs are usually created to take on risk that is not appropriate for the other parts of the business. By definition, we take on projects that can fail. There is always the risk that a project will end regardless of who is buying whom or what the current economic climate is like. Usually this is technical risk. Its not clear that the merger puts any project at more or less risk than before.

So what about the future? The good news is that you have more influence than you might think. It used to be that consumers of technology were completely dependent on the projects that produced that technology and ultimately that company's budget and management commitment. Whether a company is purchased or goes through some tough financial times or not, projects at corporations can come and go on a whim. Today, with open source, that is no longer so true. Once the source code is out there, it can never really be taken back. It doesn't just belong to the company, it belongs to the community. In fact, that is why we like open source. By giving up a little bit of control, we gain your partnership in insights, imagination, enthusiasm, innovation, direction and leadership. What we gain from open source is exactly the fact that the community can influence the direction of the project. If, in the worst case, a project funding goes away for whatever reason, the community remains. In the case of most every Sun Labs project, the number of people in our communities dwarf the number of people actually assigned to a project here in Labs. The community is much bigger than the internal project. The technology is out there and it will continue to be used and pushed forward by the community.

More importantly, a strong community is one of the best arguments for a company's continued investment in a technology. When a project has a strong community, engineers are inspired, managers feel external validation, sales and marketing sees evidence that we are on an interesting track with market potential. When you use an open source technology and more importantly when you participate in its community, you endorse that project/technology. Just by browsing the web site and posting comments on the forums, you are casting your vote for it to continue. When it comes time for evaluation of a project, the community can make or break a project. Make sure that your favorite project has the most web site hits, forums posts and projects based on it to make it clear that it has a strong community. Blog, Twitter and otherwise spread the news to help grow the community and make it a success for everyone.

Onward

So don't think about who is being bought by whom or what the economic crisis of the moment is. Think about the technology that the world needs and become a supporter of it. Do you part to make the world a better place.

For those of you still concerned about the merger you can find some official statements from Oracle here and here.

The upcoming release of Sun SPOT software (Red v5.0) will feature a new robotics simulator built into to Solarium. It allows you to use virtual Sun SPOTs to program virtual robots using the Sun SPOT Java Development Kit. The great thing about it is you can download it and use it for free right now! Even if you don't have Sun SPOTs.

The simulation roughly mimics the environment that is used in a competition held in San Diego each year called IARoc sponsored by Wintriss School. In this competition students use Sun SPOTs to control and iRobot Create to navigate a maze. The Create is very much like its more popular sibling, the Roomba except it doesn't suck... by which I mean it has no vacuum... (Roombas are great, BTW) The combination of a Create and a Sun SPOT is fantastic for learning the basics of robot motion and navigation. In the simulation you write software for a Sun SPOT, and then in Solarium, create a new Robot View and Add a Robot. This will create a Robot/VIrtual Sun SPOT combination. Back on the Grid View, you will now see a Virtual SPOT. You deploy and run your software on this Virtual SPOT and it will control your simulated robot. You have your choice of three different environments to run in; an empty room, a maze, or an obstacle course. Each view includes an 'X' as a starting point and a 'O' as an ending point. Your robot includes sensors that allow you to sense when your robot is over one of these marks. We also provide a sample application that can find the center of the room, or if you poke around in the code a little, you'll see a simple wall follower. Its just enough to get you started.

Its great fun! ...and you can get as fancy as you like. For instance, you can create multiple robots that will interact in a single view. These robots can interact with each other. They can run the same code or different code... whatever you like. Of course, they can also use the the Sun SPOT radio communication library to communicate with each other. This way your robots can cooperate to carry out a task.

And of course, if it doesn't do what you like, remember you have all the source code to the entire system, so you can make it do exactly what you would like. Give it a try!

To use the simulator follow the instructions here.

We on Project Sun SPOT are on a mission to drive the adoption of Java on small devices everywhere. We believe that with Sun SPOT devices we can help speed the onset of the Internet of Things by providing smart, connected devices and tools to developers, students, researchers and hobbyists. That is why we are so excited this week to announce the port of the Sun SPOT platform to the FIRST Robotics hardware (the National Instruments Compact RIO) and thereby making our software environment available to some of the best and brightest high school students. Yet another step toward Java everywhere. ...and this is a big step

  

The FIRST Robotics Competition is a truly inspired event originally created by Dean Kamen the inventor of the Segway. Each year tens of thousands of high school students compete with each other in head to head robotics competition. Its really a great event. I've attended the regional competition in San Jose several times now and what I've seen is nothing short of amazing. First, the robots are impressive. Its really hard to believe that high school students are able to put together such fantastic devices. These robots are usually quite large and heavy (the size of several of the students combined). They are designed to fulfill some interesting task such as retrieving large balls (several feet in diameter) and lifting them into a hoop six feet high. The teams go head-to-head with multiple robots on the playing field at one time. This year the challenge has the teams collecting some balls and trying to place them in a trailer that the opposing team is pulling behind their robot, all the time protecting their own trailer. This leads to the second amazing thing about the FIRST competition. It is great entertainment. At the regional championships in San Jose, I am just one of thousands of spectators watching the event. There is music and cheerleading and mascots and a general party atmosphere. It nearly brought a tear to my eye when I saw thousands of screaming fans watching a bunch of (and I use the term affectionately) nerds out there doing their thing. The competition is fierce with often intense rivalries between schools. While the spirit of competition is strong on the playing field, what is truly amazing is the attitude in the pits. As a walked around looking at the amazing creations, I often overheard competitors helping each other out, lending tools, advice, muscle power and general moral support. These kids get the idea that the most satisfying competition is the one where everyone is performing at their best. On the field they are competitors but in the pits they are on a mission together to change the world. These are our future technical leaders.

Right now I'm in Atlanta to attend the national competition at the GeorgiaDome... The freakin' GreorgiaDome! the same thing on an even larger scale. Its all very impressive. Its clearly a life experience for the kids lucky enough to compete here. Over the last couple of days I've gotten to meet some of these competitors. They are only in high school, but this competition has already given them real-world war stories that come from trying to make something complex come together under an aggressive time schedule. This is great, real-world experience.

Where does Sun SPOT fit in?

The folks at Worchester Polytechnic Institute (WPI), with some help from us, are porting the Squawk virtual Machine that underlies the Sun SPOT software stack to the controller used for this competition. This means that in next years competition the students will have the opportunity to program their robots in Java. It also mea

ns they'll have access to some of the libraries and features that we've built in Sun SPOTs. It seems that last year they did a survey of the students, and a huge percentage of them asked for Java. This makes sense since Java is the language they are tested on in their advanced placement exams. It just so happens that we have a great little open source Java environment at the core of the Sun SPOT system called the Squawk Virtual Machine. So last year, several students from WPI joined us for the summer to try porting the Squawk VM to the Compact RIO. It worked well. Now we are well on the way to making the platform available to the students so that they will have new tools to do their magic. You can learn more about FIRST and the Sun SPOT Java software here and you can get some background on the port itself here.

Welcome FIRST competitors to our little corner or the world of builders and makers. May you take your skills and competitive spirit and save the world for all of us!