Blog, I have not been ignoring you (non-RC moving obstacle)

No, I have... and I am sorry. I could site a million and one reasons, but you don't care. What do you care about?

My next project!




Work has granted me a sweet RC car to take home, attach a SunSPOT, and create some simple behaviors so that it acts as a moving obstacle. In the bigger picture, I am involved with a project that calls for the evaluation of several planning algorithms for human following in dynamic and cluttered environments. To test this, outside of simulation, we need some damn moving obstacles.

Hardware: On top of the RC car, I will place a pyramid-shaped shroud made primarily from balsa wood. I Google SketchUp'ed a model of the shroud. I will attach a SunSPOT to the electronic speed control and steering servo of the RC car.

Sensors: The sensor package for this moving obstacle comprises only those sensors included in the SunSPOT. However, the system will employ only the 3G accelerometer for some coarse local positioning.

Plan: So far, I ordered the car and downloaded the manual for the electronic speed controller in the car. Unfortunately, the manual does not provide the frequency of the PWM signal used to control the speed. The steering servo takes standard servo inputs, I'm told. To add to my chagrin, I am no EE person. Therefore, I will most likely proposition the help of several online forums and/or EEs at work, in order to figure out the accepted signals for controlling these components.

SunSPOT underwater radio range

For this experiment, I moved the SPOTs over to the local community center pool. Using the same watertight case and ZipLoc bag full of pennies as anchor, the configuration changed slightly. This time the ZipLoc bags anchored the SPOTs from a cord attached to each of their waterproof cases. These allowed the SPOTs to hover about 3 feet above the floor of the pool. I performed the test in a section of the pool which is 4 feet deep.

Oddly enough, the SPOTs could communicate with each other up until approximately the same distance as in the bathtub-- 8 inches.

In addition to this disappointing conclusion, SPOT communication on the water's surface appears stable up to approximately 5 feet. I tested this to the extent that I could indoors, from long side to long side of an olympic side swimming pool. Raising the SPOTs slightly above the surface of the water improved results greatly. So maybe there's some hope for autonomous surface vehicle SPOT communication.

This ends my experiments with underwater SPOT communication, as I am not convinced it will get any better. In fact, in saltwater, it may become worse.

There is one final water-based experiment that I would like to see done (by myself or some other more industrious individual)-- above-ground basestation to saltwater surface SPOT communication strength.

SunSPOT underwater radio range (preliminary tests)

At least one member of Sun Research Lab, and a number amateur SunSPOT enthusiasts, have performed tests to measure the ability of the SunSPOT radios to communicate under different conditions. To date, I have not found an experiment to test whether or not SunSPOTs can communicate underwater. 

Using a bath tub, two waterproof cases, and two ZipLock bags, I performed this crude experiment.

My intentions for this experiment were not to take any detailed range or lost packet data. Rather, I hoped for the experiment to yield two important boolean answers to the following questions. Are my purchases truly waterproof? Can SunSPOTs communicate underwater?

To the first question, yes, the hard, waterproof cases I bought from Dick's Sporting Goods are waterproof to at least a foot. I tested this by placing tissue paper inside each and leaving them under a foot of water for an hour. N.B.: ZipLoc bags are not waterproof-- I used these on top of the waterproof cases so I could weight them to the bottom with pennies.

