[BUG] All methods of the experimental class related to the engine parameters settings are not working in CoppeliaSim 4.8.0-rev0

[juanjqo]

---

Code of Conduct

By submitting this report you automatically agree that you've read and accepted the following conditions.

• Support for DQ Robotics is given voluntarily and it's not the developers' role to educate and/or convince anyone of their vision.
• Any possible response and its timeliness will be based on the relevance, accuracy, and politeness of a request and the following discussion.
• If a DQ Robotics member replies, the user must let them know if their response solves their issue or not.
• Any suggestion/advice/request made by anyone, as well intentioned as they might be, might not be incorporated into DQ Robotics.

---

Bug description

Hi @dqrobotics/developers

All methods of the experimental class related to setting the engine parameters are not working in CoppeliaSim 4.8.0-rev0. Such methods were working well in CoppeliaSim 4.7.0. However, in the 4.8.0 version, Coppelia introduced API modifications that broke the current implementation of the DQ_CoppeliaSimInterfaceZMQExperimental() class. Those modifications are listed in the Coppelia's changelog. For instance, the one related to parameter setting is listed as

All internal variables or states can now be handled as properties: those can be queried or modified via [dedicated API functions. Additionally, most properties, when modified, trigger an event that can be listened to. Signals, custom data, engines parameters and named parameters have been integrated into the properties framework

I reported the issue in Coppelia Forums. This is the second time API modifications from Coppelia break the experimental methods in the class DQ_CoppeliaSimInterfaceZMQExperimental(). The first one was related to simulation scripts, which I fixed in juanjqo@1ec0296. This raises concerns about how hard it will be to support some ZMQ-powered functionalities in the DQ Robotics library.

To Reproduce

Minimal example

Code

#include <dqrobotics/interfaces/coppeliasim/DQ_CoppeliaSimInterfaceZMQExperimental.h>

using namespace std;

int main()
{
    auto vi = std::make_shared<DQ_CoppeliaSimInterfaceZMQExperimental>();
    vi->connect();
    try {
        vi->set_mujoco_joint_damping("Revolute_joint", 0.3);
    } catch (const std::runtime_error& e){
        std::cerr << "Caught a runtime error: " << e.what() << std::endl;
    };
    return 0;
}

Output

Caught a runtime error: No such function: sim.setEngineFloatParam

Note for developers from the future:

Modify the internal implementation of the affected methods. For instance,

Current:

void DQ_CoppeliaSimInterfaceZMQExperimental::set_mujoco_joint_damping(const std::string &jointname, const double &damping)
{
    _ZMQWrapper::get_sim()->setEngineFloatParam(_ZMQWrapper::get_sim()->mujoco_joint_damping, _get_handle_from_map(jointname), damping);
}

proposal based on this (untested):

void DQ_CoppeliaSimInterfaceZMQExperimental::set_mujoco_joint_damping(const std::string &jointname, const double &damping)
{
    _ZMQWrapper::get_sim()->setFloatProperty(_get_handle_from_map(jointname), 'mujoco.springDamping', damping);
}

Environment:

• OS: MacOS Sonoma 14.7.1 (M3 PRO)
• dqrobotics-interface-coppeliasim-zmq version commit c71769c
• CoppeliaSim 4.8.0-rev0

[bvadorno]

Hi @juanjqo,

As annoying as it might be, this is a recurring problem in software engineering. That's why we need an API to enable people to use DQ Robotics transparently without concern for those low-level details.

On the other hand, we don't need to support every single version of CoppeliaSim. We should only move to newer versions if it doesn't break our existing code base or if newly introduced functionalities pay off the effort of modifying our APIs.

Kind regards,
Bruno