Path Parser ends a square early

[amiller27]

When the robot runs through the above maze, starting in the bottom left and going to the top right, the path parser gives a solution which makes the robot stop in the cell one south of the target

[awglyde]

I found some use cases that fail to parse the motion correctly.

The original issue use case: kNorth, kEast, kNorth, kNorth

A use case I found while debugging (only gets to the first east, ignores everything else): kNorth, kNorth, kEast, kNorth, kEast, kEast, kEast

Edit: the paths above are absolute paths through the maze

[ghost]

If I remember correctly, we thought this bug only occurred when the robot enters the finish cell from a straightaway. I wonder if what's actually happening is the path parser is just stopping at the last turn. That would be consistent with our previous guess and with your new observations.

[awglyde]

The original assumption is close to accurate. When the mouse exits a turn and needs to move forward it fails to do the last move because of the underlying queue structure. It pops a North (i.e. forward) off the queue to determine how to exit but never pushes a forward.

You saw this as missing the last move in the maze photo above because there were a series of forwards. It was truly missing the first forward of the series not the last. Thus the logic for the diagonals was the problem.

I've attach photos of the some problem mazes (warning: I drew them on a white board):

20170302_142639 20170302_143503 20170302_144804

It would be a good idea to test those explicitly as well as some random maze configurations. Likely those that have diagonals as that is what my fix affects.

[ghost]

Three test cases that don't work on 39528ea926f2fff2b0cda3ac0a8e036aa2174db0.

[ghost]

See #122.