Reasoning
The technique that I used is a sort of model-based control and minimum time control. First I developed a model of the system using Mathematica. Then I wrote a program that used this model of the system to create a look-up table. I then wrote a non-graphics simulator of the pendulum to test the look-up table. The next set of programs I wrote had the 332 sending data to the Sun and the Sun was using the look-up table to issue motor commands to the 332. Finally, I wrote some Matlab code that would re-estimate the model parameters based on collected data. From these newly re-estimated parameters, I made an improved look-up table.
The above picture is a lookup table which stopped when the start state
was reached. The start state is indexed at 250,250 (center of the
plot) and the goal state is indexed at 250, 420 (near the top in the middle).
The blue color is either not visited or zero torque command. The
yellow color is a negative torque command. The red color is a positive
torque command.
Table Generator Code (zipped)
This simulator program simply had the same model of the system that
I used to get the look-up table. For each time step, it used the
lookup table just as the real pendulum would.
Simulator Code (zipped)
These programs communicated between the 332 and the Sun. The 332's
function was to 1) collect data from the pendulum and send it to the Sun
and 2) receive commands from the Sun and translate them into motor commands.
The function of the Sun was to receive data from the 332 about the state
of the pendulum, find the appropriate command in the look-up table, and
send that command to the 332.
Pendulum Invert Code (zipped)
The first problem was easy to fix, the second require more work.
In order to keep the pendulum invert once it was pumped up there, I uploaded
a smaller look-up to the 332 itself (since it does not have enough memory
to handle the entire look-up table). The speed of this lookup table
(updated motor commands every .01 seconds) was enough to keep the pendulum
inverted. The program below was used to take a small "snapshot" of
the inverted region of a larger look-up table. This table has less
gaps than a small table generated from scratch.
Snapshot Code (zipped)
Even in this variation, the pendulum would not always stop on the top. The look-up table effectively added energy to the system very quickly - the swing-up time was very small, owing to the minimum time control. However, more often than not, the momentum of the pendulum was enough to swing well past the inverted position instead of stopping. This could have been a result of not having learned the parameters well enough. My personal suspicion is that it is a result of the fact that I couldn't use the same look-up table for the entire trajectory and that there are gaps as a result of the switching.
The final problem that I had was that I could never get the two different methods of estimating the model parameters to exactly agree. One of the parameters would always almost exactly agree, while the other two parameters would be in the same range. This may have been a result of the discretation of the data, but I could not track down the root of the problem.