Contact Chase

Project Details

  • School: University of Montana, Missoula
  • Course: Advanced Programming (CS 442)
  • Term: Spring 2010
  • Type: Wildlife Research
  • Teammates:
    • Joel Henry (Project Manager)
    • Jesse Skrivseth (Software)
    • Dayton Gomez (Software)
    • Gene Stipe (Hardware)
    • Thomas Crane (Hardware)
    • Corri Olson (Documentation)
    • Blair Gemmer (Documentation)
    • Fitz Nobles (Testing)
    • Guangmei Xu (Testing)

Project Tags

The following tags have been assigned:

Media Gallery

The home screen of the schedule creation application.If an existing schedule file has already been saved the user could use menu options to open and manipulate an existing schedule file.The audio browser portion of the application is dedicated to listing the audio recordings that were recorded as a result of previous scheduled recording events. A built in media player allows the users to easily manage and preview all files within a single application.The audio browser portion of the application is dedicated to listing the audio recordings that were recorded as a result of previous scheduled recording events. A built in media player allows the users to easily manage and preview all files within a single application.
Commonly played audio files can be imported into the application and organized into a tree structure to make managing these files easier. In this example we are creating a new category where we will place audio files representing animal noises.An individual file can then be selected through the built-in windows file selector.An example of what the tree structure looks like after the first file has been imported.Similar to adding a single audio file, it is possible to add audio files in bulk through the same interface eliminating the need to individually add every file.
Using selections from the audio files panel and the event creation panel it is possible to create new events and add them to the current schedule. These events will populate the center panel.An example of how the scheduling application will look after adding three events on the same day. When adding events with a play component the duration of the selected audio file is automatically detected by the software and used as the play duration simplifying the user experience.By selecting a day on the calendar and choosing to copy events all events on the selected date will be copied in such a way that they can be repeated onto a different day eliminating the need for a user to manually create repeating events.In this example the three elements from Tuesday, April 10th have been copied. After selecting Thursday, April 12th and indicating that the copied events should be repeated, duplicates of each event on Tuesday are automatically generated on Thursday at the same time of day and using the same event settings as the original.
The same copy and repeat technique can be used for spans of time covering an arbitrary number of contiguous days by making such a selection on the calendar. In this example the full week of 4/8 - 4/14 is being copied.By selecting the next week and indicating that the copied events should be repeated over the selected span, new events are generated on the appropriate day corresponding to the event's position in the original selection.Event details can freely be modified by the user by interacting with the event list eliminating the need for a user to delete and recreate events if errors were made or changes must be made. In this case the audio file associated with an event was altered by selecting an alternate file already listed in the audio files panel.Once a schedule is create the schedule can be exported to a file which can later be opened by the scheduler application and modified.
When the user is ready to actually use a schedule they only need to select to have the schedule exported to their desktop. This will generate a completely self-contained zip file containing the necessary schedule details and any audio files referenced in the scheduled events. This file can be placed on a flash drive and will act as instructions for a device deployed in the field once that flash drive is inserted into the deployed device.Spectrogram of wolf pack chorus howls recorded by a device developed from this project. These recordings were taken during August 2010 in Idaho. The black arrows indicate individual adult wolves during chorus howl. Spectrograms were generated using RavenLite software.Spectrogram of wolf pack chorus howls recorded by a device developed from this project. These recordings were taken during August 2010 in Idaho. The black arrows indicate individual adult wolves during chorus howl. Spectrograms were generated using RavenLite software.A sample of a simplistic schedule XML file generated by the scheduling application.

Hoot (Howl Box)

This project was a semester long group effort made up of the instructor, Joel Henry, and all students in the senior capstone course, Advanced Programming (CS 442), at the University of Montana. While this was a school-related project for which the students involved received credit it was a project developed for actual real-world research use by an actual client, the Montana Cooperative Wildlife Research Unit.

Luckily, our client for this project had a good idea of what they wanted created. Often during wildlife research they found that one highly effective technique to evaluate wildlife population and other data was to exploit the call-and-response behavior of certain animals where they will respond to an audible call with a call of their own, facilitating detection. An example of one such animal would be the wolf which respond to howl calls with their own response howl. Unfortunately, the traditional method of broadcasting such a howl and recording the response for future analysis required a human operator in the field to manage the process and remain in place throughout the course of the research period. Since it is optimal for these research periods to last days if not weeks to gather the best sample data this human component is extremely costly and can also impact the accuracy of the results by the human's presence altering the behavior of the animals being studied. This is the problem we were asked to solve and for which our final product helped to automate. Our role in this project covered all aspects of acquiring and selecting the most appropriate hardware as well as developing any software that was necessary to facilitate this process.

