Support for time-synchronized manual control?

[brettle]

Right now, DeepBlueSim can either be used for time-synchronized automated testing (via WebotsSimulator) or for non-synchronized manual control.

In the time-synchronized case, the robot's time and simulator's time are kept in sync with each other (to within maxJitterSecs, which defaults to 0). Depending on the simulator and robot's time steps and the speed of the user's machine, this can result in the tests running slower than real time. At the moment, on my laptop with the default time steps of 32ms for the simulator and 20ms for the robot code (and maxJitterSecs of 0), the simulation runs slower than real time. Allowing for some jitter would arguably be more realistic (albeit less deterministic) and would improve that, but I haven't looked into how much. For automated testing, the slow down isn't critical.

In the non-synchronized case, the robot's time and the simulator's time drift apart and robot control loops see potentially significant latency as actuation/sensor signals are sent between the robot code and the simulator. The lack of synchronization makes it more likely that the simulation will (at least appear to) run in real time, but the simulation is less accurate. For some use cases the real time simulation speed might not be worth sacrificing the simulation accuracy.

So, should we support time-synchronized manual control, and if so, what should that look like from the developer's perspective and the operator's perspective?

[CoolSpy3]

My guess is that on a computer that can run both the simulation and the robot code at near-real-time speeds, any desynchronization in the two would be analogous to lag in the real world (albeit probably more severe than on most real-world systems). Furthermore, running time synchronization could make the simulation feel more laggy than without it. That being said, there are certainly cases where being able to enable time synchronization outside of tests would be beneficial. (The one that comes to mind is auto paths.) Because of this, I think that time-synchronized manual control is something that we should look into.

At the moment, time synchronization can be enabled in a normal robot project by replacing the main method with new WebotsSimulator("<world>", Robot::new).atSec(0, s -> {}).run(); (untested). However, I agree that this is not the best solution. It requires specifying a world file (which, imo, doesn't make sense outside of tests), and It's a fairly unintuitive way to enable time synchronization.

In order to address this, I propose splitting WebotsSimulator into two classes. WebotsSimulator can provide a general interface to DBS (robot & world agnostic), exposing methods to set/reload the world, do time synchronization, request a HALSim connection, etc. The test functionality (synchronizing an entire robot class, callbacks, etc.) can then be moved to a new class.

(Side note, the test class should get either a method to either explicitly enable or manually disable the callbacks to remove the unintuitive use of atSec in cases such as the above, where the user wishes to manually control the enabled state without adding additional callbacks.)

As an initial implementation of manual time sync, I think that we could enable the existing time synchronization code with a function in WebotsSimulator. We could then instruct the user to place this call in the beginning of robotInit() to enable synchronization. I agree that, by default, some jitter should probably be allowed (amount TBD), but the test class and user code can overwrite this if desired.

I think that another thing we could consider would be adding the ability to enable and disable time synchronization from user code (something like setTimeSyncEnabled(boolean) or enableTimeSynchronization()/disableTimeSynchronization()). This would allow users to do something like posting a toggle to SmartDashboard. However, this would require some additional logic to enable/disable the relevant callbacks and deal with offsets occurring because the robot and sim start at different times.