Week 8: Initial Results of Path Finding Algorithm in Verilog

Welcome back, everyone! Last week, I explored the detailed architecture and implementation of the pathfinding algorithm in Verilog. I also wrote RTL and a testbench in Verilog and ran simulations.

While testing the design, I realized that sending the results (row #, column # coordinates of the nodes visited by the robot along with cost) all placed in a one-dimensional array requires a lot of processing in the test bench to get meaningful results for each node visited. I had to read the first two numbers and assign them to the row# and column#, respectively, of the node visited by the robot. I had to repeat the process until I get all the information on the nodes visited. So, instead, I modified the RTL port definition to include providing the x (column #) and y (row #) of each node visited separately with the valid signal. By doing so, my interface and its processing within the test bench became relatively simple.

Initially, in my first test case, I provided the grid map the x, y (column #, row #) coordinates of the obstacles as (1,2), (2,2), (1,3), (2,3) and the starting location as (0,1) and destination location as (5,3). According to my algorithm, the destination column # 5 was more than the starting column # 0. So, the state machine moved to a related state and incremented column # to 1 with the new coordinates of the node visited by the robot, such as (1,1). Then the state machine looked at the current starting coordinates (1,1) to the destination coordinates (5,3). Since the destination column # is still more than the current starting column #, the state machine remained in the same state and incremented the column # to 2 with new coordinates to (2,1). Since the destination column # is still more than the current starting column #, the state machine remained in the same state and incremented the column # to 3 with new coordinates as (3,1). Since the destination column# is still more than the current starting column #, the state machine remained in the same state and incremented the column # to 4 with new coordinates as (4,1). Since the destination column # is still more than the current starting column #, the state machine remained in the same state and incremented the column # to 5 with the new coordinates as (5,1). The destination column # became the same as the current starting column #. The state machine moved to a state where it would move in the y direction by changing the row #.

According to my algorithm, the destination row # 3 was more than starting row # 1. So, the state machine moved to the related state and incremented row# to 2 with new coordinates of the node visited by the robot as (5,2). Then, the state machine looked at the current starting coordinates (5,2) to the destination coordinates of (5,3). Since the destination row # is still more than the current starting row #, the state machine remained in the same state and incremented the row # to 3 with new coordinates to (5,3). Now the destination coordinates (5,3) are exactly the same as the new coordinates visited by the state machine/robot; the state machine exits to the original 0. It helped prove that my algorithm worked in my first test case.

So, I wanted to test the pathfinding algorithm further and came up with the following test case that changed the obstacle coordinates by adding two more nodes with obstacles: (3,1) and (4,1). So the test case was with all the following coordinates (column #, row #) as (1,2), (2,2), (1,3), (2,3), (3,1), (4,1).

During the simulation, I discovered that according to my algorithm, the destination column # 5 was more than starting column # 0. So, the state machine moved to a related state and incremented column # 1 with new coordinates of the node visited by the robot, such as (1,1). Then the state machine looked at the current starting coordinates (1,1) to the destination coordinates (5,3). Since the destination column # is still more than the current starting column #, the state machine remained in the same state and incremented the column # to 2 with new coordinates to (2,1). Since the destination column # is still more than the current starting column # but the following incremented column location (3,1) had obstacles, the state machine could not increment the column #. Instead, it went to the state where row # will be changed. Since the destination row # 3 is more than the current row # 1, the state machine wanted to go to a state where it would increment row # to 2 with new coordinates as (2,2), but there was an obstacle in that location. Thus, the state machine/robot was stalled without action. There, I found a mistake in my pathfinding algorithm.

Combe back next week to find out how I fixed this bug in the algorithm and re-simulated the design.