Carelessness...

Turns out we were just careless. I found the reason for the strange velocity reading almost right away. 

But first a digression. I discovered today that LabVIEW offers functionality to run your FPGA code in simulation! I never realized it but if you right-click on the FPGA target, you can select whether to execute the FPGA VI on the FPGA target or to execute it in simulation. If you select to run the VI in simulation, it's SUPER convenient for debugging! You can probe your data lines anywhere you want and see the value of the data passing through those wires (something you can't do if you're just running your FPGA code on the target) and that really helps with debugging.

Alright. Back to the reason for the strange velocity reading. Pretty quickly, using the debugging technique discussed above, I discovered that we had made a stupid mistake in our type definitions during the velocity calculations. To calculate velocity, we first calculate the elapsed time since the last velocity calculation. We then divide distance traveled since last velocity calculation by this elapsed time to obtain the current velocity. 

While looking through the code, I realized we had stupidly defined the output of the division operation calculating elapsed time in seconds as a signed 32-bit word length, 32-bit integer length fixed point number.  Unfortunately, in calculating the elapsed time, the division operation was dividing 1000 microseconds by 1000000 to calculate the elapsed time as 0.001 seconds. Since the output of the division operation was essentially defined as an integer number, the division operation was returning 0 as its output. As such, when the distance traveled is divided by this zero (elapsed time), the resulting output was a large number. When we later change the type definition for that number to a signed 24 bit word length, 5 bit intgeger length number, the output was then 128. Silly us. Fixing that code immediately fixed the speed output problem.

​Now to fix the steering controller problem...