neachdainn / rubullet Goto Github PK

PyBullet has a function call to get the API version so that users can check to see that their server/client is compatible. We should also implement this function in addition to having a table in the README specifying the Bullet version.

Hello,

Sorry this problem may seem trivial to you. I came from control's background and works extensively with pybullet. Today I heard from one of my colleagues regarding this repo. I wonder if you may briefly elaborate the main advantage of rustbullet over pybullet? I think a lot of robotists would also be curious so this question may help them as well.

Many thanks in advance.

Maybe there are people out there who want to distinguish between different kinds of errors. For example a call to load_urdf could fail because the path is incorrect or the urdf is not well formatted. Right now we use a generic error with different string messages for that. However, if you want to distinguish between them automatically it is not a good idea to rely on the string content as it could change and it is also very inconvenient to distinguish that way.

An idea to solve this is to create different types of erros in those cases using thiserror.

The structure could look something like this:

RubulletErrors{
    LoadUrdfErrors{
            InvalidPathError
            ParsingError     
     }
    GetBaseVelocityError
...
}

The current build script has (at least) two problems with it that prevent it from building on macOS:

1. It links to stdc++. On recent version of macOS, this file does not exist and is replaced with a different library. We already link to the new library, so it's simply a matter of not linking when macOS is detected.
2. We specifically -D_LINUX in the CMake file. I know that it is sufficient to replace this with -D_DARWIN (on my machine) but I do not know if that is necessary. At the very least, I know what we have is wrong.

It may be important to note that this probably means that the build on Windows has basically no chance of working.

With code similar to below, we get an output that looks suspiciously like something is reading a string that isn't null-terminated. I haven't confirmed this yet but there appears to be no check on the joint index and the link names quickly turn into long series of what seems to be garbage.

for i in 0.. {
    let info = client.get_joint_info(body, i);
    println!("{}", info);
}