This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

• I used an external XML parser called CMarkup, it is free for non-commercial use and it handles all of the silly cases the TA’s give us just fine (just remember to xml.ResetMainPos(); after parsing the board so it can still parse the history even if it came before the board in the xml file.
• I only wrote two GetCandidateMoves functions.  One for my Piece class and one for the Pawn class.  I just defined directions for each piece, and the main piece move method just got squares in each direction until piece was found or it went off the board.  The pawn class was special just because it had special cases for the first move and capturing moves
• I wrote a couple of methods in my main Game class that checked for Check and Checkmate (which also shared some child methods).  Stalemate was simply when it is Checkmate but not Check (with the way I wrote those methods).
• I had memory issues until I took all pointers out of the MoveHistory.  I ended up just saving the piece type and color in the move history instead of a pointer to the piece.  I had issues leaking memory since sometimes I was putting pointers from the pieces saved in the Board class in the MoveHistory then other times I was putting pointers from the Board class in the MoveHistory.  So, so pointers in the move history.  And I made the board basically be the holder for all of the active piece pointers.  When a piece was captured or created, that is when I called delete or new. ( And the board destructor would clean-up any pieces left on the board when exiting or deleting the board before loading a new file).

Another project done for Steven Hansen, and now I am done with a CS minor and a EE major.

A fundamental piece of the project was actually controlling the steering angle and driving speed of the robot in order to successfully navigate the complicated pylon courses. After deciding early in the semester that we would drive directly towards the pylon we simply had to build an algorithm that could use the vision data to perform that principle action. First we created a few principle parameters that would be used throughout the control code. This including the parameters for driving straight speed, turning speed, number of encoder ticks to count per radian, and the distance before pylon to start turning. We were able to first successfully run the control code through the given simulator. Which allowed us to do some initial adjustments to our design and test our idea of driving directly towards the pylon.

We implemented this design with a simple state machine. During iterations through the main loop it would call the control state machine after analyzing a new frame of data from the camera. The state machine consisted of 6-7 states that the truck could be in at any given moment. The states included:
1. Pylon searching. During this state it was assumed that the pylon was in the given view. However it would only move out of this state when the vision software successfully recognized a pylon. If no pylon was currently recognized our final design simply had the truck continue straight at a slower speed while giving the vision algorithm more passes to analyze the data.
2. Pylon following. During this state the truck would make simple steering adjustments in order to maintain the pylon x-coordinate plus the width of a pylon in the center of the truck. Bigger distances from the center of the screen would mean larger adjustments of the steering angle during this state. The truck would continue in this state until the distance from the pylon was calculated to be less the threshold set in the global parameters as the distance before the pylon to turn.
3. Setting up the turn. There were two hard coded states that depended only on the parameters set for the truck. These two steps including turning slightly away from the pylon in the opposite direction then needed to be turned around the pylon and then driving straight a set distance in order to line up with the pylon nearly perpendicular from the line at which it was driving towards the pylon. If the vision consistently gave accurate values for the distance of the pylon these state worked perfectly every time. We assumed during this state that we would lose site of the pylon and we therefore did not use any of the vision calculations while in these states.
4. Dead-Reckoning turn around the pylon. Upon entering this state we simply saved the current Encoder value plus the number of ticks we needed to travel to complete the turn. This extra number of ticks was calculated by the angle given in the course description. When we approached a pylon of the same color as the previous pylon we added an extra 10 degrees to every turn due to the manner that we were entering the turns from an angle slightly less the perpendicular to the line straight from the previous pylon. When the truck approached a pylon of a different color then the previous pylon we added an extra 45 degrees to the turn in order to compensate for the fact that in this case the truck was crossing over the straight line between the two pylons and actually entered the turn much further back in the turn. The number of ticks per radian was set by a global parameter that we also could change through our gui. This variable of the ticks per radian needed to be adjusted when we tested new faster speeds navigating the course. When the calculated number of ticks had been completed the truck then moved back into the pylon searching state.

Full Chronological Review and other files