
Reasoning
What I didn't plan on was the memory limitations that are inherent in multi-dimensional arrays. The pendulum look-up table required a 2 dimensional array (example - 100x100 = 1,000 elements). The acrobot requires a 4 dimensional array (example 100x100x100x100 = 100,000,000 elements). Not only does the look-up itself get very large and overwhelm the system memory, the queue I used to do a breadth first search (BFS) to build the look-up quickly used up the system's memory. Thus, I was forced to go with very low resolutions (25x25x25x25 = 390,625 elements).
The success of this approach was limited, partially because of this memory problem and partially because I ran out of time to research the problem. I didn't get the chance to develop the code that learns the parameters of the acrobot model so the only trials have been on an estimated model.

These programs communicated between the 332 and the Sun. The 332's
function was to 1) collect data from the acrobot 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 acrobot, find the appropriate command in the look-up table, and
send that command to the 332.
Acrobot Invert Code (zipped)
As you can see above, the acrobot never got close to being inverted. It would oscillate in a scissoring motion at about the same amplitude as shown above and never break out of this rhythm.
I also implemented the simple pumping heuristic described on Gary
Boone's Acrobot
Page. While this was easy to do, the behavior of the acrobot
performing this task was very interesting. Here is the code:
Heuristic pumping code for 332 only (zipped)
Heuristic pumping code that uses the sun
to collect data and issue commands (zipped) (used to collect data above)
It is interesting to note that the time lag induced by communicating with the sun resulted in a much slower swing-up response, although it is not rigorously documented here.