Week 9: Improving the Path Finding Algorithm based on the Verilog Simulation

Welcome back, everyone! Last week, I spent time debugging the Verilog simulation that encountered issues with specific obstacle positions. These positions, with coordinates (column #, row #) at (1,2), (2,2), (1,3), (2,3), (3,1), (4,1), proved a significant challenge, but I’m happy to share that I successfully resolved them.

The starting location, initialized at (0,1), represents the initial state of the system, while the destination coordinates, at (5,3), represent the desired final state. The state machine implementing the path-finding algorithm compares destination column 5 with starting location column 0. Since destination column # is more than the starting column and the next column position is not occupied by the obstacle based on the grid map, the state machine moved to a state where it incremented the column to 1. Since the current column 1 is still less than destination column # 5 and the next column position is free from obstacles based on the grid map, the state machine remained in the same state and incremented column # to 2. Then, the state machine compared the current column position 2 with the destination column 5. Still, the next column position occupied the obstacle, so the state machine moved to a state where it would change the row position.

The current position was at (2,1), and the state machine wanted to change the row position. The current row 1 was less than destination row 3, but position (2,2) had an obstacle. In the previous state, the state machine encountered position (3,1) and an obstacle. So, the state machine was stuck. In such a situation, if the next column and next row both have obstacles, the state machine would move to a different state, which indicates a ‘move blocked’ status. In this state, the machine would make the opposite decision, meaning if the destination row is more than the current row, instead of incrementing the row, the state will decrease the row. With this fix in the state machine, the machine moved to a state where it would decrement the row to 1 and move to location (2,0). With the current row to be 0, the state machine could not decrement the row further due to grid size limitation; it moved to a state where it would increment the column.

With the current column being 2 and the destination column being 5, the next column position is free of obstacles. The state machine incremented the column to 3 and moved to location (3,0). Since the destination column 5 is still more than the current column of 3, and the next column position did not have an obstacle, the state machine incremented to column 4 and moved to location (4, 0). Since the destination column 5 is still more than the current column of 4, and the next column position did not have an obstacle, the state machine incremented to column 5 and moved to location (5, 0).  With the current column at 5, the destination column, the state machine moved to a state where it could change the row. This summary of the state machine’s movement demonstrates its successful navigation to the destination location in the presence of a new set of obstacles.

With the current row being 0 and the destination row being 3, the next row position is free of obstacles. The state machine incremented the row to 1 and moved to location (5,1). Since the destination row, 3 is still more than the current row of 1, and the next row position did not have an obstacle, the state machine incremented to row 2 and moved to location (5,2). Since the destination row, 3 is still more than the current row of 2, and the next row position did not have an obstacle, the state machine incremented to row 2 and moved to location (5, 3).  Thus, the state machine successfully moved to the destination location in the presence of a new set of obstacles.

In the next blog, I will explain the further testing of my algorithm, which will involve more complex obstacle configurations and performance evaluations.