The planning algorithm
Our planning algorithm looks for gaps in the walls. If our algorithm finds a gap in the wall, it will determine if that gap is part of a path which will lead us to the hole. If the gap does eventual lead us to the hole, then that means we should hit the ball through that hole.
Our algorith starts by looking at a straight line from the ball to the hole If a straight shot is not possible, the algorithm will look for a gap in the closest wall. After finding a gap, the algorithm will try to get a straight shot from the gap to the hole. If a straight shot is not possible, the algorithm looks for a gap in the closest wall and repeats until we can get to the hole. If we reach a dead end (we cannot get to the hole) then the algorithm will backtrack and try other possible gaps in the walls.
Our robot simulation uses gradient descent to determine the angles which should be assigned to to the joints so that the robot can both balance, and point to an (x,y) position in the world. The algorithm that we use is the one that is provided to use by Chris.
Our initial idea was to first calculate the joint angles, and then move to those angles. This didn't work because of a few reasons. First, the robot_control method does not throttle the joint movement, thus the torque of the joints was set so high that the robot would move it's legs up, off the ground and seem to float in the air before falling down and falling over. To keep the robot on the ground, we tried to slow down the speeds of the joints. This worked in keeping the robot on the ground however we ran into a second issue.
The second issue that we encountered was that when the robot moved to the joint positions we desired, it would still fall over. This is because even though the center of mass is at 0 in the final position, the center of mass is not 0 through out the movement. This meant that if the center of mass shifted signifcantly while moving, the whole robot would fall over. To fix this issue we split up the gradient descent into chucks. The simulation will run 10,000 steps of the algorithm every 3000 ticks. This means that we get good enough step sizes for the simulation to run fairly quickly, but we also get small enough step sizes that the center of mass does not shift significantly while moving.
Getting the golf club did not work. The simulation seemed to crash everytime the club was swung. So that did not make it into our final submission.
This simulation uses the simbicon code that was writen by the TA. A simicon is statemachine where each state is a set of joint angles. Furthermore, the transition between states can be event based or time based. Event based transitions occur when one of the feet touches the ground. Time based transitions occur after a set amount of time after the state was triggered. Thus it is possible to leave a state and transition to another state before reaching the desired joint agles.
We have implmented 2 different simulations. The first is where the robot walks several steps forward then stops itself and stands upright. The second is where the robot stands, crouches, then jumps into the air.
To implement the first simulation we take the walking simbicon that was provided by the TA and then repeated it several times. The sample implementation loops on itself, thus having it transition out of the loop to a new state was not possible. To fix this, we unravel the loop and make a totally sequential state machine. The four walking states are repeated until the robot is able to walk stably for several steps. After that, there is a state which tells the robot to stick its foot out very far ahead of itself to stop the walking motion. Once the robot has stopped walking (you will notice a pause where the robot's legs are streched and the body rocks forward and back) it stand upright.
The second simulation takes a similar approach. Rather than building a cycle of states, we use a linear sequence of states. First, we used trial and error to discover the proper joint angles to balance the robot while crouching. After, finding these angles we reverse the motion and tell the robot to return to a standing position. To get the robot to jump, we crouch slowly and pause. This reduces the downward momentum so jumping will be easier. Then we use the event based transitions to have the robot return to standing position. Since the robot is standing, the transitions happen instantly, thus the robot stands up fast enough to be launched into the air.
This approach initially had lots of issues because of the number of states. At first, we had 3 states, crouch, pause, and jump. However, this caused the robot to be unstable and jump wildly into the air. Also, we noticed that the robot would jump backwards. To fix the instability, we added a lot of transition states. These transition states are just a gradient of states to go from standing to crouching, and from crouching back to standing. There are 30 intermediate states for each. Additionally, when the robot jumps, it flails wildly in the air. We were un able to completely fix this problem. As you may see in the video, one of the robot legs swings very far backwards and almost swings in a full circle.
VideoWalk Then Stand