2008 Summer@CENS Project Development

From CSL Wiki

Jump to: navigation, search

Contents

[edit]

SUMMER@CENS: a research program

This wiki is designed to assist in the dialog regarding development of projects for this summer's high school and undergraduate research programs. Project development Team please feel free to add/edit.


The Summer@CENS Research Programs include the CENS Undergraduate Research Program and the CENS High School Scholars Program. The primary goals for our programs are to provide underrepresented US students the opportunity to conduct forefront research and engage in a scientific community with peers, graduate students and faculty. The research program is designed to increase the number of underrepresented US students who pursue graduate education in engineering and physical sciences.


[edit]

Logistical details

Program length: 8 weeks

Start Date: Monday, June 23, 2008

End Date: Friday, August 15, 2008

Number of participants:

  • 12 undergraduates (2 Returning Intel Scholars)
    • Charisse Carter, Jennifer Chandler, Suming Chen, Joey Degges, Oscar Herrera, Nan Jia, Saro Miguerdichian, Edi Rocha, Victor Shia, Senglong Taing, Kelsey Whitesell, Michael Wilson
  • 1 Zeizhang University undergraduates (tentative: July 5 - September 10)
    • Zheng Guan
  • 15 high schoolers
    • Sophie Gerrick, Guadalupe Hernandez, Ian Cinnamon, Paul Ashla, Taylor Savage, Ashley Davis, Carlos Gomez, Christian Rodriguez, Adam Brenner, Isaac Kim, Jeffrey Lee, Nataly Parra, Shreyasi Ghosh, Brendan Kutler, Rutna Gadh

Important Dates: Program Calendar

  • Orientation = Monday, June 23
  • Mentor Orientation = Monday, June 23 (required of all mentors)
  • Lab welcome = Tuesday, June 24
  • CENS Tech Camp = Wednesday, June 25 and Thursday, June 26 (mentors welcome)
  • Lab Immersion = Friday, June 27
  • Development Workshops = TBD - Typically Wednesdays from 12:00 - 2:00 PM
  • Focus Group Discussion = Thursday, August 14
  • Poster Session & Paper Deadline = Friday, August 15 - 12:00 - 2:00 PM
  • Final Dinner = Friday, August 15 - 5:00 - 7:00PM
  • Fridays - Weekly Progress Meetings (Interns will present progress to group 2 x over the summer for a total of 4 WPMs through summer)
[edit]

Project Descriptions

(*) Project Lead(s)

[edit]

Project: CycleSense for a Healthier Bike Commute

Nithya Ramanathan, Sasank Reddy* , Vids Samanta and Katie Shilton*

Project Summary: Add system components to the Campaignr framework to support the bikeability campaign in Los Angeles

With the help of bikers in Los Angeles, CENS is building CycleSense, a technology to help bikers plan safe routes and collect data to improve those routes. Bikers carry a GPS logger or a mobile phone equipped with GPS technology during their commute. These tools automatically upload their routes to a secure website. Participants can log in to their private website see their route combined with existing data, including air quality, time-sensitive traffic conditions, and aggregate traffic accidents along the route.

Participants can also use mobile phone technologies to help improve their routes. Bikers can document hazards and impediments along their way by taking photos with a mobile phone or sending a text message to CENS servers. This information will help CENS improve its maps and models so that all bikers in the region will benefit from these bike-centric updates.

Combining existing Los Angeles conditions with biker-contributed data, CycleSense will allow area bikers to:

  • Plan routes with the least probability of traffic accidents
  • Plan routes with the best air quality Plan routes according to personal preferences, such as maximum shade, connections with public transportation, or available bike racks
  • Contribute to the safety and well-being of the Los Angeles bike community

Want to Document

  • Route Proximity to Traffic. See these two links here and here
  • Route Particulate Exposure. How exposed you get to car fumes; leverage PEIR here directly.
  • Route Exercise Monitoring. A lot of these sites simply use your speed and elevation as a measure of how hard the route is or how much exercise it can provide. Could we infer this from GPS altitude information and maybe use accelerometer in some smart way?
  • Route Safety Marking. Places where there are problems - ie. bad roads, bumps, difficult intersections, etc...

Data source: GPS data, Tag Initial Campaign Users: 10-15 Target: Daily commuters Duration: 1 month (Ready-August) Nokia Workshop Mid August

Some useful websites..These are good for UI mockups, things we should consider when monitoring, etc.. The first one is interesting..

Research Question(s) :

(1) CycleSense Sensors - Sasank (mentor), Suming Chen (ugrad), Nan Jia(ugrad)

Background: We are going to be using cell phones to enable Bikers monitor their route. We imagine that data collection will come in two forms - manual and and automatic. In terms of manual, the user will actually take pictures, add tags, etc.. through user input. In the automatic process, we will use sensors that exist on the mobile phone to monitor various situations. Two sensors that we will concentrate on will be the accelerometer and the microphone.

Inference from Sensors: With the accelerometer, we will want to see if it can be used for two different type of situations - can it identify road roughness and can it be used to find significant bumps along a road. With the microphone, we will first want to simply calculate the decibel noise level and then see if we can identify when a user is around lots of cars / traffic. The first case is fairly simple - we would take a WAVE sample of audio and calculate the decibel level. In the second case, we are interested in finding audio features and then classifying it as different forms of traffic.