To the second question, yes, I was able to achieve up to 3.5 LEDs with no lost packets (using Ron Goldman's RadioStrength demo in %SPOT_HOME%/sdk/Demos). Of course, this occured only when the two SPOT antennae were close enough to be "more than just friends." Without touching, they achieved a signal strength of just over 2 LEDs.

The crudeness of this setup prevents any further solid conclusions. Whether or not I go to the YMCA pool tomorrow depended on the results of this experiment (Why waste the effort if they don't work in a bath tub?). However, for kicks, I threw a ruler into the tub. At 8 inches apart, the SPOTs communicated with no lost packets.

Consider these issues with the current setup: 

• As mentioned by Ron Goldman in this post, placing the SPOTs too close to the ground will decrease the signal strength. Now, I live several stories above the actual ground, but I can only assume that Ron meant any solid surface. In my experiment, the SPOTs laid on the bottom of the bathtub.
  
• In addition to the the adjacency of the SPOTs to the ground, the walls of the bathtub may provide additional signal interference/assistance.
• Signal strength could not be tested at depths greater than one foot.
• Different SPOT orientations produce varying signal strengths. Clearly, antenna-on-antenna action peaks reception. However, orientating SPOTs so that they face each other seems to produce the greatest signal strength over distance.
• My SPOTs were severely undercharged at the time of this experiment (less than 10% charged). I configured both SPOTs to transmit at full power. Theoretically, battery power should not have any effect on signal strength, but I make no assumptions.

SunSPOT sdk blue compiles with JDK1.4

By default, the blue version of the SunSPOT compiles with JDK1.4. This is not much content for a blog post, but the problem wasted an hour of my life/development time. Here's the error message:

generics are not supported in -source 1.4

Simple enough, right? Obviously, generics weren't around until version 1.5. Usually, this error yields to a simple change in the project properties or platform manager in Netbeans. Or, on the command line, you would specify "-source=1.5" as an option when compiling. Unfortunately, we're dealing with SunSPOT applications that use special ant scripts that automatically specify all the paths and properties needed to compile/run either a host or client application, with host-compile/host-run and compile/run, respectively.

The solution: In your %SPOT_HOME%/sdk directory exists a file named default.properties. Open this file for editing and search for "host.java.version". You'll see that the file sets this property to some value (1.4 in my case). Change that value to the latest version of Java.

Perhaps the fine researchers at Sun Research Labs will change the default setting of host.java.version from 1.4 to 1.5 in future SDK releases.

SpotClientCommands

Sometimes I make some stupid mistakes. Lately, I chalk that up to working too late at night at this SunSPOT stuff. However, after a full "engineer" work day, there's little time left but late at night to do anything.

SpotClientCommands holds all the commands available in a SpotClient, and provides a means for the execution of these commands whether the SPOT is PC-tethered or out in the wireless wild. The details of my inquiry can be found here. Notice, someone posted a link to a good project-sized examples of how SpotClientCommands is used to create a SPOT shell.

I took a few important lessons from this problem:
1) SpotClientCommands has two different constructors (as of the blue SDK). The first, with 6 arguments, commands directly-connected SPOTs. The second, with 8 arguments, commands SPOTs wirelessly over a basestation.
2) The OTA command server must be enabled on the free range SPOTs and disabled on the basestation.
3) It's safest to execute these commands on a SPOT with the out-of-the-box dummy application installed, but others will work as long as they do not enter deep sleep.
4) Before you can execute any command except for the "hello" command, you must execute the "synchronize" command. SpotClientCommands.execute("synchronize");

ant hello

Each free range SPOT can run a small number of commands using the libraries installed on them by default. The OTA command server is charged with intepreting and performing these commands. One of these commands is "ant hello", and it acts as a good indication that your SPOTs and base station are all communicating correctly, read to accept commands, etc.

After messing with some demos, however, I ran into trouble when trying to invoke the simple command. I pleaded with the SunSPOT World forums:

What is the appropriate response for this command? My basestation is connected, OTA server disabled, and running as a basestation. Client one is configured to run the built-in dummy application, and the OTA server is disabled. Client two is configured to run the current application, and the OTA server is enabled. The response to "ant hello":

-run-spotclient-one:
[java] SPOT Client starting...
[java] There are 0 Sun SPOTs in range

[java] Exiting

How do I get both SPOTs in range?

---

First off, the OTA server must be enabled in order for a SPOT to respond to a hello request. The OTA server is the process that (among other things) responds to the hello). If you turn the OTA server on (ant enableota) on the SPOT with the dummy application, it should begin to respond.

Second, you need to be sure you are not running an application that deep sleeps. If the SPOT is sleeping, it will only respond if it happens to be awake when the hello is sent. You don't say what the "current application" on your second SPOT is. What I'd suggest is that you make sure that OTA is enabled, then connect the SPOT via USB and deploy something like the BounceDemo-OnSPOT, which does not attempt to sleep. If you still encounter problems, posting the output of 'ant sdk-info' and 'ant info' for one of the failing SPOTs will provide a place for people on the forum to help debug the situation.

---

I upgraded my SPOTs to blue-sdk, enabled OTA on both the free range SPOTS (disabled by default), started the base station ("ant startbasestation"), and ran "ant hello" with the base station plugged into my PC. However, the command did not work until the base station and the two free range SPOTs were restarted using their respective reset buttons.

To recap:
1. Ensure both fre range SPOTs have loaded on them an application that does not deep sleep.
2. Enable the OTA command server on free range SPOTs usng "ant enableota".
3. Ensure your base station is configured as a base station. Remember, anytime you do an "ant info" on the base sation, you must do an "ant startbasestation".
4. Reset all SPOTs with the reset button on each device.
5. With the base station plugged into the USB port, run "ant hello".

MIDlet class specified was not found

This is my first issue with the Java SunSPOT, out-of-the-box. From Netbeans 5.5, when you start a new Sun SPOT Application, a template application is always created. The template application builds and deploys correctly-- assuming you followed all the installation instructions and wrestled away all the PATH or ENV issues-- and should print, "Hello World!", followed by the address of the SPOT client's radio. However, the latter part does not happen. Instead, you get the following error:

java.lang.IllegalArgumentException: MIDlet class specified, org.sunspotworld.src/org/sunspotworld/StartApplication, was not found

What's the problem? Well, this may be something I screwed up in my setup, but the manifest file is set up wrong! Here's what I get with a new project and no alterations:

MIDlet-1: src/org/sunspotworld/StartApplication, , org.sunspotworld.src/org/sunspotworld/StartApplication

The line, written correctly, should read:

MIDlet-1: src/org/sunspotworld/StartApplication, , org.sunspotworld.StartApplication