If you are running a version of Linux that supports Debian packages, then you may want to use the TinyOS package repository.

1) Remove any old tinyos repository from /etc/apt/sources.list and add the following:
Supported distributions are (edgy, feisty, gutsy, hardy)

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

2) Update your repository cache:

 sudo apt-get update

3) Run the following to install the latest release of tinyos and all its supported tools:

 sudo apt-get install tinyos

4) Add the following line to your ~/.bashrc or ~/.profile file in your home directory to set up the environment for TinyOS development at login

 #Sourcing the tinyos environment variable setup script
 source /opt/tinyos-2.1.0/tinyos.sh

If you typically run tinyos from CVS and only require the toolchain installation, you can install the tinyos-required package instead of the tinyos one to just pull these in.

Keep in mind had inconsistent success with running apt-get upgrade tinyos, so for now it’s best to play it safe and remove any old tinyos packages before installing the new ones.

Also you have used the TinyOS debian repository in the past, keep in mind that all of the tools have been updated for TinyOS-2.1, but still work with all older versions of TinyOS as well. If you try updating in this way, and you see conflicts with some deprecated packages, send me an email (klueska@cs.stanford.edu), and I’ll add them to the conflicts list so that they get removed when the updated tools are installed. These conflicts should be OK so long as you remove any old packages; they are due to a change in the names of the updated packages installing into the same locations as the outdated ones.

I found out a discussion going on slashdot.com, where visitors are sharing and describing their own UAV building experiences. The post starts like as show below but read all comments which are explanation in real.

Shojun writes “I am very interested in building my own UAV, not just one that can fly around happily, but one that I can program to say, take photos every second as it does a barrel roll under a bus (ok that part may be a pipe dream). I have enough embedded programming experience — it’s the hardware which I’m uncertain about. I can go the kit way, and then build the remaining stuff, or get some Dollar Tree Foam boards and build it all. I’m in favor of ease, however. Once the plane is built, buying a dev board seems like a possibility, but I wonder whether it’s overkill. Alternatively if there was a How-to-build example on the net for such an activity that I could adapt, to the degree that I could then program in even completely hardcoded flight instrutions, I can certainly take it from there. Thoughts? Has anyone here tried something like this before?”

Read the original post and all comments regarding UAV building Here…

Thank you.

UAV Devboard

I found This article from DIYDRONES.com and they update the links for this board regularly. So if you want to know about just specification about the board they are all here, but if you want to buy a one or more information visit this website Here.

This is the home page for the SparkFun three-axis autopilot development board developed by Bill Premerlani. This board comes with a dsPIC30F4011 CPU, an MMA7260 three axis accelerometer and 3 ADXRS401 gyros already soldered as shown in the picture. It is intended for the do-it-yourselfer. By itself, it can be used to develop a three axis IMU controller. With the addition of an EM406 GPS receiver it can be used to develop a UAV controller for an RC car, plane, or boat. It comes with self-testing firmware that serves as a starting point for you to develop your own control and navigation firmware.

For a flight Testing information information, read this blog.

Note: All firmware is available for both the previous "green" version of the UAV DevBoard with the ADXRS401 gyros, and the new "red" version with the LISY300AL gyros. Each zip file has both a corresponding "green" project and a "red" project.

A guide for getting started with PIC programming, and what to do if you get ICD2 errors.

Source code (C) for MatrixNav RTL firmware for either the red or green board is here.

Documentation for MatrixNav RTL firmware is here.

Source code (C) and documentation for AileronAssist RTL firmware for either the red or green board.

Firmware and documentation for the roll-pitch-yaw demo for either the red or green board.

The direction cosine matrix discussion forum is here.

Several technical papers by Mahony on the theory behind computing and using direction cosines.

A draft of an explanation of the direction cosine matrix algorithm.

-------------------------------------------

Additional equipment:

We highly recommend the following items to accompany this product:

• 20-Channel EM-406A SiRF III GPS Receiver
• USB/RS232 ICD2 for programming and debugging (you’ll need the low-level hardware debugging)
• An RC car, plane, or boat
• If you’ve never played with GPS before, we also recommend getting an ET312 evaluation board just so you can instantly view and understand the SiRF NMEA or binary communications protocols

Features:

