Ragemaster

Since upgrading my Ubuntu installation, I got plenty of compile warnings when compiling TinyOS applications.  To fix this, I just decided to reinstall TinyOS.  It can be a pain to install and each time I do it, I've got to look for resources on the internet and try a couple different things to get it working.  I'll try to keep this updated whenever I discover something new or have to upgrade or reinstall TinyOS again.  Here are the references I found to help me compile this:

All Platforms:
Installing TinyOS 2.0.2

Ubuntu:
5 Second Fuse - TinyOS Installation
Install TinyOS-2.x On Ubuntu << Udin Harun

I also got it running on my Leopard Macbook using this:
Installing TinyOS 2.x on Mac OS X (Tiger and Leopard)

This worked for me on Ubuntu 8.10 Intrepid Ibex.  I did have a previous install of TinyOS that I removed, but some stuff may have been left behind.

1.  Add the following line to /etc/apt/source.list:

deb http://tinyos.stanford.edu/tinyos/dists/ubuntu hardy main

Currently, there isn't any repository for Intrepid Ibex, but this seems to work fine.

2. Update the repository cache from a terminal window:

$sudo apt-get update

3.  Install TinyOS packages:

sudo apt-get install tinyos tinyos-avr tinyos-msp430 nesc tinyos-tools

In my case, "tinyos" caused a warning since it was an abstraction for several packages.  I installed "tinyos-2.0.2".

3a.  (Iris Support): Install TinyOS from CVS:

I also wished to have the latest TinyOS version from CVS since it seems those provided via the Stanford repository did not support the Iris mote.  To install from CVS, open a terminal window to the installation directory of your choice and run the following:

$cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
$cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x
$cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x-contrib

tinyos-2.x-contrib is a library of user-contributed code that can help in designing your own applications.  If you installed as su, you may want to change the permissions of your tinyos directory if you wish to compile anything in the apps directory or modify any TinyOS code:

$chown -R <uid> tinyos-2.x

4. Add the following environment variables to ~/.bashrc:
export TOSROOT=/opt/tinyos-2.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:.
export MAKERULES=$TOSROOT/support/make/Makerules
export PATH=/opt/msp430/bin:$PATH

Depending on the directory and version you have installed, you may need to change TOSROOT to reflect the correct directory.

5. Install TinyOS Java Toolset:
I had issues with this one: you may not have to do this step if you just use the tinyos package provided by the Stanford repository.  However, I installed via CVS and had to install the TinyOS Java toolset manually.  Ensure that you have performed Step 4 and modified your .bashrc file before proceeding.

First, from the terminal, run:
$sudo tos-install-jni

This will install the Java Toolset into your Java directory.  For some reason I had Java 1.5 (5.0), Java 1.6 (6.0), and OpenJDK installed on Ubuntu.  Oddly, javac pointed to Java 1.5 and the java command pointed to OpenJDK, which was causing errors when running TinyOS Java apps like TestSerial.  To fix this, I removed Java 1.6 and OpenJDK since these seemed to be causing nothing but problems and just about everything runs on 1.4 or 1.5 (including TinyOS Java libraries).  Now java and javac point to Java 1.5 (Hopefully doing this didn't toast some other application).

You can then compile the TinyOS Java libraries by running the following in the terminal:
$cd $TOSROOT/support/sdk/java
$make

6. Install Graphviz
This step seems to be optional, but you need it if you want to run the Oscilloscope application.  In a terminal, run:
$sudo apt-get install graphviz

TinyOS wants an old version of Graphviz, but Oscilloscope seems to run fine.

7. Check your TinyOS Installation:
From a terminal, run:
$ tos-check-env

Running this, I have received errors about the Graphviz version, but the Oscilloscope application runs fine with the newer version.

To test your installation with Telos-based motes, try:
$ cd /opt/tinyos-2.x/apps/Blink
$ make telosb install.0 bsl,/dev/ttyUSB0

To test with Iris motes, try:
$cd /opt/tinyos-2.x/apps/Blink
$make iris install.0 mib510,/dev/ttyUSB0

To test the serial connection with Telos-based motes, try:
$cd /opt/tinyos-2.x/apps/tests/TestSerial
$make telosb install.0 bsl,/dev/ttyUSB0
$java TestSerial -comm serial@/dev/ttyUSB0:telos

To test the serial connection with Iris-based motes, try:
$cd /opt/tinyos-2.x/apps/tests/TestSerial
$make iris install.0 bsl,/dev/ttyUSB0
$java TestSerial -comm serial@/dev/ttyUSB1:iris

It seems that with the Iris, applications must be installed via the mib510 board (ttyUSB0) and data can be retrieved by accessing the mote itself (ttyUSB1).

7.  Issues
In addition to the Graphviz errors, for some reason the motelist command does not see the mib510 interface board or the Iris.  However, when I install to /dev/ttyUSB0 or listen to /dev/ttyUSB1, the installation works fine.  motelist does recognize the Iris on OS X, however.

As with EmNets over the summer, the trip to SenSys this week was an experience.

The sessions went from Wednesday through Friday so my adviser, the other student in our group, and I left Tuesday afternoon and got back late last night.  The weather in Williamsburg sucked when I left and it sucked when I got back, but it was nice in Raleigh.  I also managed to get in my weight routine and the bike/elliptical every day while I was there, but I had to get up early to do it.  The whole thing really wore me out and I was asleep by ten every night.  Of course, I got up before seven to start my routine and kept awake with the terrible coffee they had.  Hard to believe I drink enough coffee now to have preferences (darker roasts are better).

Overall, the whole thing was kind of weird.  Nearly everyone there was foreign -- despite most schools being from the U.S., almost all the students and professors were not.  I guess this was to be expected -- it was like taking a 200 person sample of the world population and putting them in the same room.  A plurality were Chinese, a lot were Indian, and there were only a small number of Europeans and Americans.  Since my adviser and the other guy in the research group were Chinese, I found myself hanging out with everyone else speaking in Chinese.  The group meals we had and conversations during the break were kind of awkward since they would speak some in English and then just suddenly switch to Chinese.  For example, the first night we went out (to a Chinese restaurant of course), I was the only one of eight that used a fork and knife.  I should probably start learning Chinese so that I can at least pick up some of it.  My adviser encouraged me to talk to people during the session breaks, but it's tough when many aren't speaking a language you can understand.

Asides from the demographics, the other thing that made it weird was the atmosphere.  These are some of the top people in sensor networks and the whole thing seemed so ... unprofessional.  The attitude of everyone and atmosphere seemed so relaxed and informal - at the end of a few presentations there were a few arguments between the presenters and a questioner.  Nearly everyone was in typical student-type clothes and the faculty were typically attired, and it seemed as much a chance to have a good time as it was to show off your work.  Some of the UVA guys came in one morning musing about how drunk they got the night before.  The closest thing I can compare this to is NCAAs for cross country.  With this conference and the NCAA meet, the idea is the same: the best schools come to show off their stuff, but the atmosphere at NCAAs was extremely professional and focused.  In both cases we had a banquet with everyone that was attending, but at NCAAs everyone was subdued, had their "game face" on, and kept conversation to those within their team.  In contrast, at SenSys, there was wine on the table and everyone was nearly out of control by the end.  Somehow, I expected something a little more formal, but I guess that's the appeal of academia -- you're given a fair amount of leeway as to what you can do in research and in your approach to your work.

I met up with the other people I had collaborated with over weekly Skype meetings since last winter.  It was interesting to meet them in person and I got some special hardware from the hardware guy we are working with for our current project.

In my opinion, about a third of the sessions were interesting, a third was okay, and another third wasn't of interest to me.  There was some cool stuff on measuring radio link connectivity burstiness, vehicle sensor networks, and integrating posture detection and geolocation data into social network sites.  There was stuff on distributed camera image recognition (detection people's gestures), ensuring privacy when sharing personal sensor data, and a environmental monitoring system using accelerometers to measure flow rate in water pipes.  I didn't care too much for the radio MAC protocol stuff and there were a few high-level programming frameworks that seemed uninteresting. 

According to my adviser, SenSys papers are focused on actual deployments and implementations while marginalizing theory in design.  Most of the papers had a giant deployment section with lots of pictures and evaluation statistics.  While deployments are practical, advancements are slow since so little new theory is developed.  One or two of the papers presented had simple data collection and evaluation schemes that were just tested extensively in the real world, such as a road pothole detection system using accelerometers and GPS/cell towers for localization.  I would like to work on stuff that can actually be deployed (I am now), but deployment and testing takes a lot of time and isn't really research.  Other conferences are more focused on theory and a simulation-based evaluation is acceptable.  The reviewers look more at algorithm design and novel theoretical ideas over real-world deployments and testing.  Additionally, the committees for each conference tend to have varying amounts of control over who gets accepted -- some are very tightly knit and seem to accept papers only from certain schools while others are more diverse and objective over their selections.

Listening to the paper presentations and going to the poster and demo sessions got me a few new ideas.  The poster and demo sessions were especially interesting because you could talk one-on-one with each person about what they had done or were working on.  A lot of people out there have a lot of good ideas.  Most of the presentations were done by students and a lot of them weren't much different than me in terms of age and experience.  It seems that students are typically listed as first authors and give the paper presentations while their advisers come to watch and ask all the hard questions.  That was also what was weird about it -- it wasn't much different than going to class and listening to student presentations, except that the work was exceptional.  I took a lot of notes and saw what made a good presentation: abstracting away details and making your main ideas clear.  It sounds like going to a conference (maybe not this one) and giving a talk on my paper is in my future.  I only have to get accepted first.

So now I come back motivated to get going on my current project.  The ideas are (hopefully) new and will actually work when we get the thing implemented.  I'll be able to do an actual test with sensors instead of just simulation.  The deadlines are looming and it's time to get moving.