There was a fairly narrow range of approaches taken.
- Quintic splines with knot points. This was a popular choice.
- Dynamic programming. Several people tried this. This method proved tricky.
- PD gain scheduling and Energy methods. These were based on observations about the particular properties of this problem. DP and splines, by contrast, are more generic. Some people used gravity or friction compensation with their PD controllers. That is, they computed the torque mgl/2sin(theta) due to gravity and applied a feedforward torque to counter it. Doing this causes the pendulum to act as if it were in a gravity-free environment, and it can be easier to find Kp and Kb values that work over the whole range of the pendulum's motion.
- No one tried A* search or other search methods.
A tip to keep in mind - Look At The Data. You need to have data to justify claims you make about the behavior of your programs. I saw a number of people make claims about why things were or were not working for them that seemed suspect and were not backed up by data. Your writeups should contain plenty of figures that you can reference to substantiate your claims. Here is an example of the number of figures I would like to see.
Remember, the writeup is more important than the code. Even if your code didn't work out the way you wanted, I still want to know what the ideas were. And I do need all the code. Some people only gave me what they thought was the core of their code. I need to be able to look at everything and run your program from start to finish.
Aim for simplicity and clarity.
Several people changed the scoring function to make it work better with their approach. Don't do this. The problem is exactly as specified in the sample code. Also, be careful about introducing inadvertent changes into the dynamics when transcribing to another language like Matlab from the sample C code.
I gave grades ranging between 50 and 80. They were distributed as follows:
