Software

Photographers want total control of all aspects of a camera such as exposure, shutter speed and aperture size. However, some breathtaking pictures require the photographer to be separated from the camera, and thus there is a need for remote access. Currently commercial solutions are very limited. For example, there is software that allows the user to control the camera from a computer but this requires the camera to be tethered to the computer via USB. Canon provides a wireless attachment to their high end DSLRs, but it is every expensive and the range is very limited. On top of that, the attachment is only compatible with certain cameras.

Our solution is combining these there features: full camera control, extended range, compatible with a variety of cameras, all at a really low price. To accomplish this, there is an embedded system that communicates with a camera via USB to adjust its settings. Both the embedded system and the computer are on the same wireless local area network. The photographer will input commands into the computer; the computer then sends the commands via the 802.11 wireless protocol to an embedded system that controls camera. The embedded system will transmit pictures taken to the photographer's computer as well as providing a live preview of what the camera is seeing.

Hardware

The concept of a self stabilizing aerial camera platform came out of the need to have pictures taken at a precise orientation. In order to construct such a device, much planning had to go into figuring out the most logical and mechanically sustainable methodology for stabilization. The first major decision was decided between using passive stabilization, such as a hanging weight, or active stabilization, using motors. Active stabilization was eventually chosen because it allowed for many more features to be added in later, such as panoramic picture taking.

As the project evolved, the panoramic picture taking ability began to take precedence. There was a some struggle in figuring out how to incorporate this with the stabilization. Initially the concept was to use a 4 degree-of-freedom mechanism, which had pitch and roll stabilization, with a pan/tilt mechanism mounted below this. Ultimately, this designed was found to be not feasible to some previous unaccounted for physics.

The next design utilized three degrees of freedom, but now coupled the stabilization and panoramic control schemes. The initial 4 degree-of-freedom model used separate routines. However, this new methodology was much more mechanically stable, and therefore was chosen to be the next design.

Software

With any software component of a project, it is necessary to follow some sort of process model to ensure that both quality standards and project deadlines are met. It follows, that the SACP Software Team has adopted an informal spiral approach to getting tasks done.

We meet each week as an entire team to first discuss metrics or goals that we wish to achieve from that week onwards. From there we come up with a time for the team to get together to actually write code such that we allow ourselves time to absorb ideas and do individual research before approaching the task. We then assemble for a coding session and repeat the cycle. Each time we discuss our metrics we adjust for any roadblocks we may have hit from the last meeting and come up with possible workarounds to our problems.

Nonetheless, when our team was approached with the challenge of creating some sort of interface to allow a user to take panoramic photos given specific input -- we decided the first step would be to create mathematical formulas to calculate the number of photos necessary to stitch together a high quality panorama.

We then took our formulas and put them into functions written in C++. Following that, we designed a graphical interface that would handle user input and process the input within our functions. Our next step was to develop the on-board server machine thats runs on an Intel Atom board that would be used to control the hardware implemented on the Gimbel. After configuring the necessary components to allow for private WiFi access, we arrive at our current state in the software development workflow.

Hardware

Mechanical Design:

The mechanical design of the gimbal system was based around the 3 degree of freedom model shown in the Planning section. This consisted of 3 separate mechanical joints that would work independently of each other. As with aircraft, these primary axes are pitch, yaw, and roll, shown below.

Each axis/joint is driven by its own R/C servo motor. To keep the rotation as smooth as possible, bearings were used at all mechanical interfaces. The entire chassis was constructed from 1" aluminum tubing held together at each joint by press-fit elbow pieces. An example of a mechanical joint is shown below.

• R/C Servo
• Bearing assembly

Controls:

In order to effectively stabilize the system, the orientation of the camera must be continuously computed with reference to some fixed point. The system uses an IMU, or inertial measurement unit, to continuously compute the Euler angles, also known as pitch, roll and yaw with respect to the North-East-Down frame (NED). The angles are then sent to an Arduino microcontroller, which uses a PID control loop to correct for any positional changes from the setpoint. The setpoints for each axis are adjustable to allow the camera to stabilize while pointed in any direction. Below is a diagram showing the correlation between all the components.

Software

Field testing to obtain max range of wireless network

Currently max range has not been determined, although testing in a controlled environment at a distance of 30 feet has been yielded positive results with no issues. Additional field test are scheduled for the near future to determine the max effective range of streaming live video from the camera over a wireless network.

Testing of various methods to stream video

Various methods of streaming video between the Atom Board and the base station have yielded positive and negative results. An initial idea involved a direct transfer of video frames via a shared folder on the Atom Board and the base station which were then collected and displayed by the Application GUI. This method proved to be inefficient and an alternate means of streaming video was needed. Currently we are testing methods where an image object is created on the Atom Board which the extracts the raw data. The data is broken down into bits and is then passed into a byte buffer. The bytes are then transferred via a simple communications controller over the wireless network to the base station which is then collected and displayed by the Application GUI.

Testing of various methods of communication between the base station and the Atom Board

An initial idea involved a direct transfer of text files via a shared folder on the Atom Board and the base station is the current means of communication. This includes all buttons on the Application GUI that are used to control the functionality of the camera. This is accomplished by writing various strings, characters, and integers, all with specific meanings, to a text file which are then read by the program on the Atom Board and interpreted using a case structure. The program on the Atom Board then preforms the desired action and sends a return character back to the Application GUI as a signal that the action has been performed. This has yielded positive results. Additional functionality is constantly being added and tested.

Hardware

Currently, the device has been constructed and is undergoing tests to understand the response of the control loop while in the presence of external disturbances. Currently this testing is being done in a controlled lab environment. Soon testing will take place in more harsh conditions; the platform is schedule to be launched underneath a balloon in the near future. Below is the device in its current state.

-Camera
-Roll Mechanism
-Yaw Mechanism
-Lithium Polymer Battery
-Microcontroller and electronics
-Pitch Mechanism

Software

The Aerial Stabilization project is designed to be versatile and can be used for various image capturing situations. The Aerial Stabilization unit can be used for multiple purposes, such as: security surveilance, nature and wildlife observations, and even scenic photography. It is capable of being deployed in environments that are inaccessible to photographers and allowing them to not only capture images, but video, footages as well.

On May 13, 2011, our team will be deploying this unit over the Sun God Festival using a mini blimp in order to test its capabilities within a large environment. This unit will allow officers on campus to observe the event from a birds-eye view in order to provide a higher quality of safety for students. Using the camera's Live-View functionality, one can surveil the festival ground in real time and react to any possible fatal incidents as they occur.

One other goal this project has had is being able to deploy the gimbal unit over one of Hawaii's volcano and observe the condition of the volcano itself while capturing videos of the event. For this, the gimbal was specially designed to be portable enough to be able to pass as carry-on flight cargo for easy traveling. Also, the gimbal has another function where it can attach itself to a system of high quality cables so one can move it directly through the volcano in a series of directions. In this situation, the gimbal will become a cable-cam setup that travels on a cable instead of an aircraft and still retain its core functionalities.

Hardware

Currently the stabilized aerial camera platform is schedule to be deployed in various locations. They are listed below.

Jordan - UCSD ELRAP Archaeological expedition
The camera platform will support Dr. Tom Levy's expedition to the Edom Lowlands in Jordan this upcoming fall. It will most likely be used for timelapse photography of the dig. The picture is a balloon rig used this past year in Jordan. SACP will be a much needed improvement to this platform.

First test over La Jolla Pier

Glider port view

View over La Jolla Pier