We began the process by documenting, troubleshooting, and making a variety of minor alterations to an existing non-functional product the client had previously tried to have developed by an individual within their organization who, unfortunately, did not have a solid working knowledge of technology or software development. This non-functional system came with no documentation and included large unwieldy hardware running a Linux OS making use almost exclusively of Bash scripts to control the process. This first phase of the project involved our team fully documenting and making this existing system functional with the minimal requirements while simultaneously working closely with the client to develop a complete requirements list for an entirely new system which we would develop.

The design of the new system was based on the need to facilitate the following common usage scenario for the system in addition to several other important aspects:

  • The researcher would, in advance on any computer with our scheduling software, setup a schedule of events by specifying the date and time and other details about each event that they would like the device to execute throughout the research period. These events could include actions such as playing an audio file through attached speakers (e.g. a wolf howl used to trigger a response howl) or recording the environment using an attached microphone (e.g. to record the target wolf's response howl).
  • The software application we developed to create such a schedule would then generate a single output file that included all of the necessary schedule information as well as any audio files that would need to be played during any of the events outlined in the schedule. This file could be placed on a USB flash drive or external hard drive for easy portability into the field.
  • The researcher would then need to setup the device in the location which they wished to perform their study if a device was not already setup in that location. Often reaching the locations they wish to study is only possibly by hiking on foot for long distances and therefore it was important to minimize the weight of any equipment, including power sources, that would be required for the device to be functional. It was also necessary for the device to be very power efficient as there was no source of power in the wilderness and all power needs throughout the entire span of the research period would need to be satisfied by a battery source. An example of some hardware and I/O devices (a netbook, microphone, and speakers) used by the application to execute the scheduled events. Because of these factors, and the need to make use of inexpensive and easily accessible hardware that other researchers could duplicate to easily make use of the software that we would develop and freely release, we chose to make use of power-efficient netbook computers with external microphones and speakers which could also optionally have an additional battery pack included for extended battery power. These components were packaged in an such a way that they could be left in harsh weather conditions for extended period without damage. Once the researcher arrived at their destination they would mount the packaged device to a tree or other appropriate surface where it would remain until it was revisited days or weeks later in order to assign a new schedule of events, retrieve any recordings that had been taken, replace and replenish a battery source, or bring the device home.
  • While these netbooks did have keyboards, trackpads, and monitors which would allow them to be used in a traditional fashion, using them in this fashion was unnecessary, drained the battery extremely quickly, and was not easily done as a result of the way the bundle of hardware was packed to be weather resistant. When designing the daemon software that ran on the device and executed the schedule it was assumed that the device would not have any I/O devices (e.g. monitor) other than audio and the ability to insert and remove removable storage devices via an exposed USB port. Interaction with the device was intentionally simple. When the researcher wished to load a new schedule onto the device or retrieve all recordings that had been taken by the device since the last visit they would simply need to wake the device - by default the device was always in sleep mode while not executing a scheduled event to conserve power - and wait for an audible prompt instructing them to insert a USB storage device. The daemon responsible for handling this action would then import the proper schedule file from the inserted drive and use it as the schedule for future events. It would also copy over to the inserted drive any recordings that had been taken by the device since the researcher's last visit so these recordings could taken and analyzed elsewhere without needing to remove the device from the field. Throughout this process the user would receive audible instructions and status updates through the device's speakers regarding when they should take certain actions. As the device's power profiles and other settings are managed by our software the researcher needs only insert their drive, listen to the audio status messages, wait to be prompted to remove the drive, remove the drive, and then depart leaving the device responsible for turning itself off, turning on in time for future scheduled events, and any other responsibilities.

A research paper discussing this project and some results obtained through the use of our final product was written and published in the Wildlife Society Bulletin (Volume 35, Issue 4, Pages 498-503, December 2011).

While the scheduling application used to generate schedule files is only a small part of this project, the media gallery on this page focuses primarily on that component. The other components, such as scripts automating the configuring of new devices and the software daemon running on and controlling the actual device in the field do not contain graphical or visual components and are, therefore, difficult to display.