The charter provides a description of our project.
The Spectre Project will be a software update for the already existing Stabilized Aerial Camera Platform (SACP) created at the UCSD CSE Labs. The Spectre team will be the 4th team to contribute to the SACP, making it fully autonomous whilst airborne.
SACP is a low cost alternative to traditional fixed wing aircraft, and has previously been used for different applications like time lapse pictures of work at an archaeological site, aerial surveys and panorama pictures. Till now, these tasks has been accomplished by controlling targeting and picture taking manually from the ground station, making these kind of tasks time consuming for the operators.
During this project we want to make the SACP easier to operate, less time consuming to use and more accurate in time lapse applications. We want to make the SACP more autonomous by making it able to focus on a target, given the targets GPS location both while the balloon is stationary and when its moving. Further we want to implement scheduling, so the SACP can take pictures of one or more targets in given time intervals for a given time period.
This project is going to add functionality to the Stabilized Aerial Camera Platform (SACP) to support GPS targeting, scheduling and real-time tracking of a GPS location. The user should only have to specify a GPS coordinate, and the SACP is going to calculate and point the camera in the right direction. In addition, we want the SACP to be able to automatically point at a certain target location at a specified time.
The SACP consists of a helium balloon, a metal frame and a stabilized gimbal with camera. The camera and gimbal are controlled by two Arduino microcontrollers: a Mega 2560 for stabilization and control of the gimbal, and a Uno for taking pictures. In this project we are going to add code to the programs running on the microcontrollers to enable targeting and scheduling.
There is a u-blox GPS device on the SACP that we will use to measure the GPS location. We will add a Barometric Pressure Sensor - MPL115A1 Breakout to be able to measure height with improved accuracy. We will use this data to calculate the direction from the camera to the target location and then adjust the camera accordingly.
In addition we will have to fix a problem with the gimbal where it stops behaving correctly when pointing in certain angles. The SACP is currently using a CH Robotics UM6 Inertial Measurement Unit (IMU) that has a compass, an accelerometer and a gyroscope. The IMU gets confused when the axes of two of the gimbals is in a parallel configuration.
Our major objective is to atomize the SACP’s targeting and picture taking making it easier and less time consuming to operate. Since the existing system have a current issue, “the gimbal lock problem”, we wish to start implementing autonomous scheduling and GPS targeting with the current solution to the gimbal lock problem which constrains the pitch of the camera. After implementing this, we want to see if we can find a better solution to get around the problem making the SACP able to autonomously take pictures with camera pointing in all directions.
Our project’s milestones and major deliverables are listed below:
1. Getting familiar with the existing hardware and software – Everyone.
2. Overcome Gimbal Lock – Frederik
3. Implement Barometer – Kamilla
4. GPS targeting – Alex
5. Timelapse and Panorama – Thomas
6. The final presentation will be held on June 3.
Potential long term goals or future developments of this project could be making the control program more users friendly. Another would be to work out stabilization code using quaternion values from the IMU, instead of the current Euler angles. This would solve the current gimbal lock problem. The current method of preventing gimbal lock is to constrain the pitch of the camera. We might have try to do this if we can’t find another way to get around the problem.
The SACP uses a gimbal to hold and stabilize the camera. Currently, the pitch of the gimbal is constrained to only be in a horizontal or vertical position to avoid gimbal lock. To avoid this constraint, we plan on adding functionality to support quaternion calculations. We currently don’t know how difficult this problem is to solve, and it might be too big and time consuming for this project. If that turns out to be the case, we will have to try and avoid the problem by locking the camera in different angles for different modes for instance.
For measuring the altitude we will use a Barometric Pressure Sensor that we will connect to one of the microcontrollers. The team does not previously have much experience with hardware, and the implementation might take more time than we initially expect. In addition there has been some trouble with the compass-data from the IMU, and if they persist we will have to add an additional IMU as well.
Although all members are required to take part in programming and hands on work on the rig, the team members are also assigned specific responsibilities .
At the moment Alex is functioning as Team Leader. His job is to oversee the fulfillment of deadlines and deliverables as well as organize the meeting locations and chair the meetings. Alex is also responsible for the presentations, although other team members will present their own deliverables.
Kamilla is the main contact with Eric, the Supervisor. She is also responsible for the weekly reports and logging the meetings in google docs.
Thomas is the team’s Webmaster and is in charge of effectively communicating the teams weekly efforts online. This includes setting up the website on Webflow and transferring the site over to a separately hosted herokuapp server. Once a stand alone website, it will be updated through github.
Frederik, who has the most programming experience, is Chief Programmer and will advise and support the other team members in the coding objectives. All members are required to take part in the programming, however Frederik will act as consultant when a programming team is stuck.
The person responsible for their area will make their own day to day decisions. If there is a question regarding the overall strategy or vision of the project it will be brought up in the weekly meeting and agreed upon.
Our team is fortunate to have a very similar schedule. We therefore have many opportunities to meet in the lab to work on the Spectre. Additionally we will be holding one update meeting every week. For day to day discussions we have a Facebook Conversation to communicate.
Thomas has made a detailed schedule of the milestones and all their sub-objectives. If we fall behind on one objective we can re-allocate other members to try to catch up to speed so that the milestones themselves are not delayed. The clue for the schedule is that the objectives are set up in order of dependency. Independent objectives can run in parallel as long as the dependent objective requirements are always on time.
Refer to the milestones section of the specification.
Although all members are required to take part in programming and hands on work on the rig, the team members are also assigned specific responsibilities .
At the moment Alex is functioning as Team Leader. His job is to oversee the fulfillment of deadlines and deliverables as well as organize the meeting locations and chair the meetings. Alex is also responsible for the presentations, although other team members will present their own deliverables.
Kamilla is the main contact with Eric, the Supervisor. She is also responsible for the weekly reports and logging the meetings in google docs.
Thomas is the team’s Webmaster and is in charge of effectively communicating the teams weekly efforts online. This includes setting up the website on Webflow and transferring the site over to a separately hosted herokuapp server. Once a stand alone website, it will be updated through github.
Frederik, who has the most programming experience, is Chief Programmer and will advise and support the other team members in the coding objectives. All members are required to take part in the programming, however Frederik will act as consultant when a programming team is stuck.
Our plan is to use the existing hardware, and hook a barometer (https://www.sparkfun.com/products/9721) to one f the Arduinos over SPI to get data about the platforms altitude. We already have this component available, so no components will need to be ordered.
Currently the SACP consists of a helium balloon, a T-frame, a stabilized gimbal with camera, a ground station and a tether rope. The T-frame has two Arduino micro-controllers mounted, a Mega 2560 for stabilization and control of the gimbal and a Uno for taking pictures. Further it has a mount for a GoPro camera to take non-stabilized images, a u-Blox GPS logging GPS data, and autopilot equipment for logging wind speed data. The software for polling GPS data is already implemented, but have not been applied for any practical use yet.
The gimbal is based on a Freefly six degrees of freedom gimbal, a light-weight gimbal made of carbon fiber. The servos are replaced with Bourns 6639S Continuous Precision Potentiometers. This allowed for using our own micro-controllers and IMU, instead of the very expensive Freefly system. Mounted on the camera platform is a CH Robotics UM6 Inertial Measurement Unit (IMU), which has a compass, accelerometer, and gyroscope .
The ground station consists of a Pelican case housing a video screen with live video feed from the camera via wireless radio link, and a laptop with a Serial radio connection to the Arduinos. Commands are typed into a terminal window attached to the COM port to which the Serial radio is attached.
The software running on the two Arduinos is implemented in C. We will use the existing software as starting point for our project.
The person(s) responsible for implementing a module will also be responsible for testing it. We also plan to use team programming to develop all modules, always having two people programming collaboratively at the various sub-tasks, to make sure bugs are discovered fast. Unit testing will be performed at the lab, with the T-frame fastened tt to a stationary ground based rig. If we managed to get all our planned new features operational, we intend to do a live aerial test by week 10.
The persons developing a module will be responsible to document their work in the google doc database. Thomas will update the website accordingly and some documentation will also be provided and updated in the github wiki for future generations to continue work on the SACP.