Back to the Basics
Top down approach
The long term goal of PSAS is to send a nanosatellite into orbit. The satellite really only needs to orbit once to validate our project. What do we need to go to orbit and release the "coke can satellite"?
The coke can satellite must have:
- communications down (to validate our claims that we met our goal)
- antenna
- webcam (can be low quality)
- power - solar and batteries
- shell (aeroframe)
- GPS (?) - will it work in low earth orbit?
- GPL-GPS - would be cheap and could get around the 8 mach/64,000 feet limitation of most commercially available GPS boards.
The satellite described is similar to the "cubeSat". These small satellites are built in university classes at Stanford.
Space agencies have a set weight requirement for the cargo in their rocket. If they end up loading all the gear they need and still have a few extra pounds that need to be filled, they will "rent out" that free space. The university loads the cubeSats into the rocket, and they will be released into low earth orbit.
Bottom up approach
To get a satellite into orbit, we need a thrust-vector controlled rocket. The rocket must be able to go straight up, then curve horizontally and release the satellite (so that it doesn't get pulled into the earth's gravitational well).
The satellite will eventually get pulled down toward earth due to gravitational forces and friction from molecules in the atmosphere. This may take several days, and a motor on the cubeSat would make the orbit last longer.
The satellite (and rocket) will need to withstand extreme temperature changes, radiation, and vibration.
Rocket Requirements
- big (need high-class motor to make it up, large airframe)
- PSAS really can't afford to build a big rocket, but we could load our avionics into another group's airframe.
- controlled trajectory (orbital insertion trajectory)
- OPEN SOURCE (hardware and software)
- this is mostly an educational project, and we want other groups to be able to duplicate our efforts
- minimize cost and development time
- maximize coolness
Sensors
- GPS
- gives an absolute position and altitude
- GPS has a constant built-in error, so there is a "sphere" that represents your location
- derives velocity from the Doppler shift
- IMU
- gives position over a small time scale
- position is relative to when it is turned on
- position drifts over time - t2 drift over time because we have to integrate twice
- 3D Magnetometer
- pressure
- temperature
We want position, velocity, and acceleration on the x, y, and z axises. Each sensor has an associated error (denoted by placing a "hat" over the measurement) and we want to minimize that error.
Trajectory Control
There are several ways to achieve orbital insertion trajectory.
One way would be to have fins that are motor controlled; changing fin position will cause the rocket to change orientation. However, this stops working as the air gets thin (around 60,000 feet).
Another way to control trajectory would be to use "thrust-vector control". One implementation would be to allow the motors to be pivoted. Changing the motor angle would change the rocket's orientation. Ideally, there would be four motors that could be controlled separately. A more difficult implementation would be to create an "oxidizer" control system. The system would control the oxygen/fuel mixture of the motors and control the thrust from each motor.
In either case, we would need to have very good sensor data to control these systems.
Architecture
There are several models for the avionics system that have been discussed:
- star model - flight computer is central, with many branches from it to each sensor
- peer-to-peer - sensors are all on one bus, and pass needed data back and forth on their own
- flight computer model - like peer-to-peer, but FC controls data transfers
- could be a serial bus or a parallel bus
Would be nice to be able to send the firmware for the nodes across the bus and have them be dynamically configured.
High bandwidth sensors:
- GPS
- either COTS (commercial off the shelf) GPS
- or GPL-GPS (General Public License GPS)
- IMU
IMU takes up 40% of the current CAN bus, so it may make sense to put it on a separate bus. This may also be combined with pressure and temperature sensors on a separate bus. Testing will have to be done that shows how much bandwidth the IMU takes on the CAN bus.
Low bandwidth sensors:
- APS (avionics power supply)
- ATV
Current Flight Computer
Men Micro board:
- Power PC architecture
- uses MPC5200 chip
- SPI (Serial Peripheral Interface)
- I2C
- two CAN buses
- two serial ports
- USB
- ethernet
- PCI
- PCI-104 form factor
- Uses Motorola CAN chip
Limitations of the current flight computer:
- there have been issues with the MPC5200 chip (rev C works)
- other boards may have more USB ports
- this board will need to have a breakout board for connections
There aren't many "middle-line" Power PC chips - most are either low-end or high-end. This was the only board that offered what we needed and conformed to PCI-104. There is another board that isn't PCI-104 form factor that may work. (Andrew, link?)
Misc
Glenn proposed an older fly-by-wire system used by the military. The pros and cons were discussed. (Glenn, link?)
SMAD - space mission analysis and design - large book, but a good resource
Action Items
- Read the 1999 white paper.
- Where can we get a good Wiki math attachment? (Emma?)
- http://johannes.sipsolutions.net/Projects/new-moinmoin-latex (better choice?)
- http://moinmoin.wikiwikiweb.de/MathMlSupport (does this actually work?)
- reference: http://mcelrath.org/Notes/WikiEngines
Next meeting
Wednesday, January 4th, 2006 - FAB155, 7pm. Professor Faust will be attending. (Didn't show.)