Resolves #156. It seems that the bug can be tracked down to commit #8213292. A removal of a sleep(40000) inside the send_gamepad_state function of net_handler_cli was what caused the issue. Inside the test case, we send a gamepad state where button A is pressed and immediately follow with sending another gamepad state with button A unsent. I believe what may have happened was that perhaps it probably wasn't done processing the first gamepad_state received allowing for the virtual device to update its timestamp before the second gamepad state was received, or it received them out of order, which could explain why the test worked successfully like 1/20 times that I ran the test yesterday. I'm honestly not too sure if a bug like this can happen with real robots and gamepads/keyboards since this seemed more like a client issue. Either way this was an easy fix
Added sleep after sending updated gamepad state in tc_71_10.c
Added a function to test framework to allow us to check the latency of a provided start time and a parameter of a device
Resolves #156. It seems that the bug can be tracked down to commit #8213292. A removal of a
sleep(40000)inside thesend_gamepad_statefunction ofnet_handler_cliwas what caused the issue. Inside the test case, we send a gamepad state where button A is pressed and immediately follow with sending another gamepad state with button A unsent. I believe what may have happened was that perhaps it probably wasn't done processing the first gamepad_state received allowing for the virtual device to update its timestamp before the second gamepad state was received, or it received them out of order, which could explain why the test worked successfully like 1/20 times that I ran the test yesterday. I'm honestly not too sure if a bug like this can happen with real robots and gamepads/keyboards since this seemed more like a client issue. Either way this was an easy fixtc_71_10.c