summaryrefslogtreecommitdiff
path: root/FCSoftwareRequirements.mdwn
authorPeter Welte <shark@centibyte.org>2007-03-25 04:08:10 (GMT)
committer Peter Welte <shark@centibyte.org>2007-03-25 04:08:10 (GMT)
commita13245e19910bad5f3bba0f536f9b35fbf6ce43a (patch) (side-by-side diff)
treeffcaec9c714386f43182c0425a93f6ceef3c5bad /FCSoftwareRequirements.mdwn
parent3e330807b1af8d48ef44138db841fbbb9f609858 (diff)
downloadwiki-a13245e19910bad5f3bba0f536f9b35fbf6ce43a.zip
wiki-a13245e19910bad5f3bba0f536f9b35fbf6ce43a.tar.gz
FCSoftwareRequirements: changed mode description, created 'config' section, and a bit of cleanup
Diffstat (limited to 'FCSoftwareRequirements.mdwn') (more/less context) (ignore whitespace changes)
-rw-r--r--FCSoftwareRequirements.mdwn33
1 files changed, 17 insertions, 16 deletions
diff --git a/FCSoftwareRequirements.mdwn b/FCSoftwareRequirements.mdwn
index 4f52542..1f8b438 100644
--- a/FCSoftwareRequirements.mdwn
+++ b/FCSoftwareRequirements.mdwn
@@ -117,11 +117,9 @@ This section describes any software, hardware, and communication interfaces the
#### Modes
-- This section describes the modes of operation of the software (see also [[FlightComputerStateFlowSep2003]] and [[StateMachineApr2003]]). The requirements/behavior of the software are different in each mode.
-- Idle
-- Armed
-- Recovery
-- _**TBD**_
+- The software may have two "modes": in-flight and debug. Within those, there are a number of states (as described in [[FlightComputerStateFlowSep2003]]) in which the software has unique requirements.
+
+Debug mode has a superset of requirements, mainly that debugging information may be made available and that it should be possible to force the software into any of its states.
### Product Functions
@@ -169,22 +167,25 @@ As a reminder, specific requirements include the following types:
The following are specific requirements, organized primarily by functionality. The "flight sequencing" functionality _**might be**_ organized by state with some things to do in each state. There is a section for non-functionality requirements ("Other Requirements") at the end.
-1. Flight Sequencing: the software controls flight sequencing based on internal state machine, input from other subsystems and uplink data.
+1. Configuration.
+ 1. The software should have a method to configure whether or not antennas should be powered up.
+ 2. The software must have a way for users to specify GPS position of the launch site, and starting barometric pressure at the launch site. [See setbase.sh and sequencer.c from old software; the software uses it to help detect liftoff].
+ 3. The software should have a way for users to specify the Ameature radio callsign for the ATV node to use.
+2. Flight Sequencing: the software controls flight sequencing based on internal state machine, input from other subsystems and uplink data.
1. The software will initialize with a "power on self test" that determines which nodes are currently active in the system, then enter a valid state in the state machine (see [[FlightComputerSoftware]]).
2. Recovery Node: Software sets recovery node timer to TIME\_TO\_APOGEE seconds before launch. If software detects timer has &lt;= 1 second but doesn't think the rocket is at apogee, set timer to 4 seconds.
3. The software should detect launch and enter appropriate state.
- 4. The software will have a manual override to exit the launch-ready state.
- 5. If a force state command is recieved from Launch Control, that state will be entered. The possible force state commands are ARM, LAUNCH, ABORT, DEPLOY\_DROGUE, DEPLOY\_MAIN.
- 6. The software must have a way for users to specify GPS position of the launch site, and starting barometric pressure at the launch site. [See setbase.sh and sequencer.c from old software; the software uses it to help detect liftoff].
- 7. The software should have a way for users to specify the Ameature radio callsign for the ATV node to use.
+ 4. If an FC\_ABORT\_LAUNCH command is receieved from Launch Control the software enter the appropriate abort state if one is defined. If no abort state is defined (for example, once the motors ignite and launch is detect it is impossible to abort) the event will be logged and no state change will occur.
+ 5. If an FC\_FORCE\_STATE command is received from Launch Control while in debug mode, that state will be entered.
+ 6. If an FC\_REQUEST\_STATE command is received from Launch Control requesting the software to enter the next expected state, that state will be entered. Requests to enter an unexpected state should be logged.
+ 7. The software must detect apogee based on sensor data.
8. The software must send signal to hardware to deploy drogue at apogee.
- 9. The software must detect apogee based on sensor data.
-2. Collect Rocket State Information
+3. Collect Rocket State Information
1. The software should read all sensor data as frequently as possible while still meeting all other requirements (like apogee detect) from the IMU and GPS
2. The software should get, log, and report over wifi voltage, current, and charge from the APS node at _**TBD**_ intervals.
3. The software should get, log, and report over wifi state of pyros and timers from REC node at _**TBD**_ intervals.
4. The software should get, log, and report over wifi disk/log usage information at _**TBD**_ intervals.
-3. Interact with ATV node. The software should send the following information to the ATV node for overlay, as often as it changes:
+4. Interact with ATV node. The software should send the following information to the ATV node for overlay, as often as it changes:
- Mission (e.g. "LV2")
- Ham callsign
- FC Status (e.g. Safe, Armed, Boost, etc)
@@ -194,18 +195,18 @@ The following are specific requirements, organized primarily by functionality. T
- time left on recovery node timers if they are set
- altitude from pressure sensor
- APS node voltage &amp; amps
-4. Logging to flash
+5. Logging to flash
1. will have no discernable impact on other processing
2. will guarantee 100% logging of all packets up to the limit of the log buffer
3. will deal gracefully with log buffer overflow; if necessary, will discard oldest data first
-5. 2\.4 Ghz downlink
+6. 2\.4 Ghz downlink
1. software will tolerate 100% failure of link
2. when resuming from a failure, will process most recent data first
3. should process 10 ping packets per second from the ground to Flight Computer
4. Telemetry data will be sent over the wireless link with Launch Control.
5. Important software state information will be sent to Launch Control.
6. wifi link quality should be measured in flight
-6. Other Requirements
+7. Other Requirements
1. Safety
1. The software must be able to abort the launch if it is commanded to do so before the motor has ignited.
2. The software must be able to abort the launch if it has detected any error before the motor has ignited.