PSAS/ news/ 2005-12-20 - Capstone Team: Goals of PSAS and how they relate to the capstone project

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:

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


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.


There are several models for the avionics system that have been discussed:

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:

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:

Current Flight Computer

Men Micro board:

Limitations of the current flight computer:

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?)


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

Next meeting

Wednesday, January 4th, 2006 - FAB155, 7pm. Professor Faust will be attending. (Didn't show.)