You can get pictures and a QuickTime movie (thanks to SOAP) of our robot from my personal web space at school:
http://www-personal.engin.umich.edu/~chibner/first/2001
Removing auto-balance from our code wasn't a big issue since our balancing method was pretty fool-proof. The only reason for doing it automatically is because it would have been faster. The reliability was the same either way. To balance, we did the following (if you watch the movie, you can see all of the step pretty clearly):
1) push the goals onto the bridge so that they are out of balance toward the far side of the bridge. When the bridge went to rotate over to the other side (since we pushed it out of balance), the bridge would hit our bridge sensor / bridge stop, keeping the bridge from going all the way to the other side.
2) Pull the near goal back toward our robot to balance the bridge.
3) Our bridge sensor sends a signal back to the player station (it turns on an LED) when the bridge is not balanced. As soon as the light goes out, we stop pulling the near goal toward us.
4) Release the goal and back into the end-zone.
To automate the process, you remove the LED and hit a button that starts moving the near goal back until the sensor says the bridge is balanced at which point the routine lets go of the goal. It would have made the process faster, but it wasn't at all necessary since the sensor provides good feedback to the drivers.
So, what did we do with all of our code space, you ask? If you look at the pictures and the video, you can see that our arms had a lot of joints (necessary to pack into the starting position and to reach far enough to tip the bridge out of balance when pusing the goals onto the bridge). There is no way a human could control that many joints without automatic, feedback control.
To control our arms, we made a small model of one side of our robot's arms (only one side is needed since the robot is symmetric) that sits in the player station. The driver would move the model arm into the position that she wanted it to go, and the control algorithms would then make the actual robot follow the model robot (we won the leadership in control award a nationals in 2000 for doing the same thing with out 2000 robot).
Since we had 3 joints per arm, our robot requires 6 control loops to run at all times. This is what took up most of the memory and code space. Then once you add in the drive train, the bridge sensor, and all of our pneumatics, we didn't have enough room to add the auto-balance.
In terms of the actual code, I didn't do the programming, so I don't really know what our programmer (Dave Purola is his name) did. I asked him once and he described it to me and it was fairly complicated so I didn't fully pick up on it.
Dave works in test engineering here and they use PBASIC to do some simply control with their testers, so he's extremely familiar with it and has years of daily experience to learn all of the tricks. I could try to track him down and get a full explaination on what he did, but Dave is one of those guys who doesn't do anything unless absolutely necessary, so I wouldn't hold your breath waiting for a white paper or anything.
I would suggest that you go the programming seminars at the kickoffs and learn as many tricks there as possible. Unless you do something really crazy, you probably won't need to do anything like we did.
The big reason that I always want a better micro to allow more control is because our team is based in an electronics place. What we do is control things. That plays to our strength. The only mechanical engineering we do in our building is putting boxes around the electronics (there aren't too many moving parts in a box and bracket
). Getting a little more flexibility in the controls helps us to get over our mechanical shortcomings.
-Chris