Project Specifics: Write scripts that can accept data from the accelerometer or wave files and then perform the inference above. We would like to use open-source components (using libraries that others have used before), have modular code that can be reused for different projects, rigorous so that it is tested in a large set of data sets, and documented so that others could easily pick it up and use it.

There will also be weekly writing assignments. Please mail these writeups to me at the end of each week.

Schedule:

Week 1: Preparation.

Both

Sound

Accelerometers

Week 2: Data Collection. Take appropriate data for your projects.

  • For the case of the accelerometer, we want to gather accelerometer data from the phone (Nokia n95) for various types of roads - smooth, medium roughness, really rough. Furthermore, we want to go over bumps of different grade as well.
  • For the case of sound, we want to gather samples to create a noise map which means taking around a sound meter along with you and recording its level along with getting samples and also we want to gather data of traffic of different levels. For both projects, we want to plot out the initial results to see if we gathered the proper data.
  • Write up background research for your project(s) into a page or so of prose, including properly formatted citations. Share and edit this with each other and with me.

Week 3 and 4: Feature Identification Development. Now we want to actually perform the feature calculation for our projects.

  • For the accelerometer, we want to calculate features (mean, standard deviation, FFT over a time window) for the road measure inference and design an algorithm to find large drops along the Z axis to find bumps.
  • For sound, we first want to write a program to analyze the WAVE file to get decibel level and then for traffic level classification we would gather features similar to the ones outlined in the papers in the background.
  • Write up about your feature identification techniques. What worked and what didn't work in terms of feature calculation and your data collection. What would you do over again if you had a chance to collect data again? Revise your writing in #1 and #2 as well. I will review this with you.

Week 5 and 6: Algorithm Development. Lets create algorithms!

  • For the accelerometer - based on the results from the previous weeks, we will figure out whether we can actually identify different types of roads and/or bumps. Based on that, you will need to create an algorithm that takes the accelerometer data and identifies the types of road and events of bumpiness.
  • For the sound application - at this point you want to take the features we have for traffic levels and apply a machine learning technique. We can use Weka to identify the right pattern classification algorithm and at this point we want to implement the best one in Python.
  • Write up your initial results. Want to revise #1, #2, and #3 based on the results section.

Week 7 and 8: Wrap Up and Documentation. Finish Implementation and document.

  • For the accelerometer - we want to test out the algorithm you developed using different situations. This might involve going out and gathering more data for certain situations to get an idea of how well your algorithm works. Basically, we want to characterize how well the algorithm actually works.
  • For the sound application - we are interested in the performance of your chosen machine learning technique. Where and when does it work better (for instance are there certain contexts that it is better vs places that it is not)?
  • Write up a rough draft of your overall document by end of Week 7. By end of Week 8, we should have a completed version and also a poster to go along with it.
[edit]

(2) Trace Simulator & Power Aware Data Collection

Vids (mentor), Victor Shia (ugrad), Ian Cinnamon (HS)


[edit]
Trace Simulator

Goal Build a simulator that generates traces of commuting.

Description

  • For instance you travel from your house in China Town to UCLA everyday. The simulator should find different routes between these locations drive a car on them some days or consider walking and biking and using buses other days, or a combination.
  • It simulates using a phone with GPS being carried around so should simulate GPS loss, cell tower loss, traffic on the roads, taking different road to avoid traffic, being turned off in some areas to hide location.
  • Evaluation:
    • Compare different route searching algorithms (A*, random walk, Levy Walk) considering modes of transport and bus stops.
    • Compare performance i.e. time to generate a trace.
    • Can we simulate and evaluate selective hiding from Min's paper.

Tools Here are tools you should evaluate and could consider using:

[edit]
Power Aware Data Collection

Goal Make best use of available power while collecting samples of data to meet the requirement.

Description

  • This will involve first characterizing the diffident sensors like imager, audio, gps, gsm, accelerometer, wifi, gprs etc.. on phone for their power consumption. This needs to be systematically:
    • on several phones.
    • different combinations of sensors.
    • different sampling rates.
  • Mine existing data we have in sensorbase that contains battery info.
  • The algorithm should be able to decide based of power consumption which sensors to use to get a result if there is more than one way to get that result. For example I know I can use accelerometer or GPS for activity classification. GPS gives better results, but uses more battery lift. The algorithm should then given the current battery life and these parameters, and how long a trace you want figure out what is the best sampling.
  • Resources:



(3) Image Analysis - Nithya (mentor), Kelsey Whitesell (ugrad), Brendan Kutler (hs)

Goal: Design a tool that accepts an image of a gray colored paper and a gray scale color chart. The tool should infer the color of the paper using the accompanying color chart.

Background: A multi-centered, international group based at UCSD aims to reduce indoor air pollution in village households. Studies of health impacts estimate that indoor air pollution results in as many as 2.5 million pre-mature deaths each year in India. This project plans to replace traditional bio-fuel based cooking methods with inexpensive solar and other energy-efficient cookers in 6,000 homes in rural India. The scientists hypothesize that this simple step will significantly reduce indoor and outdoor air pollution. They will be the first group to attempt to quantify this claim with sensor data. Instruments, consisting of a pump that pushes air through a filter, will be placed in each household to quantify indoor soot levels. Manually collecting, analyzing, and verifying data from each of these sensors is not scalable. Using our technology, cell-phone cameras and image analysis techniques will enable automated, reliable data collection from the filters in all 6,000 homes.

=> Read the Surya White Paper to learn more about the project.

Our Contribution: Participants will use cell phone cameras to capture and transmit images of the air filters to a centralized location for analysis, creating a new kind of sensor. This novel mode of data collection is an improvement over traditional data gathering techniques in several ways. First, soot readings will be obtained using image analysis techniques to extract filter color. This automated approach contrasts with the current method of relying upon highly subjective visual estimates of filter color provided by individuals. Second, time and location stamping of readings, provided by cell phones, will reduce accounting errors introduced through manual data entry. Third, automated integrity checks that ensure image capture and that confirm daily filter replacement, will lead to improved data quality.

=> Read our Surya Participatory Sensing paper to learn more about our contribution.

Project Specifics: Write a script that will accept an image of a color chart and the filter. Using the color chart in the image, the script should determine which color the filter is closest to. The color chart has 10 gray spots on it varying in intensity and labeled 1..10. The script should also identify images that need to be retaken.

It should be: (1) based on open-source components, using other libraries wherever possible, rather than building new ones, (2) coded in modular pieces that can be reused for different projects (3) tested against a variety of data sets. It is intended to be a tool for other people to use, not simply an experiment.

There will also be weekly writing assignments. Please mail these writeups to me at the end of each week.

Schedule:

Week 2:

(1) research potential software environments and language libraries

(2) Get 2 phones set up

(3)Collect data from the sensor

(4) finish checking out tutorials

(5)find a good survey paper on image analysis techniques and metrics

Week 3:

(1) run/manipulate Kelsey's old C++ image analysis code

(2)understand existing algorithms and write a short summary of them

Week 4-Week 5:

(1) finish the color chart

(2) start writing-designing-testing algorithms in matlab

Week 5-6: (1) translate code to the phones

Week 6-7: (1) put the paper and code in final format

OLD Schedule:

Week 1: Preparation. Do tutorials for Matlab and C as needed. If you have never used matlab, you may want to start with these two short tutorials: [1] and [2]. Focus on the image procesing toolkit. Read the background papers provided in the Background Section above. Check out papers on region growing and [http://www.cis.upenn.edu/~jshi/software/ normalized cuts]. These are computer vision techniques you may find useful.

Write about yourself, and about the interpretation of participatory sensing and your project. Share this with each other and edit it for grammar, structure, and clarity.

Week 2-4: Algorithm Development. Take a couple of images of the color chart and different filter colors with a high resolution digital camera and the camera on the N80. Try images under different light conditions and vary other parameters that you think might impact the algorithm. Start testing out image algorithms on these images, maybe in Matlab or R. Determine which algorithm works best for each image and why. Document everything.

Begin with a simple algorithm:

  • Draw a box around each color on the color chart and around the filter paper (get code from Teresa to make this work on Matlab)
  • Collect the pixels from each box and average them
  • Compare the intensity to find which color most closely matches the filter paper

Write up background research for your project(s) into a page or so of prose, including properly formatted citations. Share and edit this with each other and with me. I will review and comment on technical accuracy and clarity. Additionally, revise what's written in #1 based on what you know now.

Week 5-6: Automate Color Extraction. Automate the process of identifying each color on the chart and the filter color. Try region growing, normalized cuts, or K-means.

Write up the problem formulation and initial tests/results, with citations, and review as in #2. Revise what's written in #1 and #2 based on what you know now.

Week 7-8: Implementation. Implement the above algorithm in C and test it out. Include a function to identify images that are not of sufficient quality. This could mean the light was too low, the image was not a high enough resolution, or something else. Identify all possible fault scenarios and write a script to identify each case. Document everything.

Can the fault checking code be run on the cell phone? If so, implement it.

Assemble all of your writing and write your paper.


(4) Correlating outside data sources - Min/Eric (mentor), Senglong Taing(ugrad), Isaac Kim (HS)

Given a location trace of a Bike Route, we want to gather external information from the web that can add value based on the GPS information. We can imagine gathering environmental pollution data, elevation and traffic information, land-use data, traffic information, accident reports, events, etc... The idea here is to create a mechanism to populate the location trace with these additional tags easily with a click of a button.

Schedule

Week 1: Preparation. Do tutorials for python as needed. Read the background papers on GIS. Write about yourself, and about the interpretation of participatory sensing and your project. Share this with each other and edit it for grammar, structure, and clarity.

Week 2-4: Web Service and WSGI development. Begin review publicly available web services and data sources that provide information of value to cyclist. Start developing WSGI based hooks into these services. The following are good starting points:

Some interesting readings:

Week 5-6: Finalize WSGI development, develop testing/validation study for one of the data sources. Write up: Motivation/Purpose, a testable hypothesis, and methods sections.

Week 7-8: Implementation. Conduct testing in terms of performance (how long does it take to gather the data, how often do you have to sample the data from the web, how long does it take to connect the location trace to the data) and finish write up with results, conclusion / discussion, and potential future work sections in terms of your paper. Document all code.

Discussion Topics/Commentary:

  • Would be nice to have interns create a field kit – we would need a couple tablet PCs.

Preparation:

  • Hardware needs:
  • Software/Program needs:
  • Tutorials/materials needed for intern immersion (Should we do a group tutorial in MATLab, provide articles before arriving, etc): C, Python, Nokia programming framework, PHP,
  • Accounts (CENS account, login access, email lists):
  • Lab access, desk space, keys:
[edit]

Project: Portable Image Platform (PIP)

Teresa Ko*, John Hicks, Eric Graham

(requests 3 undergraduates and 3 high schoolers)

Project Summary: Develop deployed platform, onboard algorithms and server side image anal/vis (using Mike Wilsons system with consult by Josh Hyman) and data logging. Focus on pollinators and feeder station.

Research Question(s) (higher level and lower level tasks for undergraduates and high school interns):

  1. Camera Interface - Create an interface between the gumstik and camera to control and capture images.
  2. Data management - Store/transmit raw images/image processing results
  3. User interface - Control and visualize state of PIP from a remote desktop (connected wired/wirelessly) through status indicators and images.
  4. Setup local bird feeder station for experiments
  5. Gather specs of PIP
  6. Run experiments

Preparation:

  • Hardware needs: a linux box for each student, deployment laptop, 3 gumstiks, 3 usbcams, 3 wireless cards, 3 memory cards
  • Software/Program needs: Matlab
  • Tutorials/materials needed for intern immersion (Should we do a group tutorial in MATLab, provide articles before arriving, etc):
  • Accounts (CENS account, login access, email lists): Matlab, Unix
  • Lab access, desk space, keys: desk space for each student, keys to courtyard

Progress Activities:

  • Ramp-up activities:
  • Project group meetings (frequency and location): every Tues, 11am
  • Off-campus Excursions: field deployment/data collection (dates and location): James Reserve for testing
  • Wrap-up/Completion of project activities and indicators: On-site demo/Video of off-site performance.

Discussion Topics:

  1. Recording pollinator visits to flowers seems ideal, because to monitor this activity any camera would have to be moved frequently as flowers fade (although production of fruits where the flowers would be very interesting to document -- success of pollination/ reproduction is a key aspect). Unfortunately, this may requre video and all its associated problems. If onboard processing could capture only the appropriate video based on motion/event detection, then this might streamline the PIP even more (and provide context for algorithm development).



[edit]

Project: Budburst - Plant Phenology

Eric Graham* and Eric Yuen

(request: 2 [maybe 4] undergrads and 2 high-school students)

Project Summary:

Project BudBurst is a national citizen science field campaign in its second year. By having citizens record the timing of stages of development (phenology), such as leafing and flowering of native tree, shrub, and herbaceous species each year, the prevailing climatic characteristics can be determined for locally, regionally, and nationally. With the help of citizen scientists, Project BudBurst will be compiling valuable environmental information that can be compared to historical records to illustrate the effects of climate change.

Hundreds of citizen scientists from across the country participated in the inaugural pilot test of Project BudBurst in 2007, collecting useful scientific data in a consistent manner. The enthusiastic response and robust participation in the pilot effort made it clear that there is sufficient interest from the American public to expand Project BudBurst in 2008. http://www.windows.ucar.edu/citizen_science/budburst/index.html

For Project BudBurst we will design a tool for recording daily plant phenology observations with auxiliary data, such as verification photos, hemispherical canopy images, geo-tagging, commenting, etc. Students will be collecting daily measurements of tagged individual plants of their choice on their routes to and from school or in the CENS courtyard. These plants do not necessarily have to be on the list of Project Budburst target plants but will be used in the tool creation. Daily observations will be recorded with 2 or 3 Cyclops cameras already at the James Reserve (possibly also for transplanted specimens to the CENS courtyard) of Common Yarrow, a target species.


Research Question(s) (higher level and lower level tasks for undergraduates and high school interns):

  1. How can we gather plant observations in a systematic way using mobile devices such as cell phones?
    • Can SMS messages from participants be sent to a single number and parsed for information?
    • Can SMS messages be sent to multiple numbers to parse information (American Idle model of phone-in voting)?
  2. How can we remind participants to re-visit their plants to record observations?
    • Can/should we send them daily SMS or MMS reminders?
    • Can/should we send email messages instead?
    • Can these be automatically generated from a CENS web server?
  3. How can we store their recorded information and display their progress?
    • Can we set up a website to track their information?
    • Should we rely on just the SensorBase web pages for this?
    • Can we receive images from phones as verification of phenology stages and link this to their data sets?
    • How can we connect images collected from a seperate camera with text message input?
  4. Can we get additional information, like local weather summaries or microclimate measurements included?
    • Degree-days and photoperiod are interesting parameters that may tie into phenological events that might be obtained from web-accessible weather records. Can we automatically get this data for a participant's location?
  5. How can we have participants share their data and interest with others who are in the same project, those who are looking at the same plant but in geographically distant locations, or with friends who are not participating but who might next year?
    • Can we tie into Flickr or Picasa or some other social networking system that already exists?
  6. Could this organization of participants be extended to serve as a model for classroom activities for grade school, high school, orundergraduate courses?


Preparation:

  • Hardware needs:
    1. Computer per 1 or 2 students
    2. Simple cell phones that can transmit and receive SMS messages.
    3. Cell phones that can transmit and received MMS messages.
    4. Higher-level hand-held devices, just as the Nokia N80?
  • Software/Program needs:
    1. Computer running Windows or Linux


  • Projects:
    1. Design a system for sending/receiving SMS and MMS messages.
    2. Database for collecting and storing appropriate data (linked to SMS).
    3. Programs for processing information and displaying results.
    4. Web page for initial account establishment (mimic Project Budburst for later integration with them).
    5. Web page for daily data entry.
    6. Hooks into into Flickr for sharing data & community building.


  • Tutorials/materials needed for intern immersion (Should we do a group tutorial in MATLab, provide articles before arriving, etc):
    1. One article on plant phenology and climate change.
    2. Work will be done in Python?
    3. PHP?


  • Accounts (CENS account, login access, email lists):
    1. CENS account


  • Lab access, desk space, keys:
    1. Yes, please, for all students.


Progress Activities:

  • Ramp-up activities:
    1. Get familiar with Project Budburst website and goals
    2. Get familiar with SensorBase and web services


  • Project group meetings (frequency and location):


  • Off-campus Excursions: field deployment/data collection (dates and location):


  • Wrap-up/Completion of project activities and indicators:
    1. Demostrate summer activities to Project Budburst leaders


Discussion Topics:

  1. Campaigner may have software developed for user input. Sasank suggested a Campaigner project where participants locate flowers around campus to make a map of locations that might be interesting to the UCLA community.



[edit]

Project: Malibu Source Tracking Project and/or Coastal Quality Management

Christine Lee, Nithya Ramanathan, Taimur Hassan

Project Summary: Design a PDA tool to support the Coastal monitoring project


A civil engineering group led by Professor Jenny Jay will be measuring bacteria levels at various beaches this summer. Traditional Fecal Indicabor Bacteria (FIB) sampling methods require a 24 hour incubation period before analysis is possible. Rapid tests are available, but require evaluation. 50-100 scientists will be gathering at Catalina (point source pollution) and Doheney (diffuse pollution sources) to take samples and evaluate these methods.

2 traditional methods will be used to establish groundtruth bacteria levels. Results from 3 to 4 different rapid tests will be compared with the ground truth. Sediment and water samples will be taken at a variety of locations, multiple times during the day. Tests will quantify two different types of bacteria.

Recording and accurately managing this large volume of data is not easy (in or out of the field). CENS has designed an EcoPDA (eyuen/1234) to make this process more systematic and improve the overall quality of the data. See EcoPDA document for background. However the EcoPDA was built for a different application. It needs to be tailored to meet the needs of this coastal monitoring project. The EcoPDA is currently designed to run on the Hp iPAQ hx2495b running Windows Mobile 5.

The modified EcoPDA could also be used in support of a campaign at UC Merced: a human-actuated "snapshot" of the Merced River. Temperature, pH, salinity, nitrate, dissolved oxygen, supplemented with images and perhaps voice recordings about perceptions about water quality from perspectives of the humans standing at various locations. (From Tom Harmon.)

Required Lab/Field Work: Several lab and field days are required in order to understand the scientists' needs and test the tool out. Field work allows you to experience first-hand what the scientists pay attention to when they are out in the field. Additional trips are up to you. There are two different studies that can use the EcoPDA. 1) Epi/SCCWRP study Lab work to process samples collected with SCCWRP. This work will provide valuable context and motivation for why tools are needed to streamline the data collection/analysis process. This experience will also inform system design for data management. Interns can also accompany the group on field days at Catalina. 2) Malibu/other Field work to collect samples. These trips will give you an idea of how flexible and adaptable the ecoPDA needs to be regarding what and how information is recorded. This work will be useful in testing and refining the (a) ecoPDA interace (b) data management in the field, and (c) ecoPDA sensor attachment.

Research Question(s) (higher level and lower level tasks for undergraduates and high school interns):

(1) General, flexible interface

We need an easy way to customize the EcoPDA for different applications. Design a framework so that a user can enter preferences into a web page and obtain a customized EcoPDA interface.

  • Begin by manually customizing the EcoPDA for the Beach project described above. Create and name cells in a way that would be easy for the scientists to input environmental conditions data, a map and images of sampled sites, values from all sensor readings (manually input, image extraction, Bluetooth interface). Users should be able to associate information such as: an image of the sampling site, the bar-coded reading from the sample vial, GPS coordinates, and a description of the site. Each sample should be geo-coded each time it is taken: Because the sites are at the beach, we can easily get GPS coordinates. Get details from Christine Lee who is the lead scientist on this project.
  • Write a script that will take the CSV file provided by EcoPDA and automatically upload the data into sensorbase.
  • Determine the system design/block diagram for the framework, the language used to implement each block. One possible system design is:

- A PHP web-page that takes preferences from user and outputs an XML configuration file

- A python script that parses the XML file and produces the desired EcoPDA interface using the C# API

- A python script that parses the XML file and produces a script that can upload data to the EcoPDA SQL database and/or sensorbase

  • Implement your system

(2) Support Image Capture

Incorporate image capture into the EcoPDA.

  • Find a platform that has an imager and works with Windows Mobile 5 (this link states that HP iPAQ hx2495 will work with the SDIO Photosmart Mobile Camera.)
  • Design a module to run on the EcoPDA that will associate the image with the current sampling event. Some things to consider: how to associate multiple images with a record, how to advance to the next sampling record
  • Determine how and where the image is uploaded and stored
  • Final image analysis application. Use EcoPDA to take an image of the luminometer readout and design an algorithm to extract the number from the image. Check the integrity of image to ensure that the output is reliable. Some images may not be usable, e.g. insufficient light or bad angle. If the image fails the integrity check, notify the user that they need to retake the image. Useful for a lot of different instruments that are still too expensive to directly attach to the EcoPDA. Some operations may be difficult to do on the server because connectivity is likely slow. Explore how much can be done directly on the device, or on the field-kit server (if available).

(3) Bluetooth sensor attachment

Connect PAR, temperature, salinity, DO, chemical sensors over a Bluetooth interface. See [3] for bluetooth transmitters.

Schedule:

Week 1: Preparation

  • Write about yourself, your expectations from the CENS internship, your interpretation of the project's goals (above), and how you would like to contribute to it. Share this with each other and edit it for grammar, structure, and clarity.
  • Introduce yourself to some topics you will be involved in for the duration of the internship (below).
  • Hardware
    • Bluetooth
    • PDA
    • Chemical analyzers
    • Digital cameras
  • Software
    • Visual Studio (C#)
    • Sql Server
    • ASP, IIS, or any other web development platform of your choice
    • Image capture and recognition packages (free ones are preferred)
  • Research
    • Field Research
    • Quantitative Data Collection
    • In-vivo Experiments

Week 2: Introduction to EcoPDA

  • Purpose
  • Architecture
  • Demonstration
  • Christine Lee and her research on Coastal Quality Management (TBA)
  • Hands on code introduction to EcoPDA, small and easy projects for manipulating EcoPDA interface
  • Team assignment: By end of week 2, there will be three teams assigned for each of the three projects, most likely a undergrad-high schooler pairing. Team leaders will be chosen, who will be responsible for their assignment's completion through time and resource management

Week 3 and 4: Detailed explanation for each team's assignment

  • By the end of week 3, you should understand how the EcoPDA works, how interfaces are designed using the C# API, and how data is uploaded to the database.
  • Teams will be directed to the exact areas of EcoPDA that will need to be manipulated for achieving the desired goals of their respective projects (Note, each team will have to be responsible for researching and gaining the appropriate skills for successful manipulation of EcoPDA's C# code.
  • How your spare time is managed during these weeks will be the key to a productive internship!
  • Please document all your work, if you have doubts or are stuck, you are welcome to ask your mentor for help, however do your homework beforehand
  • It would be appropriate to start thinking about some good testing strategies at this point

Week 5 and 6: Testing and Incremental presentation of work to mentors

  • At this point, it will be assumed you have put your solution to some real world testing.

Week 7 and 8: Wrap Up and Documentation. Finish Implementation

  • Write up a rough draft of your overall document by end of Week 7. By end of Week 8, we should have a completed version and also a poster to go along with it.
  • Report must mention the specific technologies you used, how each team member contributed to the project, as well your overall gain in knowledge of particular areas.

FUTURE WORK

(1) Field Kit

Have a laptop which can communicate with multiple "satellite" ecoPDAs. Each ecoPDA should have near real-time access to all data collected by all nearby ecoPDAs. All communication brokered by the laptop.

Coding Project (Hard): Write the server side code on the laptop to collect and distribute data to each ecoPDA. Write client code to run on the ecoPDA to upload and receive data. Talk with Vids regarding his "field kit" code for urban sensing


Preparation:

  • Hardware needs:
  • Software/Program needs:
  • Tutorials/materials needed for intern immersion (Should we do a group tutorial in MATLab, provide articles before arriving, etc): XML, C#, PHP
  • Accounts (CENS account, login access, email lists):
  • Lab access, desk space, keys:

Progress Activities:

  • Ramp-up activities:
  • Project group meetings (frequency and location):
  • Off-campus Excursions: field deployment/data collection (dates and location):
  • Wrap-up/Completion of project activities and indicators:

Discussion Topics: Ask Jenny Jay about specific materials/ kits (test strips, imagers???) sample jars or ziplocks with marker numbered system, image based characterization Media:Example.ogg

Readings - June 27, 2008 Hi Interns, Please read this packet of news articles to start familiarizing yourself with public health and recreational water quality. I will have additional readings ready for you by the start of the week that will delve more into the environmental research that has been done in the area. Here they are: Beach News Articles

[edit]

Planning Archives/ Comments

This area is designed to keep a running tab on past developments through this process. This reflects old thoughts and ideas.

[edit]

Planning Archive: 4.22.08:

Project Details

Application Driver

  • Coordinated watershed and ecosystem campaigns by scientists, supervised-citizens and independent citizens
  • Stream watch and Bud burst: an interactive distributed field kit for coordinated, adaptive, data collection in two domains:
  1. Urban watershed source identification
  2. Project bud-burst
    • Project BudBurst is a national citizen science field campaign that targets native tree and flower species across the country. By recording the timing of the leafing and flowering of native tree, shrub, and herbaceous species each year, the prevailing climatic characteristics can be determined for locally, regionally, and nationally. With the help of citizen scientists, Project BudBurst will be compiling valuable environmental information that can be compared to historical records to illustrate the effects of climate change. Thousands of citizen scientists from across the country participated in the inaugural pilot test of Project BudBurst in 2007, collecting useful scientific data in a consistent manner. The enthusiastic response and robust participation in the pilot effort made it clear that there is sufficient interest from the American public to expand Project BudBurst in 2008.
    • http://www.windows.ucar.edu/citizen_science/budburst/index.html
    • For Project BudBurst we will collect a daily record of observations of marked individuals of plants. Ideally:
      1. We will create a tool for recording daily phenology observations with auxiliary data, such as verification photos, hemispherical canopy images, geo-tagging, commenting, etc.
      2. Students will be collecting daily measurements of tagged individual plants of their choice on their routes to and from school, in the courtyard, or from other, easy to maintain locations. These plants do not necessarily have to be on the list of Project Budburst target plants.
      3. Daily observations will be recorded with 2 or 3 Cyclops cameras already at the James Reserve (possibly also for transplanted specimens to the CENS courtyard) of Common Yarrow, a target species.


System Components

  • Mobile device: guided/assisted data capture that includes data entry as well as image, geolocation, audio annotation -- two platforms:
  1. Eco-PDA Professional
  2. n80 Community Member

Also think about targeting a version of it for anyone with a cameraphone and a TBD substitute for location.


  • Field Kit: coordination, data visualization, data integrity checks, mapping and iterative/adaptive collection tool
  • Server side image tools:
  1. Filtering
  2. Clustering


  • Water observation instruments/ testkits:
  1. DO, ph, algal cover
  2. Ask Jenny Jay about specific materials (test strips, imagers, etc...)
  3. Sample jars or ziplocks with marker numbered system


  • Image based characterization:
  1. stream algae cover, marked ziplock/containers
  2. canopy cover with hemispherical photographs
  3. verification (as voucher specimen) of leaves/buds, stages of phenology
  4. strategically-placed Cyclops for daily observations

Project Description/Development

Two undergraduates per project and an even distribution of high schoolers.


Eco-PDA/Campaignr

Specify data collection campaign on Windows mobile/n80: evaluated current design updates, implement test, user study Develop/use on device mapping? Add geotagging/semacode capability (to leave a mark at location virtually for others who go there?)

  • n80: Taimur?, Min?, John Hicks? (avoid need for campaignr development)


Field kit

Campaign shepherd/watchdog: coordination, data checking, and visualization application

  • Vids?, Sasank?, Nithya? (possibly looking at adapting some aspect of confidence to this application/ modality).


Server-side image characterization and browzing, filtering tools

Ground truth and test data sets

  • Teresa?, MHR? (with help from Josh), Mike W?


Integration of off-devise tests and samples

  • Christine?


Sensorbase/sensorstore/perff (optional)

Anything relevant to do here with activity characterization? Datastore ideas (synchronize between fieldkits) Implement data missing reminder systems (eg for project budburst)

  • Min?, Karen?, Donnie?


Identify something that is more tied to participatory aspects of this (optional)

Was for volunteer participants to explore, visualize and manipulate the data

  • Mark?, Jeff?, Ruth? -- anyone intersted?


1-3 hour long engagement for a middle school/elementary school based on the system

  • Anyone interested? -- Wes is interested but would need help with this...from Wes


Target Field Tests

Do all go on each? or each go on 2 of 3?


Malibu Stream Watch (Jenny Jay):

See heal the bay/ Jenny Jay/ Christine protocol for stream source characterization: use the system to view data and guide coverage interactively to avoid daily/ weekly iterations; take images of test results and physical samples to geolocate and index.


JR (Eric Graham)

Collect data as for Project BudBurst with documented content of location, and server side support for clustering and viewing; characterize canopy cover/opening. Take images of test results and physical samples to geolocate and index.


Two target species identified in ProjectBudburst occur at the James Reserve: Common yarrow (Achillea millefolium) and Ponderosa pine (Pinus ponderosa). There are ten other genera that are common to the list and are acceptable models for Project BudBurst (that will take daily observations of any species).


We will collect EcoPDA data on:

  1. Location using either GPS or distance from landmarks associated with a GPS location
  2. Canopy cover for that location using hemispherical photos with in situ image analysis
  3. Phenological stage of the plants encountered.


We will place one or two Cyclops near the Common yarrows identified last year to collect daily images.


Merced (Tom Harmon)

Talk to Tom about intended measurements, protocol

[edit]

E-mail dialog Jeff Burke and Deborah Estrin 2.23.08:

Question 1: How many (large deployments/ field experiences are you thinking of? Is it best to do 3 different field experiences or 3 cycles around the same area to learn more?

Response 1: No idea. Thats a good question and I would like us to find the right compromise jointly.


Question 2: Having three separate locations for all groups seems to reduce the opportunity to refine each group's approach, unless the data collection is similar in each?

Response 2: Yes


Question 3: Can we build in field iterations around the same data collection challenge without taking too much time away from technical development or overwhelming the mentors? For example, could we get the undergraduates doing field data collection (with progressively advanced approaches?) at least 3 times: 1) in the very beginning with existing tools being led by their mentors, 2) in the middle leading their mentors to use what they developed, and 3) in the end with other people using what they develop?

Response 3: Very good idea; Confirmed by Eric


Question 4: How do you see the different "development projects" working together at a technical level? Integration seems challenging. Do they work pretty much separately with whatever stable version of the other tools they need to use to be able to focus on their task?

Response 4: No idea, great question. I need help figuring the right approach.


Question 5: I wonder if we should consider clustering around professional vs. non-professional users of the technology as this will generate different complementary technical challenges. Based on your groups I think this is already there but I didn't know how much of a use case emphasis there will be. Making it more explicit may help them to know for whom they are working and provide more structure for them to collaborate without making huge supergroups like we had in the eighties. With that last part I was just checking to see if anyone read this far.

Response 5: I like this too

[edit]

Archive 2.22.08

[edit]

Plan A:

Develop, deploy, and analyze distributed interactive, field data collection system that includes handheld devices and field-ready server (field kit).

Pros:

  • Students will learn about mobile infrastructure, distributed services, experimental design, data analysis/visualization

Cons:

  • Does it really relate directly to what students are doing?
  • Does this plan rely too heavily on Urban Sensing students shifting their focus to accommodate this project?

Student Group Project/ Development Ideas

  • Field Kit/ server capabilities and interface to devices (Vids)
  • In-field coordination tool for multiperson synchronized data collection: sms (Vids)
  • Geocaching game with location based virtual caching and semacode stickers...and locations defined by sensed features not just location. (???)
  • Botanical gardens guided tour with image collection/identification, mapping, possibly apply the geocaching game idea here (???)
  • Adaptive data collection coordination tool: Collection planning, in progress updates to locations and data, time/location based automated planning (???)
  • Adapt confidence to one or more of these applications in the field (Nithya)
  • Computer vision based clustering for in-field data visualization. Use tie in to picassa/flickr (Josh H)
  • Authoring of data collection campaigns/protocols
  • On device map based navigation to fit protocol (Eric Y)
  • Capabilities: audio annotation, barcoding, images of all field notes and equipment (???)
  • Two or Three Large Group Projects:
    • Heal the bay (Faculty: Jenny Jay, Jeff Burke; Grad Students: Christine, Vids, Sasank, ???)
    • Focus on calibration/data integrity techniques, integrating some management of physical samples and measures
    • Document with images, barcoding of physical samples, audio annotations.
[edit]

Plan B:

  • Eric Graham & Eric Yuen
    • Work with existing image tools and collection requirements to add UI or Image related features, do associated data collection.
    • Gather ground truth phenology data sets to drive CDI like algorithm development and run some basic image analysis or integrate to picassa/flickr.
  • John Hicks & Teresa Ko
    • Suggest that they come up with some ideas imager related???
  • Mohammad Rahimi & Min Young Mun
    • GeoX related, however avoiding individual's personal data collection but looking at algorithms, doing targeted group data collection that has nothing to do with the natural individual behavior, look at existing data sets.
    • Does it fit for Min to do activity characterization or coarse-sharing in this context
  • Vids Samanta & Sasank Reddy
    • Field data collection campaigns: Walkability, Talkability, Bikeability. Develop sound map and use accelerometer/ location traces to monitor how much stop/waiting time there is with traffic lights, bad sidewalks, with some experience sampling via audio annotation or text/menu or after the fact annotation tool.
  • Josh Hyman & Donnie Kim
    • Work on Image View, API to Picassa/Flickr (???)
    • Look at doing the server side parallelization (???)
[edit]

Plan C:

  • Ask Bill Kaiser and Mani Srivastava if they want to take on half the group...


[edit]

Email Comments from Jenny Jay:

Dear all, That was a great meeting. I just wanted to respond a bit more about one of the environmental sensing applications for CENS technology that my students (Christine Lee and Katie Mika), Rich Ambrose and I are excited about and that Rich and I are currently writing a proposal on together, hopefully with Bill Kaiser as well if he agrees, although I am late in getting to him about this! We are using the rapid method Christine Lee has been working on through NIMS in a novel approach to source tracking of fecal pollution. The overall approach involves a tiered investigation of an impaired watershed in which E. coli and enterococci are used as indicators, and then hotspots are investigated in more detail using molecular biology methods (PCR with human and wildlife specific primers) to attempt to determine the species of the source of pollution. This tiered approach has been done before, but not in a time sensitive manner with a rapid method (and this would be really important as the concentrations of these organisms change rapidly in the environment). To do this properly requires being able to rapidly coordinate water quality data taken at specific places at specific times. It seems like an application that might be of interest, and I'd love to include it in the preproposal we are putting together this week. So, I just wanted to know if you think I can include CENS summer program participation in the preproposal.

My group will also brainstorm on drinking water/environmental justice applications this week, and contact the environmental justice group that we previously worked with on the Maywood project.

Best, Jenny

Retrieved from "http://lecs.cs.ucla.edu/wiki/index.php/2008_Summer%40CENS_Project_Development"
Personal tools