Added the method wait_for_simulation_step_to_end() to fix #50

[juanjqo]

@dqrobotics/developers

Hi @mmmarinho,

This PR adds the method wait_for_simulation_step_to_end() to fix #50

• Added example in dqrobotics/python-examples.

Best regards,

Juancho

About the test:

The synchronous mode is tested, comparing the height of a dynamic object in free fall with the expected height after 0.25 s in the simulation time. The expected height is computed as y(t) = y_0 + 0.5 * g * t^2, where g=-9.81, t= elapsed simulation time. To ensure the synchrony (in the synchronous mode), the method wait_for_simulation_step_to_end() is paramount.

        for i in range(0, 6):
            print(i)
            t = i * time_simulation_step
            y_sim = vi.get_object_pose("/Sphere").translation().vec3()[2]
            y_est = y_0 - 0.5 * 9.81 * pow(t, 2)
            vi.trigger_next_simulation_step()
            vi.wait_for_simulation_step_to_end()

Results (synchronized)

Elapsed time:  0.25
Estimated height:  0.6934374999999999 Measured height:  0.6873062252998352

Results without wait_for_simulation_step_to_end()

        for i in range(0, 6):
            print(i)
            t = i * time_simulation_step
            y_sim = vi.get_object_pose("/Sphere").translation().vec3()[2]
            y_est = y_0 - 0.5 * 9.81 * pow(t, 2)
            vi.trigger_next_simulation_step()
            #vi.wait_for_simulation_step_to_end()

(Not synchronized)

Elapsed time:  0.25
Estimated height:  0.6934374999999999 Measured height:  0.798895001411438

Note:

During my local tests, the synchronous mode worked for only some setups. This means that in some cases, the method wait_for_simulation_step_to_end(), which calls the blocking function simxGetPingTime() of the Legacy Remote API didn't ensure the synchrony between the simulation and the script.

OS	DQ Robotics/Matlab	DQ Robotics/Python	DQ Robotics/C++
Ubuntu	✅	✅	✅
Windows	✅	❌	Untested
VM Ubuntu on Windows	Untested	❌	❌
MacOS	Untested	Untested	Untested

[mmmarinho]

@juanjqo

The compatibility table is very informative. It might be good to explore, in some future opportunity, how to make it reliable in those systems. However, I suppose that would take a considerable amount of effort and might entail updating the embedded "legacy" remote API or even re-writing the interface to use whatever is the currently new shiny remote API for CoppeliaSim.

Either way, the intended support is for Ubuntu LTS only, so no harm, no foul.

[juanjqo]

@mmmarinho thanks for your comments. It looks like Coppelia recommends only the zmqRemoteAPI and insists in not using the Legacy Remote API anymore according to the oficial forum[1][2][3]. However,
the C++ client of the zmqRemote API requires Boost 😔.

[mmmarinho]

@juanjqo As long as the benefits justify the effort, it is something to discuss and consider... In particular as a new interface package.

I, myself, can't commit to supporting Windows and macOS (intel/arm64) as it opens up too many avenues for trouble. As long as the CoppeliaSim interface works as intended on Ubuntu, I think that we can keep this staring contest with CoppeliaSim for a while until things break for Ubuntu.