summaryrefslogtreecommitdiff
path: root/software.mdwn
authornatronics <natronics@web>2013-11-06 20:58:49 (GMT)
committer wiki <iki-wiki@psas.svcs.cs.pdx.edu>2013-11-06 20:58:49 (GMT)
commitc224b3a5b7e88aacdf292c7715549d911f11c771 (patch) (side-by-side diff)
tree5bf6e67d21d4046f10dd008ddd13782da5d07a94 /software.mdwn
parent7a6db73495952306c5afeb12cda3ab9df9356894 (diff)
downloadwiki-c224b3a5b7e88aacdf292c7715549d911f11c771.zip
wiki-c224b3a5b7e88aacdf292c7715549d911f11c771.tar.gz
Trying to write about what we do here.
Diffstat (limited to 'software.mdwn') (more/less context) (ignore whitespace changes)
-rw-r--r--software.mdwn48
1 files changed, 46 insertions, 2 deletions
diff --git a/software.mdwn b/software.mdwn
index ad3e647..0d34722 100644
--- a/software.mdwn
+++ b/software.mdwn
@@ -4,9 +4,53 @@
[[!toc levels=3]]
-## Flight Computer (FC)
+## Software at PSAS
-### The Flight Computer
+Our biggest challenge at PSAS is making a rocket, in theory, steerable. This requires a monumental effort in all the major engineering fields. In addition to having an actual rocket one needs excellent electronics to provide sensor measurements and to actuate controls, and the software to run all of it. In order to write software like this you also need testing frameworks and some kind of simulation of flights to debug the main flight software. These layers of complexity make up the software project at PSAS.
+
+
+### The Problems With Spaceflight
+
+Why are rockets hard? One of the most interesting things about building a space program from scratch is finding out that the problem often isn't where you think it is. Could you just build a giant rocket motor and light it? Yes, you could. But it won't do what you want. Instead of going up will arc in an unpredictable direction. The parachutes wont fire at the right time, and you'll never find it again because you won't be able to track it.
+
+> The hard part about rockets is often everything **around** the rocket
+
+This is a truth of building a space program. How are you going to handle communication? Sensors? What are you going to program? How are you going to test that? How are you going to test your test framework?
+
+
+### Current Design Philosophy at _PSAS_
+
+We've been attacking all these problems and more in different ways for years. We're now starting to bring this experience together into a cohesive design.
+
+There are two basic modes for our program:
+
+ 1. Testing
+ 1. Launch Operations
+
+#### Testing
+
+We spend 98% of our time on the ground. That is, not actually launching a rocket (launches are expensive and only happen once a year). But we still want to be able to run all of our software _as if_ we're actually above the ground. This means we spend a lot of energy trying to design a good, usable test framework. We also need a simulator for almost every aspect of the rocket. We also like to be able to run as much software as possible on generic hardware so people can work on ideas on their laptops or test boards and do not need the expensive, one-of-a-kind, flight computer to get work done.
+
+#### Launch Operation
+
+When it's time for a launch we have to disable all the testing bits, and make sure we're in a good launch configuration. We can drop all the simulation and testing work and boot the real flight computer. We need logs of everything during a launch so we know what happened after the fact and can plan better for future launches.
+
+To this end, most PSAS software has some kind of production switch.
+
+
+### Major Softwares
+
+The high level view of programs running in the two modes look like this:
+
+#### Testing
+
+
+#### Launch Operation
+
+
+# Flight Computer (FC)
+
+## The Flight Computer
[[AV4|avionics]] is an Intel Atom based flight computer, connected via Ethernet to Cortex M4-based sensor nodes. Wireless 802.11a telemetry to the ground during flight.