Pitfall Traps 2007

From CSL Wiki

Jump to: navigation, search

Contents

Motivation

Pitfall trap arrays at James Reserve are used by biologists to study lizards/amphibians. When a lizard is caught in a trap, they must be released before they dehydrate. So the biologist must check all the traps (which could be in the order of several tens) every few hours, most of the time just to find them empty. Tenet imaging application using Cyclops cameras can help the biologist with their research. Using Tenet application, you can visually check every trap remotely on a web browser, saving you the time, effort and frustration.

Logistics

Schedule

  • Aug. 15th - Visit JR for site survey.
  • Sep. 5th, 12th - Off-line meetings at UCLA (packaging, testing, etc)
  • Sep. 17th ~ 19th - JR deployment

Deployment scale

  • For our first deployment, we will have,
    • 1 array, (of pitfall traps in star conf.)
    • 7 tenet/cyclops nodes, 1~2 stargates, 1 laptop

Deployment duration

  • for 3 days, daytime only (7am ~ 7pm)


People

  • Shaun Ahmadian
  • John Hicks (johnhicks [at] gmail.com)
  • Jeongyeup Paek (jpaek [at] enl.usc.edu)
  • Marcos Vieira


Software / Application

Mote(Micaz/Cyclops) binary

Micaz
Mote runs 'Tenet', re-compiled with the 'CYCLOPS_HOST=1' option turned on.
We did need to cut off some RAM usage (reduce neighbor/routing table size).

 TOSH_DATA_LENGTH was set to '64' bytes, 
 - which can contain upto 40 bytes of image fragment data.
 - So, 128x128 B/W image requires 410 packets.

 64 - 40 = 
   8 byte routing header +
   6 byte transport header + 
   4 byte tenet attribute header + 
   6 byte cyclops response header

Cyclops
128x128 Black&White image.
Use default camera setting.
LED flash used (on 5 nodes, not on 2)
Max. fragment size = 40 bytes.

Tenet Imaging Application

We will run Tenet imaging application with background subtraction based object detection alg.

Tenet task: "wait(120000, 1)->image_detect(1,0,1,128,8)->count(2,0,1)->mod(2,2,'15')
             ->eq(2,2,'0')->or(8,8,2)->store(8,5)->deleteattributeif(8,2)
             ->deleteattributeif(8,8)->send(1)->retrieve(5)->not(5,5)
             ->deleteactivetaskif(5)->deleteattribute(5)->image_detect_reset()
             ->image_fetch(0,0,40,16,128,128,9,167)->send(2)"

It says,

  1. repeat every 120 seconds,
  2. take new image and detect object (using background subtraction alg.)
  3. count how many times we are doing this, and check every *15th run (which means 30minute)
  4. store that result (whether detected or not)
  5. delete the result, if detected || 15th run
  6. send the result, otherwise
  7. retrieve result (whether detected or not)
  8. delete the result, if NOT detected
  9. fetch the image and send_reliable, otherwise.

which means,
"Takes images every 2 minutes, and transfer image only if some change has been detected in the image. In addition to this, transfer an image every 30 minute. We used background subtraction alg. for image detection".

Pitfall Trap Data Visualization

  1. Images on Internet - jpaek
  2. Images on local-machine web browser - jpaek
    • We can see the incoming image on the laptop at the lodge.
    • a script will periodically generate a new html page, which will have the two most recent images from each mote.
    • when new images are created (detect by counting the number of images), laptop make a phone-ringing sound to notify the user.
    • there might be inconsistency between web & local b/c current script does "scp & mv". If a new image is generated at a time between scp and mv, those files might be mv'ed without being scp'ed.
  3. Backup/Logging
    • Need to do this.


Wireless configuration (802.11b & 802.15.4)

  • For 802.11b,
    • channel 1, ad-hoc mode, essid James, key off.
      • demo_adhoc mode for ORINOCO card
      • pseudo_ibss mode for SMC card
    • IP configuration:
      • static IP routing
      • laptop: 6.0.0.200
      • stargates: 6.0.0.202, and backups.. 6.0.0.201, 6.0.0.203
  • Micaz's will use channel 26 (most far away from 802.11b)


Hardware

Stargate packaging for JR deployment
Enlarge
Stargate packaging for JR deployment
Trap lid with mote/cyclops/antenna
Enlarge
Trap lid with mote/cyclops/antenna
  • 7 Pitfall trap lid package (UCLA)
    • materials/construction/batteries
  • 7 cyclops (UCLA)
  • 8~9 micaz (USC)
    • 7 for Tenet nodes with cyclops,
    • 1~2 for BaseStation node on stargate(s).
    • Purchased 8 2.4 GHz RP-SMA antennas from Digikey: 730-1005-ND
  • 1~2 stargates (USC)
    • with Tenet software installed
    • packaging with car battery (UCLA)
    • 802.11b setup
      • with ORINOCO 802.11b card + external antenna, or
      • with SMC 802.11b card + external antenna
  • 1 laptop (USC)
    • will be the base machine that runs the applications, scripts, and web browser.
  • 2.4 GHz antenna for 802.11b at the lodge??.


Tests

Record all the test/experiment results here.

In-lab test with 3 micaz nodes (Aug. 13 -- jpaek)

  • 1 micaz can send 50pkts/sec reliably at 1-hop.
  • 2 micaz nodes can send around 35~40pkts/sec (per node) reliably at 1-hop.
  • 3 micaz nodes can send around 28~30pkts/sec (per node) reliably at 1-hop.
  • With 3 cyclops nodes, transferring images(128x128 B/W) every 30sec is feasible.

Connectivity test at JR (Aug. 15 -- jpaek, john, marcos)

JR pitfall trap mote topology
Enlarge
JR pitfall trap mote topology
JR pitfall trap mote topology, from different angle
Enlarge
JR pitfall trap mote topology, from different angle

0. General Experiment Setup

  - All testing was done on the pitfall trap array closest to the lodge.
  - All testing was done with Tenet applications: 
    >> 'deliverytest', 'pingtree', 'imaging'.

  - 7 Micaz Tenet motes
    -- 3 with cyclops, 4 without.
    -- motes were directly on the ground
    -- default antennas (unless stated otherwise)

  - 1~2 Stargate(s) 
    -- with Micaz BaseStation (default antennas, unless stated otherwise)
    -- Orinoco 802.11b card, with ~5inch 802.11b antenna
    -- static IP routing between stargates (when two were used)

  - Topology

             4
             |
             |
             2
             | BS
             | 
     7---6---1---3---9

    -- Single base-station was placed near node 1, between 2 and 6.

  # NOTE:
    -- As you can see from the picture, node 4 was behind some trees 
       with foliage, blocking line of sight from the base station.
    -- the ground level of node 2 and 4 were higher than any other nodes.

  # NOTE: The results presented below are NOT necessarily in the order 
          of the experiments conducted.


1. TEST-1: All motes with default antennas

  - 7 Tenet micaz, 1 stargate/basestation
  - all motes with default antenna.

  = RESULT: 
    == Failed to connect to all nodes.
    == Node 4 was unable to connect to the base station.
    == Connectivity to node 9 and 7 was also flaky.

  + There were two ways to overcome this: either...
    ++ use taller antennas, or
    ++ put additional stargate/basestation.


2. TEST-2: BaseStation mote with taller antenna.

  - 7 Tenet micaz, 1 stargate/basestation
  - all Tenet motes with default antenna.
  - ## BaseStation mote with taller antenna.

  = RESULT with Best-effort transport:
    # mote 1:  100.0% recv'ed (goodput  9.9 pkts/sec)
    # mote 2:   99.5% recv'ed (goodput 10.5 pkts/sec)
    # mote 3:   99.5% recv'ed (goodput 10.8 pkts/sec)
    # mote 4:   66.5% recv'ed (goodput  5.1 pkts/sec)
    # mote 6:  100.0% recv'ed (goodput 10.9 pkts/sec)
    # mote 7:   99.5% recv'ed (goodput 10.7 pkts/sec)
    # mote 9:  100.0% recv'ed (goodput 11.0 pkts/sec)

  = RESULT with Reliable stream transport:
    # mote 1:  100.0% recv'ed (goodput 10.8 pkts/sec)
    # mote 2:  100.0% recv'ed (goodput 10.2 pkts/sec)
    # mote 3:  100.0% recv'ed (goodput 10.8 pkts/sec)
    # mote 4:  100.0% recv'ed (goodput  6.6 pkts/sec)
    # mote 6:  100.0% recv'ed (goodput 10.8 pkts/sec)
    # mote 7:  100.0% recv'ed (goodput 10.6 pkts/sec)
    # mote 9:  100.0% recv'ed (goodput 11.0 pkts/sec)

  = RESULT:
    == All motes are connected, but node 4 has insufficient reliability.
    == node 4 can provide ~6pkts/sec, while others 10pkts/sec 


