Closed WesterhofRoy closed 1 month ago
The timeout is set as it is because we cannot control Bluetooth stack delays across processors, OSes, and frameworks. A Raspberry Pi Zero W using BlueZ will have a very different latency than a Macbook Pro M1 on Chrome. Nearly all of the commands the robot uses have a response packet; the timeout is used in order to ensure the response packet is received before the next command is sent. If the timeout passes, we assume that we missed the response packet, and send the subsequent command. If there were zero delays in the Bluetooth stack, and no messages were ever missed, the timeout would never be hit. In particular, if you are concerned about position accuracy, it makes sense to wait until the robot confirms it has achieved a position command. That said, if you are happy with how the robot moves with a lower timeout, you are free to change it on your system. Given that you are remarking about "weird behavior" on low timeouts, you are running into situations where the robot is receiving commands faster than it can react to them. We have no plans to change the default timeout. I hope this helps; if not please reopen the ticket.
Why is the default timeout for the irobot (robot.py file) set to 3 seconds?
This makes drawing quite slow...
We suspect this timeout is to remain accuracy of the position of the robot (rollout) We tested some different values and for us, a value of +- 1 second provides a good balance between speed and accuracy.
Values below 1 second can sometimes cause weird behaviour.