Mote Sensor Network
Overview
The general design of the program is to obtain a photo, temperature, moisture, and power readings every 8 minutes and store the results in an array using run length encoding. Once the arrays fill up with data or the maximum time has passed, a packet is sent out over the RFM to the base station that forwards the messages on to the server via the UART.
People
Waylon
Brunette
Jason Jenks
Links
Other useful links:
Summary
The goal of the project is to produce a working prototype sensor network for the Plant Care project. For this task we will be using the Berkeley Rene Motes programmed with TinyOS. To collect the sensor data, the motes will need to interface with the photo resistor, thermistor, an irrometer (moisture sensor) and an inductively rechargeable power source (battery pack). The program running on the motes will then use run length encoding to store the information from the ADC conversions on the mote until there is enough information to fill up a data packet. The data packet will then be sent over the RFM to a computer that will process the data and use a server to determine appropriate actions. There will be different types of messages so the server will become aware of the fact that the robot is present or that the mote is about to die because of low power. One more will run a special program and act as a base station and forward the data packets from the RFM over a serial connection to a computer. The embedded program must also worry about how low the mote’s power source is getting and send off a distress signal if needed. One major design focus for the mote program is low power usage. Examples of power conservation are run length encoding of data to help compact the data space and turning off the irrometer when not in use.
Basics of the Plant Care Project
The goal of the Plant Care Project is to provide a self-contained actuation feedback loop where the system is self-calibrating and self-sustaining and hopefully requires no user intervention. Plant Care will be used as a platform to do research in the areas of localization, decoupled system design, system health and monitoring, smart environment, robotics and a whole lot more. The basic feedback loop design for the initial stage of development is represented in the diagram below.
Component Design
· MOISTURE
The moisture component is designed to turn on the irrometer and delay for a period of time until the pressure transducer has time to stabilize so that an accurate reading can be obtained from the ADC. The module then takes the ADC reading and turns the power off to the irrometer because the amount of power drawn by the irrometer is large.
· PLANT_BASE
The base station is designed to receive the packets from the sensor motes on the network and forward them onto the UART so that the serial port of a computer can get the sensor information from the mote network.
· PLANT_SENS_OUTPUT
The program is designed to use the ADC to obtain photo, temperature, moisture, and power level readings and then to send the readings over the RFM to the base station that will forward them on to a host computer.
The sensor readings are returned from the ADC as a 10-bit number. However the program rounds and reduces the reading to an 8-bit number so that it can be stored in a single byte. The data is then stored in separate arrays for the each type of sensor using run length encoding. The arrays are made up of structs, where each struct has a reading and frequency value. If a new sensor reading is the same as the former sensor readings in the array, then the frequency of the matching reading is incremented. If the sensor reading is different it is appended to the array.
There is a clock event generated approximately every 8 seconds, this is the maximum time interval possible between clock events. The program has a counter that it increments until 8 minutes have passed, it then fires a get_photo_data event. After the photo data is returned and stored the get_temp_data event fires. Similarly the get_moist_data and get_power_data is processed.
Once all the data from the four sensors are collected the program checks to see if one of the send conditions for a data packet is met. The send conditions are: if one of the data arrays is full, the maximum time interval has been met, or if there is not enough room in the packet to store the 4 possibly new sensor readings.
Depending on the state of the sensors the motes will send out different types of packet. (different packet number) One type is for just normal data readings, another is for if the robot is present, and a third for if the mote is almost out of power.
The overall design of the module tries to ensure reliable execution with the limitations of TinyOS. Tasks, locks, and restart methods are utilized to ensure that if a serious of events happens that the program can always make it back to a know state.
· POWER
The power module has 2 functions, one is to read the line that goes high when the robot is present inductively recharging the super caps of the mote power source. The second is to use the ADC to obtain a reading of the current voltage level available from the super caps.
Network Design
· PACKETS
The packet is designed to allow flexibility in the types of readings it sends. The current packet includes the 3 bytes that TOS uses to send the packets. The packet also contains bytes for the mote address the packet originated from, the number of times the packet has been sent, and the sequence number of the packet. (Sequence numbers range 0 to 15) The packet then contains an array of 35 sensor reading structs. To allow the size of each array of readings to vary a spacer (reading=0 and frequency=0) is used to determine when one type of the sequence of readings(e.g. photo) ends and the next one begins(e.g. temperature). This means the maximum number of readings that the data packet can hold is 32.
‘Data’ packets use Active Message type 4, ‘Robot is Present’ packets use Active Message type 7, and ‘Power is low Distress’ packet uses Active Message type 6. All the packets are acknowledged immediately by the base station after reception with Active Message type 10.
· ROUTING (NOTE: Routing was removed in the current version because of conflicts with localization)
The routing algorithm is based on the least number of hops to the base. Each time the sensor readings are executed the routing algorithm sets the current number of hops to the maximum of 127. If a routing packet comes in to update the route, the program checks to see if the current number of hops is greater than the hops in the route update packet. If the route update packet has a smaller number of hops the mote updates its route to the new route and broadcasts out a new route packet updated with itself as another hop in the route.
To start the route update process PLANT_BASE sends out a routing update packet after a specified time interval. The packet includes the mote address and the fact that the base is 1 hop away. PLANT_SENS_OUTPUT checks to see if the route is shorter than its current number of hops, if it is it stores how many hops the mote is away from the base and the mote address that is the next hop in the route. Routing update packets use Active Message number 10.
Mote Programs
- PLANT_SENS_OUTPUT
PLANT_SENS_OUTPUT uses the CLOCK, PHOTO, TEMP,
PLANT_BASE
PLANT_SENS_OUTPUT uses the CLOCK,
Major Difficulties
n The Plant Care project will be used for localization research. A redesign of the message and network system with one week left to the due date was requested because different motes will be used for localization. The redesign was needed because of the amount of power consumed when receiving a message would be too great on the rechargeable battery sources of the plant sensor motes as compared to the localization motes plugged into AC. This gave us very little time to redo the program and integrate it with the hardware.
n The irrometer and power supply hardware arrived late which gave us about 4 days for integration testing.
n Power on Reset on the RENE motes generation 1 does not work properly
n To save power after the redesign we tried to get RFM Power down is appears to have bugs in its TinyOS implementation.