Thanks for the report. So there is a log file that has a lot of “stuff” in it. That does include the list of commands sent to the ROV, but not timestamps.
If however, you turn on the data logging,
r key, then it will record the data with timestamps to a file that can be exported.
When you say you are using the latest software, is that 30.0.2 that was released last month?
All of the recent firmware has a deadman switch that automatically disables the motors if connectivity to the browser gets lost for more than 3 seconds, which limits the cases where the motors could keep pushing forward.
There are only three ways I can conceive that the motors would keep going if you tried to stop.
The command never got sent to the ROV. If the browser window is not the “focused” window on the computer, it goes not capture the keyboard or gamepad inputs. There are also some combinations of browser and o/s where the you have to fully release a key before pressing another for the system to register the keyboard input. This can be seen by checking the telemetry from the “cmd” line. It shows the last command received by the Arduino. If you see a thro(0) then you know the stop command was received by the Arduino. It can be hard to see this because the telemetry is only updating once a second and other commands like ping(0) can happen between the throttle command and when the telemetry updates.
The Arduino died. That would prevent it from sending the stop command to the motors. This could happen if batteries are low. The command comes in, the motors start which draw down the voltage with weak batteries, that causes the Arduino to shutdown. At some point, possibly the reduced resistance of pulling the motors in to the air, causes the voltage to come up high enough that the Arduino kicks back in and resets the motors. This is easier to check because the runtime on the cockpit will freeze and then reset to zero.
The commands that are being sent to the ROV are getting queued up somewhere. We have seen some weird cases where the commands do get queued. I think this is an issue that is limited to the 30.0.2 release and co-insides with a situation where the ROV will seem responsive, you still get latency graph for the connection, the the connection lights turns red and telemetry stops updating.
Hope this helps give some things to look for if it happens again.