Airframe Team
The airframe team is in the initial design phase for the LV2 rocket and is doing some preliminary prototyping and modeling to help in the process.
- Brian brought in a prototype of an airframe module and fiberglass aero-skin.
- Roger and Maggie have drawn up the current airframe concept in CAD (lots of great color pictures).
- Maggie is doing a Finite Element Analysis modeling to understand the loads on the modules.
- Modules are having 200, 400 and 600lb compressive loads put on them to see when and where they buckle.
- The AF team is going for a 0.60 mass fraction - which is very aggressive for us compared to the 0.13 mass fraction on LV1.
- Tim pointed out that we should do an initial accounting of how much each system will potentially weigh so that we can see if we're in the ballpark for the proposed mass ratio.
Propulsion Team
The propulsion team is currently developing a half scale motor or "O" motor. Another test is planned for the near future.
- 50-60lbs of fuel for a "P" motor
- Motor 136mm (5.354") in outer diameter; needs an adapter to 6" inner diameter of rocket airframe
Ground Support
- Jimmy is modifying the rail into something more controlled than the C channel.
- Dennis is building clamshell fall-away launch lugs. Needs access to a milling machine.
- Still using the LCM. It will require some work, including camper jacks, so that one person can load and unload it.
- Bart suggests we appoint a safety officer. We then appointed Bart to the position.
PSAS Scheduling for 2001
- September 2001 Launch of LV2: Primary mission is to test the airframe on the M2400
- Most likely at at Black Rock
- Possible multiple launches using Propulsion Team motors if available
- Launch with minimal avionics (commercial system?) - if there are any PSAS avionics, we'll launch it as a payload.
- Multiple launches would enable us to test the avionics multiple times.
- Andrew brought up the idea of petitioning the FAA to open up Oregon airspace to 100kft (or enough for LV2).
He'll email Ron and see if we can figure out a new place which might be conducive to such high altitudes.
Avionics Team (Met after General Meeting)
- LV2 Goals for the Avionics Team:
- We want to know what's going on all the time (e.g., telemetry equal to or better than LV1b)
- We want to control where the thing goes (e.g., INS)
- We want it to be reproducible (e.g., cheap COTS components so everyone (including us) can make these things)
- LV2 September 2001 Mission goal or the Avionics Team:
- FC, COM, GPS, IGN modules on launch but flying as payload (in avionics bus) for flight test - commercial avionics should probably run the first launch unless we feel really good about ourselves.
- On the 2nd (or later launches), we'll go with our launches only.
- LV2 Avionics Architecture
Hardware vs. software architecture: If it were up to Andrew, the functional interfaces would all be dictated by hardware, so that there would lots of little tiny CAN nodes all talking to each other, confining complexity to the bus and not the nodes. If it were up to Bart, there would be one big moosey processor (BMP) running the show. We all discussed the relative merits of each approach, and obviously came to the conclusion that a hybrid approach is probably best. The question now is where do we draw the lines. Some interesting questions are:
How hard is the CAN bus to debug, especially if we have devices sharing information (multiple masters) vs. everyone talking to a host CPU and it talking back to each node (a logical star)? Another way to put that is: How much easier is it to debug a serial data flow (logical star or close to that) vs. a parallel data flow (multi-master)?
If the difficulty of debugging grows like the # lines of code cubed, then does distributing the code out into little processors go like summations of n^4 (per processor) or is it still n^4 no matter how you distribute it in hardware?
Do we really want to use tiny 8bit micros? What about using a BMP for each node? Some options include a StrongARM with a separate CAN chip, but we'll probably need a FPU for the INS so something like a PowerPC MPC555 might do well.
What about OS's? QNX or Windriver? Real Time Linux? Roll our own?
- Where the rubber meets the road: One of the first things we need to think about is the bare bones system we're going to use. What kind of batteries? What's the shore connection like? What kind of card cage and connectors? vertical or horizontal mounting of the PCBs? Who can we get to design the cylindrical patch antennas? How do we attach the patch antennas to the outside of the rocket? Etc etc.