CSE237D Wireless Interface [Project Charter]

Navigation

• [Home](CSE237D Wireless Interface [Home])
• [Project Charter](CSE237D Wireless Interface [Project Charter])
• [Team](CSE237D Wireless Interface [Group Management])
• [Project Development](CSE237D Wireless Interface [Project Development])
• [Project Schedule](CSE237D Wireless Interface [Project Schedule and Milestones])
• [Weekly Updates](CSE237D Wireless Interface [Weekly Updates])

Project Charter

Project Overview

The camera trap is a device that autonomously takes pictures and records videos of wildlife. It may be deployed in settings ranging from a zoo to remote locations that are uninhabited by humans.

Due to nature of the Camera Trap, it may be deployed in locations that are hard for humans to reach when maintenance tasks such as downloading captured footage, positioning the camera trap, or checking on the system status are required. Our goal is to make these tasks easier for both engineers and biologists to perform, while being energy-efficient. To achieve these goals, we plan to add the following features:

1. Remote Debugging and Video Downloading. Remote debugging will allow engineers to check the status of the trap and perform maintenance to the software systems without going to where the camera trap is deployed to plug-in an ethernet cable (which may be difficult if the camera trap is in a tree). Remote video downloading will allow users such as biologists to easily download captured footage, with benefits similar to those of remote debugging.

2. Remote Triggering. For saving energy, the Intel Atom board gets shut down when no animals are in range. This means that if a user wants to download videos the board needs to be told to power on despite no animals being in range. We will add a low power radio to use as a remote triggering mechanism to turn on the Atom board.

Project Approach

• For the Remote Debugging and Video Downloading, we are looking at using Wifi. WiFi is fast enough (54Mbit/s for 802.11g) for video downloading and the host machine can be configured either as a hotspot or a client. When the cameras are deployed at a place where there are no routers accessible, we can configure the Atom board, which has the WiFi USB adapter attached, to act as a WiFi hotspot so that when a user (ex: a biologist) gets close enough, they can find the camera's hotspot and connect to it using their laptop to start the video downloading. This removes the need to connect their laptop to the camera trap using an ethernet cable, which may be nearly impossible depending on where the system is deployed. On the other hand, when a WiFi hotspot with internet access is in range, the WiFi dongle on the Atom board can be configured to connect to the available network, enabling real remote video downloading from anywhere in the world where internet access is available. The same goes for the debugging.

• For the remote Triggering part, we are looking at using both Zigbee and GSM SMS to achieve it. SMS triggering is a more desirable approach if SMS service is available within a certain range, in that not only can it be easily used by anyone with a cell phone, but it can also send text message reports on the camera trap status to either biologists or engineers. One downside about SMS messaging is that the power comsumption can be very high. Comparatively, Zigbee has the advantage of lower power comsumption. However, Zigbee has limited communication range (around 300 feet) if no router nodes are present within the range. But this should not be a problem when the camera is put in an actual wilderness, where no WiFi routers would be present, thus requiring the biologists to have to go near the camera to perform the triggering and video downloading anyway.

Figure 1: Overview of the System

Project Objectives, Milestones and Major Deliverables

Our primary objective is to provide a wireless interface for debugging and downloading captured footage on the camera trap. This can be broken down into two sub-objectives of building a low-power remote triggering device for activating the Intel Atom board, and developing an easy-to-use wireless interface for accessing stored files on the camera trap and debugging the system. These can be broken down into the following milestones:

• Enable access to the Intel Atom board via SSH for debugging and SFTP for downloading video files, using WiFi. (Milestone 1)
• Turn-on the Intel Atom board using a low-power Zigbee radio as the triggering device. (Milestone 3)
• Allow use of a web browser for viewing a list of captured files and downloading them. (Milestone 2)
• Allow a web browser to be used for debugging of the camera trap status. (Milestone 3)

Additional features that would be nice to add if we are ahead of schedule include:

• Allow control of the turret via a web browser based interface, with a streaming video feed.
• Send SMS status updates on the state of the camera trap.
• Use SMS to wake up the camera trap for transferring files or debugging.

A potential really long term goal would be developing a smartphone app that integrates using SMS to turn on the Intel Atom board, along with an interface for controlling the turret, downloading files, and checking the status of the device.

Constraints, Risk and Feasibility

What are the potential stumbling blocks? What is realistically feasible here? The quarter goes by very quickly. The better approach is to over-deliver on what you promise, rather than under deliver on a set of unrealistic goals. Be sure to include risks - a list of things that could go wrong and how to avoid them.

Constraints

• Low-power consumption
• Cost of components should not be excessive
• Existing hardware that we must integrate with (Intel Atom board and Atmega microprocessor)
• Limited copies of hardware for testing, such as only one Intel Atom board.

Risk

• Parts may not arrive on time. If this happens then we may need to drop features such as the GSM radio for SMS support and just go with the Zigbee radio.
• We will be sharing the hardware with another camera trap team, which may hinder development. However ordering another Atmel relay board should minimize any contention for hardware to test with.
• Zigbee can apparently be hard to work with. We may need to put additional time into getting it working properly. To minimize this risk we will get help from people who have worked with the Zigbee modules before.
• Time. Other classes and midterms take time, reducing the amount of time we can spend working on this project. To minimize the impact of these other classes we will try to get work done early in the quarter.
• The Atmel board we are using as a hypervisor may not be able to handle serial communication with 3 different devices (Intel Atom, GSM radio, and Zigbee radio). If this is the case we may need to make sure only one of the two remote triggering methods is used at a time (either GSM radio or Zigbee) depending on where the camera trap gets deployed. We may wish to disable the radio that is not in use anyway as a way to save power.

Feasibility

• Many people have used Zigbee and SMS support successfully in hobby projects. It is definitely possible to get them working.
• WiFi is also very widespread; we may need to mess with the configuration settings some to configure it properly based on whether it should create an adhoc network or use an existing router that is in range. Fortunately there is plenty of documentation on using WiFi networks in Ubuntu, and this should not be a problem.
• Simple interfaces for downloading files and checking system status. SFTP and SSH access to the camera trap would be the minimum viable product for the camera trap, both of which are easy to use. Ideally we would like to have a web browser based interface, or even a dedicated smartphone app so that a user only needs to bring a minimal amount of hardware with them other than what they already have. Developing browser based interfaces for remote control of a device has been done before, as has writing smartphone apps (as shown by the growth of the iPhone and Android app stores, respectively).