3. TEST-3: BaseStation & 2 motes with taller antennas.

  - 7 Tenet micaz, 1 stargate/basestation
  - 5 Tenet motes with default antenna.
  - ## 2 Tenet motes (node 4, 9) with taller antennas.
  - ## BaseStation mote with taller antenna.

  = RESULT with Best-effort transport:
    # mote 1:   99.6% recv'ed (goodput 10.5 pkts/sec)
    # mote 2:  100.0% recv'ed (goodput 11.0 pkts/sec)
    # mote 3:  100.0% recv'ed (goodput 10.9 pkts/sec)
    # mote 4:   99.6% recv'ed (goodput 10.5 pkts/sec)
    # mote 6:  100.0% recv'ed (goodput 10.9 pkts/sec)
    # mote 7:  100.0% recv'ed (goodput 10.9 pkts/sec)
    # mote 9:  100.0% recv'ed (goodput 10.9 pkts/sec)

  = RESULT with Reliable stream transport:
    # mote 1:  100.0% recv'ed (goodput 8.5 pkts/sec)
    # mote 2:  100.0% recv'ed (goodput 9.7 pkts/sec)
    # mote 3:  100.0% recv'ed (goodput 9.6 pkts/sec)
    # mote 4:  100.0% recv'ed (goodput 8.9 pkts/sec)
    # mote 6:  100.0% recv'ed (goodput 10.0 pkts/sec)
    # mote 7:  100.0% recv'ed (goodput 9.8 pkts/sec)
    # mote 9:  100.0% recv'ed (goodput 9.9 pkts/sec)

  = RESULT:
    == All motes are well connected, allowing ~9~10 pkts/sec


4. TEST-4: TWO stargates/basestation.

  - 7 Tenet micaz, 2 stargate/basestation
  - 2 stargates (2 BaseStation motes with DEFAULT antenna)
  - 4 Tenet motes with default antenna.
  - ## 3 Tenet motes (node 2, 4, 9) with taller antennas.

  - Topology:

             4
             |
         BS2 |
             2
             | BS1
             | 
     7---6---1---3---9

  = 'pingtree' tenet-application result:

    [203]
          \--- 2
          \--- 4

    [202]
          \--- 1
          \--- 6
          \--- 7
          \--- 3
          \--- 9

  = RESULT with Reliable stream transport:
    # mote 2:  100.0% recv'ed  (goodput 13.1 pkts/sec)
    # mote 4:   99.0% recv'ed  (goodput 11.6 pkts/sec)
    # mote 1:  100.0% recv'ed  (goodput 12.6 pkts/sec)
    # mote 6:  100.0% recv'ed  (goodput 12.8 pkts/sec)
    # mote 7:   99.5% recv'ed  (goodput 12.3 pkts/sec)
    # mote 3:  100.0% recv'ed  (goodput 12.7 pkts/sec)
    # mote 9:  100.0% recv'ed  (goodput 12.5 pkts/sec)

  = RESULT:
    == All motes are well connected, allowing ~10~12 pkts/sec

distance from lodge to first array
Enlarge
distance from lodge to first array