• Connection for a 20-Channel EM-406A SiRF III GPS Receiver
• PIC dsPIC30F4011 Controller (with onboard 3.3V and 5V glue logic)
• 16 MHz on board oscillator and 120 MHz oscillator built into the dsPIC
• MMA7260 three axis accelerometer
• 3 ADXRS401 gyros
• 4 Input, 3 output PWM points
• 6-Wire ICSP debug header
• 2 Separate colored status LEDs
• 3 General purpose switches
• On board 3.3V and 5V regulators (150mA max)
• 10m Positional Accuracy / 5m with WAAS
• GPS Outputs NMEA 0183 and SiRF binary protocol
• Spare USART connection for debugging
• 4 Spare digital I/O pins for debugging

Dimensions:

• 1.5×2.8×1.0 (max) inches
• Weight: 34 grams (controller&GPS)

Supporting documents

• GPS UAV2 Manual Part1.pdf for the “green” board
• Hardware schematic for the “green” board
• Self testing guide
• Self-testing code (C) for the “green” board

For my future research path, i have two option available:

1) which is just dedicated to localization using WSN and it’s application in UAV, UGVs (more DoD stuff) or..

2) Fusion of indoor location aware Wireless Sensor Network Fusion with Web 2.0 technologies and create web 4.0 or Sensor Web (What Ever) ( more commercial..)

This paper i found from webofthings.com it is kind of related with my second option of sensor web fusion.

“Abstract—Wireless Sensor Networks (WSNs) have promising industrial applications, since they reduce the gap between traditional enterprise systems and the real world. However, every particular application requires complex integration work, and therefore technical expertise, effort and time which prevents users from creating small tactical, ad-hoc applications using
sensor networks. Following the success of Web 2.0 “mashups”, we propose a similar lightweight approach for combining enterprise services (e.g. ERPs) with WSNs. Specifically, we discuss the tradi
tional integration solutions, propose and implement an alternative architecture where sensor nodes are accessible according to the REST principles. With this approach, the nodes become part
of a “Web of Things” and interacting with them as well as composing their services with existing ones, becomes almost as easy as browsing the web.”

Check out the original post at Here

Thank you..

-Pratiik

“Most existing programming languages for wireless sensor networks are a nightmare for nonprogrammers,” said Robert Dick, associate professor in the U-M Department of Electrical Engineering and Computer Science. “We’re working on ways to allow the scientists who actually use the devices to program them reliably without having to hire an embedded systems programming expert.”

Finding an embedded systems expert to program a sensor network is difficult and costly and can lead to errors because the person using the network is not the person programming it, Dick said. The cost and disconnect associated with the situation means these networks aren’t being used to their full potential.

Lan Bai, U-M doctoral student in electrical engineering and computer science, will present a paper on the new programming languages on April 13 at the Conference on Information Processing in Sensor Networks in St. Louis.

Modern wireless sensor networks, which have become more common in the past five years, allow researchers to monitor variables such as temperature, vibration and humidity in real time at various points across a broad environment. The sensors range in size from several centimeters across to several inches. Unlike passive radio frequency identification, or RFID tags, these active sensors can compute and communicate with each other through radio.

Civil engineers are working on using wireless sensor networks to monitor vibration in bridges to keep tabs on their health.

To create their language, the researchers examined the variables that a scientist using a sensor network might want to monitor, and the areas in which the scientist might need flexibility. They identified 19 of these “application level properties.” They then grouped them into seven categories, or archetypes. They’ve essentially broken up the main programming language into seven archetypes that zero in on specific types of monitoring that different researchers might use. They wrote a language for one archetype and are working on others. They call their first language WASP, which stands for Wireless sensor network Archetype-Specific Programming language.

In WASP, scientists tell the system what they want it to do, rather than how they want it to complete the task.

“Scientists enter the requirements and our system sorts out the implementation details for them automatically,” Dick said.

In a 56-hour, 28-user study that they believe to be the first to evaluate a broad range of sensor network languages, the researchers compared novice programmers’ experiences with WASP and four common, more complicated languages.

On average, users of other languages successfully completed assigned tasks only 30 percent of the time. It took those who succeeded an average of 22 minutes to finish. When using WASP, the average success rate was 81 percent, and it took those who succeeded an average of 12 minutes. That’s a speed improvement of more than 44 percent.

The paper is called “Archetype-Based Design: Sensor Network Programming for Application Experts, Not Just Programming Experts.” Peter Dinda, an associate professor at Northwestern University, is a co-author with Dick and Bai. This research is funded by the National Science Foundation.

I found this intersting article by Johna Till Johnsonon CIO.com, where she tried to give some overview of intelligent sensor network, smart grid, sensor network etc.

Read the article by Johna Till Johnson Here..