URDF importing correctly on one machine, incorrectly on another. Same code.

[DanSJohnson]

Hi everyone,

I'm having a strange bug where my code works fine on one machine (Machine A), but on another (Machine B) Bullet fails to load the URDF file correctly. However, when the URDF file is loaded incorrectly it doesn't return a negative ID or throw any errors, it just responds to subsequent calls involving the file incorrectly.

The following is a minimal example that recreates the problem on my two machines:

#include <b3RobotSimulatorClientAPI_NoGUI.h>
#include <btBulletDynamicsCommon.h>
#include <iostream>

using namespace std;

int minimal_recreation(){ 

    b3RobotSimulatorClientAPI_NoGUI* sim = new b3RobotSimulatorClientAPI_NoGUI();

    bool isConnected = sim->connect(eCONNECT_SHARED_MEMORY);
    if (!isConnected)
    {
        cout<<"Using direct mode"<<endl;
        isConnected = sim->connect(eCONNECT_DIRECT);
    }
    else
    {
        cout<<"Using shared memory"<<endl;
    }

    sim->resetSimulation();
    sim->setGravity(btVector3(0, 0, -9.8));
    sim->setNumSolverIterations(100);
    b3RobotSimulatorSetPhysicsEngineParameters args;
    sim->getPhysicsEngineParameters(args);

    const char* corin_path="basics/models/Drake_Corin.urdf";

    int CorinId = sim->loadURDF(corin_path);
    cout<<"loading corin with ID "<<CorinId<<" and path "<<corin_path<<endl;
    int numJoints=sim->getNumJoints(CorinId);
    cout<<"    corin has "<<numJoints<<" joints"<<endl;

    return 0;
}

On both machines this code compiles and runs without errors. On Machine A this prints:

Using direct mode
loading corin with ID 0 and path basics/models/Drake_Corin.urdf
    corin has 24 joints

which is correct. Machine B prints:

Using direct mode
loading corin with ID 0 and path basics/models/Drake_Corin.urdf
    corin has 0 joints

which is incorrect.

Can anyone advise on why this might be? The URDF file is identical and both machines are running this release of bullet.
The only difference I can think of is that Machine A is running Ubuntu 18.04, but Machine B is running Ubuntu 20.04. Though I'm unsure why that would cause this problem.

If anyone has any advice on what I could try to solve this problem or to learn more i'd be very thankful!

[DanSJohnson]

As an update, i wanted to check if it was something to do with my URDF file, so I tried it with the humanoid.urdf file from the data directory (which I moved to basics/models for consistency) . On machine A i got:

Using direct mode
loading robot with ID 0 and path basics/models/humanoid.urdf
    robot has 33 joints

Whereas on machine B i got:

Using direct mode
loading robot with ID 0 and path basics/models/humanoid.urdf
    robot has 0 joints

Which implies to me that this issue isnt being caused by my URDF file

[DanSJohnson]

As a further test, if I use the Python library urdfpy to load the same file it works fine and correctly identifies the links on both machines. I use this code:

from urdfpy import URDF

robot=URDF.load('basics/models/Drake_Corin.urdf')
for joint in robot.joints:
    print(joint.name)
robot.show()

And it correctly prints out the names of the 24 joints and then correctly visualises the robot on both machine A and machine B.

[DanSJohnson]

Ok so, after a lot of tinkering I have now fixed this problem on my end. Posting here in case anyone else experiences this.

Basically, I was having strange behaviours on machine B with a number of bullet functions. In this example the problems were caused by sim->getPhysicsEngineParameters(args);, but I also observed some problems elsewhere in my codebase relating to sim->getDyanmicsInfo. These were caused by the install being a bit bugged. I'm not sure why, but none of the official install options work for me.

• vcpkg does not contain the robotics functions I was interested in
• premake failed to build for reasons I don't entirely understand
• executing ./build_cmake_pybullet_double.sh appeared to work (this is what I did on machine B) but then produced undefined behaviour for several functions.

In the end what worked for me was building bullet the good old fashioned way:

mkdir build
cd build
cmake .. -DBUILD_SHARED_LIBS=ON
make

After doing this, the behaviour of Machine B lined up with what I expected, though I have no idea why. So anyone else having this issue, maybe try that?