5. TEST-5: MicaZ radio connectivity from the array directly to the lodge.

  - 1 stargate back at the lodge
  - 2 motes at the array, directly connected to the stargate at the lodge

  = RESULT with Best-effort transport
    == Round1:
      ## mote 1:   77.0% recv'ed  (goodput 7.1 pkts/sec)
      ## mote 3:   44.0% recv'ed  (goodput 8.7 pkts/sec)
    == Round2:
      ## mote 1:   91.0% recv'ed  (goodput 8.2 pkts/sec)
      ## mote 3:   87.5% recv'ed  (goodput 9.7 pkts/sec)
    == Round3:
      ## mote 1:   71.5% recv'ed  (goodput 4.7 pkts/sec)
      ## mote 3:   93.5% recv'ed  (goodput 4.9 pkts/sec)

  = RESULT with Reliable stream transport
      ## mote 1:  100.0% recv'ed (goodput 6.6 pkts/sec)
      ## mote 3:  100.0% recv'ed (goodput 6.0 pkts/sec)

  = RESULT:
    == With taller antennas, motes at the array can reach the stargate
       (basestation) placed at the lodge. However, the connectivity and
       hence the goodput degrades noticeably.
    == Considering the fact that we would want to do larger scale deployment
       in the future spanning several pitfall trap arrays (which are farther 
       away in distance), we definitely want to place at least one stargate
       per array. Then we can relay all the data back to the lodge using
       802.11 network.


6. TEST-6: 802.11b connectivity from the array to the lodge.

  - 2 stargates, one at the array, the other at the lodge
  - ORINOCO 802.11b cards, with small external antennas
  - Test done with 'ping -i 0.1 -s 128'
 
  = RESULT: GOOD  :-) 
    == ORINOCO 802.11b connectivity with external ~5inch antenna was good.
    == Connectivity without external antenna required one relay node.


7. Overall Comments:

  - We should plan for placing at least one stargate/basestation at the array.
    This requires consideration for packaging, power, external antenna, and 
    water-proofness for the stargates. We will place one stargate at the lodge
    for data collection, network management, and the application.
  - If we use "pitfall trap lid antennas" on the MicaZ motes, and place a 
    stargate at the array, we believe that the radio connectivity will be ok.
  - Placing two stargates at the array did not provide much increase in 
    achievable goodput. (9~10 --> 10~12pkts/sec)


In-lab tests with 7 nodes (micaz&cyclops) (Sep 3 ~ 5 -- jpaek)

Notes after conducting several overnight (7~10 hours) tests

  • We can run 2 applications concurrently (every 30min + every 2min w object detection)
  • In general, things are working fairly well. But the motes occasionally crashes. Need to identify the bug.
  • 9pkts/sec was too much on the edge and not safe. we should go for 7~8pkts/sec. We can consider using 2 stargates at the array


Object detection test in dark, with the bucket (Sep. 6 -- jpaek, john, shaun)

  • The LED flash light on the cyclops are pretty good. It can brighten up the bucket well enough for the object detection algorithm to work.


The Deployment (Sep. 17~19)

(Shaun, John, Marcos, Jeongyeup, Sharon)
The deployment was not so successful. We did catch one spider and learned many lessons, but it is dissappointing that we cannot re-try until next Spring. We should try larger network spanning several arrays next time.


Collected cyclops Images

We have collected total of 589 cyclops images. Let's look at the cyclops-images vs. time, in reverse order.
In the 'image-generation vs. time' plot, colors represent different runs, stop and re-start of app.
Usually, a single vertical line means that I manually fetched one image from every node just to check whether they are running. We had several restarts, whenever we thought something was wrong.

Wednesday: (Morning data)

imagetimeplot.wed.png

  • One incomplete image from node 106 at 7:15AM.
    • mote106_tid281_001.jpg
    • I believed that the battery level was low on some of the nodes. So I changed the batteries and re-ran the application.
  • Most of the image-detection are due to changes in sun-light/shadow, and others were intentionally triggered by us.
    • For example, compare the sun/shade changes in the following four images:
    • mote105_tid287_009.jpg mote105_tid287_010.jpg mote105_tid287_011.jpg mote105_tid287_012.jpg
  • All images: http://enl.usc.edu/~jpaek/data/cyclops/pitfall_trap_2007/images.wed/list.php


Tuesday: (Afternoon data)

