Proposal Details
“If we had SNAPS and could see a picture of our deployment, that would have been a game
changer” – Walter Holemans, Planetary Systems Corporation
Overview
The Stanford Nano Picture Satellite (SNAPS) is a 0.25U CubeSat created by a team of Stanford
undergraduate and graduate students. SNAPS’ mission is to deploy from the same dispenser as a 3U
cubesat, take video of the cubesat, and send images of its deployment back to Earth. These images are
valuable data for satellite operators who need to know how their satellite has deployed. The project has
been worked on for approximately a year; we are seeking a launch in early 2015.
Background
The Canisterized Satellite Dispenser (CSD) is an alternative to the Poly-PicoSatellite Orbital Deployer (PPOD) for deploying CubeSats. The CSD standard is a compelling alternative to the P-POD because it
enumerates specifications for robust mechanical constraint of satellites using “sandwiched” tabs, the
size and mass of satellites, and a satellite-to-vehicle interface. Critically for SNAPS, the CSD standard has
one extra inch of space compared to the P-POD. The SNAPS satellite fits in this extra 1 inch of space
along with a typical 3U Cubesat, allowing it to add tremendous value with little additional cost or risk.
Mission Phases
The SNAPS mission consists of four phases.
1) SNAPS and a CubeSat deploys from a CSD. As mentioned
above, SNAPS fits into the CSD deployer along with a 3U
cubesat.
2) SNAPS takes video of the cubesat deployment. SNAPS’
camera is automatically turned on as deployment from the
cubesat begins. SNAPS has a 1080p HackHD camera which
will take video for 10 minutes after deploying. Video will be
saved to a SD card on SNAPs.
3) SNAPS software analyzes which video frames include image
of cubesat deployment. SNAPS’ image processing algorithm
identifies the satellite by searching the frames of the video
for hard edges. This algorithm will run on-orbit on SNAPS’
processor.
SNAPs
Cubesat
Cubesat
x
4) SNAPS transmits video frames identified in Phase 3 to
ground station. SNAPS transmits with an omnidirectional
antenna built into the body of the satellite. It is expected
that the first image will arrive in about 2 days. All images will
be downlinked in 1 month.
SNAPS Mission Parameters
SNAPS has a wide orbit altitude and inclination range because its primary mission is to take video of the
3U CubeSat it deploys with. The primary limitation is that the orbit must have line of sight with Stanford
because that is where SNAPS’ ground station is located.
CubeSat Mission Parameters
Mission Mass Cube Size
Desired Orbit
Acceptable 325 km @
Name
Orbit
51.6° incl.
Range
Acceptable
SNAPS <1.33
0.25 U
Altitude
300 km
200km Yes
kg
(10x10x2.5
500km
cm)
Inclination 40°
20° - 60°
Readiness
Date
1/1/2015
Desired
Mission
Life
3
months
Cubesat Project Details
CubeSat Project Details
Focus Area
Student
NASA Funding
Sponsor
Proposed Collaboration
Involvement Yes or Organization
Yes or
International
No
No
– Yes or No
1) Primary - Yes
No
N/A
Stanford Student No
No
Technology
Space Initiative
2) Secondary Educational
Merit Review Process
We believe SNAPS provides tremendous Technical and Educational merit to NASA. To verify our beliefs,
we conducted a merit review by meeting in person with individual members of our merit review
committee. The members of the committee are listed in the table below and were selected due to their
experience in space technology and education. The process was not competitive as there were no other
Stanford groups to our knowledge building a cubesat. Results of the merit view are discussed after both
the Technical and Educational merit sections.
Name
Scott Hubbard
Gil Moore
Andrew Kalman
Ivan Linscott
Walter Holemans
Marcos Pavone
Experience
Consulting Professor in Aeronautics and Astronautics at Stanford
Former Director, NASA AMES
Project Director, Polar Orbiting Passive Atmospheric Calibration Sphere
Consulting Professor in Aeronautics and Astronautics at Stanford
Founder, Pumpkin, Inc. (makers of the CubeSat Kit)
Senior Research Associate at Stanford
Chief Engineer, Planetary Systems Corporation (creators of the
Canisterized Cubesat Dispenser)
Assistant Professor in Aeronautics and Astronautics at Stanford
Project Focus: Technical Merit
As a technology demonstration mission, SNAPS solves a very specific need in the cubesat market while
also serving as a stepping stone towards valuable larger missions. This mission advances NASA’s
technology strategic goals of “Extending and sustaining human activities across the solar system” and
“sponsoring early-stage innovation in space technologies in order to improve the future capabilities of
NASA, other government agencies, and the aerospace industry.”
Value of Imaging other Satellites
SNAPS’ specific mission will demonstrate the ability for a CubeSat to take pictures of another satellite, a
previously unperformed feat that is useful for numerous reasons.
First, by taking pictures of deploying cubesats, SNAPS provides critical information on the initial
conditions of the photographed CubeSat’s trajectory and spin that significantly increases the likelihood
of mission success. Currently, there is almost no information as to what happens to a CubeSat when it is
deployed, and this has resulted in numerous failed missions as communication is lost or the data
received is incomplete. Even when satellites are working, understanding their deployment is critical.
For example, the Polar Orbiting Passive Atmospheric
Calibration Sphere (POPACS) mission consisted of three
spheres separated by spacers (Figure 1). In our merit
review, the project director for the mission told the
SNAPS team that having images would have been
critical in determining whether they deployed correctly,
something they could otherwise only estimate.
Second, SNAPS is useful for diagnosing satellite issues. Figure 1: POPACS Mission
When something goes wrong on a satellite, the ground
team has to use sensor data to try to determine the issues; often, the necessarily information is not
available and being able to obtain real time imagery or video of the satellite would enable the ground
crew to better assess the situation. For issues like a mechanical failure of a solar panel deployment,
anomalies caused by being struck by space debris, or mistracking of satellites, especially in LEO because
of drag, real time images would be the fastest way to identify the problem, saving significant
troubleshooting and failure costs.
Finally, this technology can advance other increasingly important space technologies or maneuvers, such
as docking, telerobotics, or satellite servicing. By providing views from different angles, inspector
satellites like SNAPS can increase the machine’s or ground crew’s awareness of the situation, helping to
enable rapid and informed decision making.
Value of Miniaturization
As a ¼-U satellite with tremendous functionality, SNAPS also
functions as a technology demonstration of the increasing
ability of miniaturized spacecraft to leverage advances in
commercial off the shelf (COTS) electronics. To our knowledge,
SNAPS’ flight computer, camera, and antenna are more
powerful than any equivalent hardware that has been used by
a CubeSat that has flown in space.
SNAPS’ main flight computer runs through a 32 bit ARM Figure 2 HackHD Camera with Hand for Scale
microcontroller, a state of the art processor used in the
majority of mobile phones. It is powerful and easily upgradable as the rest of the board is made of
entirely of COTS technology as well.
The video camera on board is a 1080p HD camera with a 160-degree wide view lens that has extremely
high resolution for its size. Again, this enables higher quality than other CubeSat cameras and builds off
state of the art, COTS technology. Moreover, the wide view ensures that SNAPS will capture imagery of
the other satellite.
Lastly, the folded dipole antenna that SNAPS utilizes to communicate back to Earth adds huge capability
and reliability to small satellites. By folding around the body similar to the antenna of a smartphone,
SNAPS’ antenna can communicate omnidirectionally at high frequencies without taking up much space
within the satellite or requiring advanced technologies. Most small satellites require deployable
antennas and accurate pointing and satellites have failed when either the stabilization or deployment
mechanism has failed or interfered with other satellites. The folded dipole removes this possibility and
increases both the performance and likelihood of mission success.
Value of the Mission Architecture
By deploying with another satellite and using its mission to advance the mission of the photographed
satellite, SNAPS will be an early demonstration of co-orbiting satellites that complement each other and
achieve more together than either satellite could achieve alone. This is a stepping stone for formation
flight of cubesats, which will allow advanced missions to be accomplished at low cost.
Moreover, SNAPS demonstrates the potential of the CSD as a cubesat deployer and expands the
potential of that platform by integrating seamlessly and allowing CubeSats using the CSD greater
mission flexibility. The team plans to expand SNAPS to serve 6U and larger CSD’s, allowing greater
capabilities and further increasing the potential of both platforms.
Technical Merit Review Recap
All members of the review committee saw that there was tremendous technical merit in SNAPS.
Hubbard was excited about SNAPS as a way to increase the reliability and prove the capabilities of
secondary payloads. Hubbard also recommended we look at specific use cases, so we spoke with
Holemans and Moore in greater detail about how SNAPS would have helped the POPACS mission.
Holemans and Moore were very excited about the possibility of getting images of cubesats to help
identify initial conditions and increase the chance of mission successes. Moore reported that for the
POPACS mission that he led, a tremendous amount of time and energy was put into tracking the spheres
and trying to estimate what happened as they were deployed from the CSD, something SNAPS’ pictures
would have determined immediately. Holemas confirmed and added “If we had SNAPS and could see a
picture of our deployment, that would have been a game changer.”
Holemans, Kalman, and Linscott agreed that the cutting edge microcontroller, camera, and especially
the breakthrough with the folded dipole were huge steps forward for smaller, more capable satellites
that really built off the movement to miniaturize electronics. Pavone was particularly interested in
SNAPS as a stepping stone towards larger missions where this miniaturized camera payload could be
combined with more advanced controls systems to allow pictures to be taken of other satellites and
missions, greatly increasing our capabilities.
Secondary Focus: Educational Merit
Our goal with SNAPS is to create a process where university students can launch productive cubesats
with the highest chance of success and implement a system to teach this process to future students at
Stanford and at other universities. The team recognizes that many university cubesats have failed, so
creating this process will add a lot of educational value. We can accomplish NASA’s goal to “Strengthen
NASA and the Nation's future workforce” by teaching future engineers our process, which will give them
hands-on training with a functioning satellite. Several features of the SNAPS mission increase our
educational impact.
Accessibility and Reproducibility
All SNAPS documentation and learning is published on an open
website (https://sites.stanford.edu/ssdl/snaps). This means that the
learnings and successes of the SNAPS team can be passed on to other
educational institutions or new generations of satellite makers. We
have already seen evidence of this learning as the final reports written
by the SNAPS team last year (see Appendix) were instrumental in
getting the current SNAPS team up to speed. Furthermore, the SNAPS
structure is created with additive manufacturing. The computer-aided
design
files
are
available
for
download
here:
http://stanford.edu/group/ssdl/SNAPS/files_distribution/CAD/. This
means that future satellite makers can easily 3D print the satellite Figure 3 SNAPS Public Website
structure.
Fast Iteration
Our team believes that our educational value is amplified by our ability to iterate rapidly, constantly
testing and getting expert feedback. Because we use COTS components, we can rapidly change
hardware and test our current designs. For example, we are using a Lithium Li-1 radio, but we can easily
replace it with the next generation Li-2 radio if necessary as we experiment with the folded dipole and
the required range. In addition, we 3D print structures so we can try different designs the day they are
completed. These learnings become a part of our educational process because the team produces a
report summarizing our findings every 3 months, which is then presented to students and faculty.
Multidisciplinary Student Pipeline
The SNAPS core team currently consists of 8 Stanford students, from Freshman to PhD students. By
involving students of all educational levels, the SNAPS team will not be lost by a single graduation cycle,
and experience can be passed directly onward. We have concrete evidence of this as some of the
students who worked on SNAPS last year have graduated, yet the SNAPS team remains strong.
Furthermore, we have students from a variety of Stanford departments, including Aeronautics and
Astronautics, Electrical Engineering, Computer Sciences, and the Graduate School of Business. This lets
students exchange their ideas and learn more about how to work in a cross-functional environment.
Educational Merit Review Recap
Linscott pointed out that many university cubesats failed, so it would be truly valuable for education if
we could create a process that would maximize the chances of success. He also praised our iteration
cycles and recommended we expand on them. As a result of his feedback, we committed to the open
architecture of SNAPS where we publish everything on our webpage and expanded our testing plan. We
believe this will maximize the learning for ourselves and other institutions.
All of the committee members thought the open-source nature of the project had the ability to have an
educational impact beyond the Stanford students who are working on it. Hubbard thought the project
was more educational because it involved multiple Stanford departments. He encourages us to reach
out to even more departments. To address this, we have a recruiting effort underway to bring more
students into the project, including non-technical students who can help with regulatory and licensing
requirements.
Technical Feasibility
This section describes the technical work for each subsystem in SNAPS that either has been completed
or needs to be. As an overview, SNAPS’ mechanical, electrical, and communications designs have been
developed and are largely complete. SNAPS software is partially complete: the imaging algorithm is
complete, but the flight software and ground station components have to be developed. Finally, SNAPS
has to undergo a variety of testing, including thermal, vacuum, and vibration testing.
Structural Subsystem
SNAPS' structure has been designed and built. It consists of two parts, a
bottom shell that houses all of the components and a top plate which
snaps on top. The two sections are then screwed together to keep
everything fully constrained. The shells can either be 3D printed or
machined. There are grooves in the bottom shell to locate the HackHD
camera, two batteries, aluminum tabs, and three switches needed to
ride in the CSD. Standoffs place the battery protection and main C&DH
boards at the right heights and screw slots hold the camera, boards, and
aluminum tabs in place. The aluminum thermal plate snaps and screws
into the top plate to sit ontop of the radio and batteries to transfer heat
between them. There is a slot in the bottom shell that houses the
antenna and both large faces have recesses to hold two solar panels.
The 3D printed body lets us rapidly iterate on the design. Several Figure 4 Exploded SNAPS Structure
iterations of the structure have been printed and fully assembled to
verify that everything fits. The only remaining task is final integration of the tuning board to connect the
antenna and radio.
Electrical Subsystem
SNAPS is powered by four solar panels mounted on the face and back of the satellite. The output of the
solar cells is used to power two batteries arranged in parallel. The main sources of power consumption
are the HackHD camera and the radio.
Already Completed
Table 1 SNAPS Power Budget
Power budget analysis and power management circuitry
Estimated Power
have already been completed for SNAPS (see Table 1). Component
Consumption (W)
There are four possible modes of operation: recording
5.52
(camera + processor + SD card active), processing Camera
0.28
(processor + SD card active), transmitting (processor + SD SD card
Radio
5.43
card + radio active), and sleep (all electronics sleep).
0.40
Estimated power consumption for each component is listed Processor
Processor
(sleep)
0.06
below.
Maximum possible 11.7
The radio accounts for 91% of all energy usage assuming a
180 day mission. Thus, the RF link budget heavily influences the total power budget. Using STK, the
team estimated that a balanced energy budget dictates a 7.5% RF duty cycle.
To be done
The team’s main task before the electrical systems are complete is to assemble and characterize the
solar cells and their maximum power point tracking (MPPT) system. Three versions will be constructed
for testing: solar cells only, MPPT circuitry only, and solar cells and MPPT circuitry together. As of
writing, the solar cells only version and combined version are fully complete, and the MPPT only version
is partially completed.
The testing regimen will be similarly divided and will begin once all versions have been constructed. The
MPPT circuitry will be tested to verify correct component values and topology have been chosen. In
addition, and losses will be quantified. The solar cells alone will be used to test the mechanical aspects
of mounting and verify their current-voltage curve. Finally, the combined version will prove system
operation and provide final information for the power budget model.
Battery Supervisor Subsystem
SNAPS features a redundant and self-correcting power system that can gracefully handle power loss as
well as a variety of battery faults. Both batteries are monitored by a Battery Supervisor PCB. The Battery
Supervisor provides real-time current draw, voltage, and temperature measurements for both batteries
as well as automatically disconnecting battery charge and discharge connections in several fault
conditions.
In response to four critical fault conditions (over/under voltage and over/under current), the Battery
Supervisor will autonomously take action to protect the batteries by shutting off either the charging
connection, the load connection, or both. These immediate responses are designed to guard against
conditions that could destroy the batteries.
Throughout the mission, the Battery Supervisor can also report battery voltage, current draw, and
temperature to the SNAPS main controller via an SPI interface upon request.
Already Completed
A Battery Supervisor PCB, manufactured by Pumpkin, Inc. has been selected. The critical functionality of
the Battery Supervisor, handling immediate battery fault situations, works out of the box.
Work has already been done to implement a SPI interface between the Battery Supervisor and the main
controller. The main controller will be able to request battery voltages, current draws, and temperatures
from the Battery Supervisor and receive this data in real time. This system was prototyped last year.
To be done
Building on the SPI prototype, our current task is to design a new binary protocol with error checking to
replace the inefficient ASCII protocol used in the prototype and thoroughly test the SPI interface to
ensure that messages are consistently accurately transmitted. Any packet loss will force the main
controller to devote more of its time to handling the SPI interface, delaying the primary mission.
Once a tested and reliable basic SPI interface is in place, we also plan to further reduce the load on the
main controller by programming the Battery Supervisor to analyze the battery data it collects, decide on
the appropriate response (such as turning on or off the charging circuitry), and inform the main
controller only of the required action. This could reduce the power-related work of the main controller
down to an almost trivial task, freeing the processor to devote its resources to the primary image
processing mission.
Communications Subsystem
The SNAPS satellite communications subsystem provides beaconing, data downlink, and emergency
shutdown uplink capability to and from ground stations. Beaconing and data downlink consists of
satellite status information and payload data, products of the command and data handling (C&DH) and
imaging subsystems, respectively.
Already Completed
An antenna has been designed, built, and preliminarily tested. The antenna exhibits nearly
omnidirectional directivity because it was made as a folded dipole which loops around SNAPS’ frame.
This looping was possible because the SNAPS frame was built with additive manufacturing. Preliminary
test results with the DG8SAQ VNWA 3 network analyzer show a bandwidth of over 15 MHz around
resonance with a VSWR of 2 or less.
In addition, the SNAPS team has selected a Lithium Li-1 radio by Astronautical Development LLC. The
radio uses the AX.25 packet protocol in KISS mode at 9600 baud FSK modulation, presenting a digital
command and data interface to the CDH subsystem through serial UART. With a maximum output of 5
W, the radio transmits payload data on the 70 cm
Table 2 Signal Power at Ground Station
amateur band, fed via coaxial cable to a folded
dipole antenna integrated into the spacecraft’s
plastic hull.
Finally, a link budget analysis has been completed.
This analysis estimates the received power at our
ground station from overall system components,
namely the satellite’s radio power and gain, and
receiver gain, while accounting for global losses
due to impedance mismatching and atmospheric
parameters. Table 2 shows approximate signal
power received on the ground during mission
operation. Despite conservative estimates of
downlink signal strength and path loss, SNAPS’
communication subsystem operates with a link
margin of over 11 dB.
To be done
Antenna testing still needs to be completed as some interference exists when the rest of the SNAPS
components are added to the structure. Final testing and integration will be needed to ensure the
communication subsystem performs as expected when integrated with flight hardware and software.
Tuning may be required to center resonance near 430 MHz.
The SNAPS link budget may need to be updated (for the better) if the team decides to use the much
larger Stanford dish (see “Ground Station” section).
Image Processing Algorithm
In order to most effectively take advantage of limited ground-station communication opportunities as
SNAPS is in orbit, we utilize image processing software to selectively choose frames to transmit to the
ground station, separating images of satellite deployment from the noise of the rest.
Already Completed
Presently, the image processing software, written in C, is fully-functional and has been tested on a
variety of images in our desktop development environment. SNAPS’ image processing software stack
begins by decoding a Quicktime video file recorded by the HackHD camera to a raw H.264 stream. Each
I-Frame from said stream is subsequently subjected to a series of filters, such as down-sampling and
Gaussian noise reduction.
We attempt to accurately identify images of interest from a large selection using feature detection
algorithms. We employ a well-established Canny Edge Detection algorithm followed by a corner
detector, to quantify the estimated “utility” of a given image as a function of the number of
perpendicular edges the image contains, which are characteristic of man-made objects in space.
Images that are deemed to be useful depictions of the CubeSat launch are encoded as high-quality
compressed images and saved to an integrated SD card in preparation for transmission. Code space is
significantly below our hardware constraints, and memory usage is approaching our 3.5 MB target.
To be Done
Our team is in the process of re-compiling the code-base for SNAPS’ STM32 ARM microcontroller, since
it is presently only built in our desktop test-bed environment. We are also actively engaged in optimizing
memory usage and reducing runtime, which define the crux of our major goals in the immediate future.
Memory usage reductions are intrinsically tied to our ability to compile on the ARM microcontroller,
given its physical memory limitations.
Since our mission duration is limited by SNAPS’ ability to stay in low-Earth orbit, reducing runtime for
algorithms that could potentially be processing thousands of images is of high importance. The current
image processing codebase does not leverage the robust digital signal processing (DSP) with a floating
point unit (FPU) capabilities of the STM32 Cortex M4 processor SNAPS is built on. Consequently,
refactoring parts of the codebase to leverage DSP instructions to ultimately reduce runtime is a high
priority for our team. This constitutes one major thrust of our code-review: identifying code whose
runtime stands to particularly benefit from DSP optimizations.
The final component of the image processing software involves its integration into the rest of the SNAPS
flight software, and final decisions on the encoding and preparation of images for transmission.
Command And Data Handling (C&DH)
SNAPS’ C&DH board autonomously operates the satellite. This includes initializing recording by the
HackHD camera, running the image processing algorithm, broadcasting the images through the
communication subsystem, and charging the batteries with input from the battery supervisor. The
system also handles errors and adjusts software to adjust for any hardware failures.
Already Completed
The C&DH board has already gone through two main iterations in which all hardware components were
chosen and fit onto a board compatible with the SNAPS structure. The most important component is the
STM32F40x processor which was selected because of its attractive performance, peripheral
specifications, and built-in parallel memory interface which enable large image processing algorithms to
run. Additionally, components were chosen to streamline the overall power topology and protect the
radio from overvoltage and overcurrent.
To Be Done
As the image processing code, communication subsystem, and electrical subsystem are finalized,
substantial work is required to create the flight software to allow the C&DH board to integrate all of the
components and perform SNAPS’ mission. Additionally, work is required in the department of optimal
packetization and encoding techniques for the ideal transmission of selected images to the ground
station. We will develop a packetization scheme to ensure image robustness even with packet loss. We
have already begun this process and plan to complete it in parallel with the various structural tests
SNAPS must undergo.
Ground Station
We are currently planning on using the VISION system as our ground station. We have access to this
station free of charge because it is a part of Stanford’s Space Systems and Design Laboratory (SSDL).
The team is currently evaluating switching to use the larger Stanford Dish as a ground station. With the
active support of Dr. Ivan Linscott and the Stanford Electrical Engineering department in conjunction
with Southwest Research Institute and the United States Air Force, the 46 m Stanford Dish will
significantly bolster link budget estimates, allowing the possibility of greater data rates and increased
payload data retrieval on the ground.
Testing
As our hardware components are being finalized in the next few months, we will step into testing to
ensure our craft is flight ready. We will start with shaker tests to ensure the integrity of the 3D orinted
bodies and all of the fasteners – this will be done in collaboration with NASA Ames, Skybox Imaging, and
Planet Labs, all groups who support our efforts. Second, we will perform thermal vacuum testing, cycling
the components to make sure they do not breakdown – this again will be done with NASA Ames and
Planet labs. In fact, in preparation we helped Skybox Imaging test their satellite in the NASA Ames
facilities last year, learning the process first hand. In our intended orbit, we are not concerned about
long term radiation exposure, but we will also investigate the effect of radiation on our main
components, such as the HackHD camera.
We will also perform functionality tests once software is complete to make sure SNAPS can collect its
imagery, detect objects, transmit data through its antenna, and charge the batteries with the solar cells.
Project Schedule and Finances
We expect to complete SNAPS by the end of 2014.
Table 3 SNAPS Project Schedule
SNAPS is fully funded by the Stanford Student Space Initiative (SSI). SSI has a budget of $15,000 for the
year. The SNAPS project requires little financing because the team consists of students who are
volunteering their time to learn about satellites. In addition, the team has access to the resources of
Stanford University, including the Space Systems Development Laboratory at Stanford. This provides
the team with access to resources such as IAR licenses for the software team, reflow soldering
equipment, a 3d printer, and many others.
The majority of SNAPS parts have already been obtained including the ARM processor, the HackHD
camera, the antenna, structure, and printed circuit boards. We estimate the hardware cost to be
<$10,000, driven primarily by the cost of the radio ($5,000).
Technical Feasibility Review
Internal Review Process
We met with a committee of four to provide us feedback on our technical feasibility (see table below).
The technical feasibility review consisted of the team describing the overall mission concept and
subsystems to experts in their field (displayed below). Like the merit review, we met with members of
the committee one-on-one. The technical feasibility process was not competitive.
We briefly describe the materials we presented to the committee in the sections above; more in-depth
technical detail is available in the Appendix. After presenting, committee members asked us a variety of
questions (“What is the power budget?” “Have you done a link budget analysis?”) to assess technical
merit. Finally, we asked them to provide feedback on our project’s schedule.
Name
Andrew Kalman
Ivan Linscott
Walter Holemans
Marcos Pavone
Experience
Consulting Professor in Aeronautics and Astronautics at Stanford
Founder, Pumpkin, Inc. (makers of the CubeSat Kit)
Senior Research Associate at Stanford
Chief Engineer, Planetary Systems Corporation (makers of the
Canisterized Cubesat Dispenser)
Assistant Professor in Aeronautics and Astronautics at Stanford
Feedback from the Technical Feasibility Review
Panelists generally thought our original project roadmap, which called for completing the project by
Sept 1, 2014, aggressive but possible (our current roadmap has us completing the project by December
30, 2014). Linscott described the technical roadmap as having “no showstoppers.” Hubbard was
concerned about whether SNAPS is reliable enough to survive single-event upsets, but he recognized
that the level of risk is appropriate for a 0.25U CubeSat.
All of our panelists pointed out the major technical challenge of this mission which will be ensuring that
as SNAPS is deployed and tumbling, it captures imagery of the other satellite. They agreed that by
turning on SNAPS the minute the CSD begins to deploy ensures that at least some imagery will be
captured while SNAPS is in the CSD and pointing forwards. In addition, the wide view camera makes it
very likely SNAPS will achieve its mission. Hubbard suggested modeling the initial trajectory. Linscott
suggested that we could try deploying the CSD on a parabolic “zero gravity” flight. Based on this
feedback, we plan to apply for the “NASA Announcement of Flight Opportunities (AFO) - #8” due
January 16th. We have added time in our schedule to simulate SNAPS deployment from the CSD.
Hubbard pointed out that while it is interesting that we are flying new hardware, such as the 32 bit ARM
microcontroller and the HackHD camera, it could jeopardize the mission if they do not perform. As a
result of this feedback, we decided to add an additional three months to the schedule to conduct
thermal, vibration, and vacuum testing.
Conclusion
SNAPS is a CubeSat with a great deal of technical and educational merit for NASA. The project is fully
funded by the Stanford Student Space Initiative and consists of a dedicated group of undergraduate and
graduate students. The team has already made significant progress on the satellite, completing many
key tasks like finalizing the structure and electrical subsystem design. Our internal committee reviews
confirm the team’s belief that SNAPS is a satellite with a huge amount of value.