System Requirements
We decided to break up the requirements into "blocks", where "block 1" is the absolute minimum system we need to launch, "block 2" is the nice system we'd like to launch but it may be finally complete after several intermediate launches, and "block 3" is the future full functionality we've always been working towards.
[CP] = critical path: critical tasks with lots of unknowns
Block 1 Requirements:
- Fully functional Flight computer software (see software requirements below)
- Working recovery node [CP, Tim]
- FC and Timer-based recovery ejection
- Working ATV system [Glenn]
- More reliable/capable power system [Timr]
- WiFi amplifier [CP, Glenn]
- Cylindrical Patch Antennas [CP, Andrew, w/Glenn]
Block 1 Software requirements:
- FC [James, w/Andrew & Tim]
- IMU [CP] [fake INS]
- Pressure
- Timer (coordinate w/recovery node timer)
- GPS [Jay, possibly Russel]
- Detect: launch, chuff, apogee, recovery (mains @ 600m)
- FC->LTC [James? Larry?]
- Rocket Ready
- Init code
- FC infrastructure
- CAN Driver [CP, Ian]
- FC WiFi comm test [Vinay?]
- Cantelope [Larry, w/Andrew & Markus]
- Rocketview [Dave]
- Launch Control [Peter]
Block 1 Questions:
- Change software architecture now or later?
- What CP items are we forgetting?
- When's the soonest we can get Block 1 done for a launch?
Block 2 Requirements:
- GPS overlay on ATV
- Working v2 2m board
- Stable power system (at least better APS firmware, larger battery pack)
- Full IMU message bandwidth
- Final camera mounting
- RF Tuning/Refactor cabling
- Real INS code w/fake GAINS (GPS position reset)
- 2m/WiFi comm testing
Block 3 Requirements:
- RTLinux
- GPL-GPS
- Real GAINS (GPS-aided inertial nav calcs)
The plan here is that we schedule a time that these subpieces are integrated but not tested, and that is the time at which we could plan a launch date.
Dead Tree Report
We need to write a report on our exploded rocket, where that left us, and where we are going.
Other ideas
- Board redesign for recovery node with
- 1-axis accelerometer
- pressure sensor
- detects: launch, chuff, apogee
- sell it?
- Partially-populated IMU board, marry to current Recovery board
Software discussion
Architecture:
We had a long talk about BlackboardArchitecture with threads and mutexes and condition variables, versus the existing FifoArchitecture structure. The process/FIFO environment has been fairly easy for people to develop and debug so far -- allowing us to actually develop an application. It seems to break down in fine-grained message dispatching, in the need to packetize the conversations between various tasks, and in the uncertainty of the contents of the producer/consumer mystery fifo (deadlocks? livelocks?). Moving to a new architecture requires someone to actually create a demonstration based around our existing application -- significant effort, but it would also clear up any possible Grass is Greener idealism about the scheme. Since the meeting the whole multi-headed issue of FlightComputerArchitectures has been given its own TWiki topic.
CAN Driver:
There is a class project afoot that Bart will coordinate. Needs lots of input from James, Ian. Hopefully a nice, clean 82527 implementation that gets us what we need. It's also likely the class will be able to buy another MOPS520 board to be able to write the driver.
?JamesPerkins and IanOsgood talked about findings on the current CAN driver and massaging it to do RTR messages without expecting a response with matching message id.
Bart's Requirement List:
- turn the existing RTR "read" into an ioctl
- exclusive open
- single file descriptor can both read and write (driver would allocate two onchip message buffers for read/write open)
Cantelope
?LarryLeach reports it needs to be made working. First step: Andrew and Markus will get two prototype hardware boards together with firmware within the next few weeks.