imagetimeplot.tue.png

  • SPIDER was caught in node 102, at around 7:45PM.
    • You can see that object-detection was continuously triggered between 7:45PM ~ 8:40PM, for node 102. Check images between 007~015.
      • mote102_tid267_007.jpg mote102_tid267_008.jpg mote102_tid267_009.jpg mote102_tid267_015.jpg
  • It became dark around 7:00.
    • Node 105 and 107 were continuously generating images (object-detection triggered) in the dark because they did not have LED-Flash.
      • Our background subtraction based object detection algorithm has infinite false-positives when dark. See everything after
      • Node 105: mote105_tid267_009.jpg mote105_tid267_010.jpg
      • Node 107: mote107_tid267_009.jpg mote107_tid267_010.jpg
  • We closed the trap lids at around 8:40 ~ 8:50PM.
    • I think we have accidentally reset the power of node 102 while doing this. This is the reason that we don't have images between 8:40~10:00PM.
  • I also have the images from the morning experiments, but unfortunately, I overwrote the file modification time. (I cannot plot time)
    • Tuesday morning is when we have experience 802.11b SMC card outage couple of times and decided to move to Orinoco card.
  • All images: http://enl.usc.edu/~jpaek/data/cyclops/pitfall_trap_2007/images.tue/list.php


Monday: (Afternoon, the first day)

imagetimeplot.mon.png

  • Not so nice data.
    • As you can see from the figure, we have started/re-started the app. several times between 2pm ~ 6pm.
    • Particularly, node 101 had some connectivity problem.
    • We started the deployment around 1:30PM, tried starting the app. at around 2:30Om, and stopped the app. at around 7pm.
  • All images: http://enl.usc.edu/~jpaek/data/cyclops/pitfall_trap_2007/images.mon/list.php


802.11b Connectivity (SMC vs. Orinoco) issue

  • What setups did we try? (widen your browser to see the following images in 2-by-2)

Picture1.jpg Picture2.jpg Picture3.jpg Picture4.jpg

  • When we first started with setup-1, we encountered mote connectivity problem;
    • direct link from node 101 to stargate 202 seemed bad (that is what I thought),
    • while 802.11b connection seemed fine.
  • Then we tried setup-2, and this worked!!.... for couple of hours... and failed.
    • We tried this setup because placement of 203 created line of sight between 202 and 203, and between 101 and 203.
    • The application failed after some time, but we were not sure why. So we re-started, again with setup-2. Note that time elapsed between every decision is at least couple of hours.
  • After experiencing application stoppage several times, we decided to try Orinoco cards.
    • because I believed that there is some problem with the SMC.
    • Orinoco worked for longer time, till the time we left JR.


Object detection algorithm (background subtraction)

  • As you can see from Tuesday data above, infinite false positives when completely dark.
  • As you can see from Wednesday data above, detects changes in sun light / shade.
    • --> correct behavior in some sense.
  • Since we didn't have any lizards, we have no sense about false negatives.


The mistakes and the lessons

  1. Changing the 802.11b card from Orinoco to SMC
    • We should not have switched from the Orinoco card that have been tested to work at both VTB and JR, to the SMC card that we were not sure about.
  2. Background subtraction alg. as object detection
    • Not very great... detects sun, shade... infinite false-positive when completely dark.
  3. Bad handling of the image data
    • I relied on the linux-file-modification time for time-stamping the cyclops image files. A false 'cp' command resulted in loss of half-day worth of timestamps. I should have logged the file creation time somewhere else.
  4. Cold weather
    • The temperature was much lower than the week before the deployment. We should have anticipated this.


Directions to JR

MAP: http://maps.google.com/maps?f=q&hl=en&q=Lake+Fulmor,+CA&sll=33.796875,-116.777031&sspn=0.090371,0.067291&ie=UTF8&z=17&iwloc=addr&om=1

Take Interstate 10. Exit at 8th Street exit. Turn right on 8th Street and continue a short distance to the first stop sign. Turn left on Lincoln until the next stop sign (approximately 1/2 mile). Turn right on San Gorgonio Avenue (State Highway 243) and once the road begins climbing the mountain grade continue for approximately 15 miles. When you get to Lake Fulmor Picnic Area (US Forest Service), turn left into the handicap parking lot (this is across the street from the main parking area). Pull up to the gate with the sign that says "ROAD CLOSED" and unlock the gate using the combination that has been provided to you in advance. We change the lock combination frequently so call or email before your visit. Unlock the gate and drive forward, then lock the gate behind you. Continue on the uneven dirt road until you reach a second locked gate constructed out of chain link fence. The same combination applies to this gate. Again, please lock the gate behind you. Continue to the end of the road (about 1/4 mile) and check in at the Trailfinders Lodge.


Pictures


RDSCN1300.jpg
RDSC00314.jpg
RDSCN1319.jpg

Personal tools