[bobiko]

Hi @Hugo,

It’s been a while since I returned to this problem, but here is what I found. The bug arises from the fact that Utils::getSofaPathTo(const std::string& pathFromBuildDir) returns the path to the current dir if a file does not exist (including the situations when computeSofaPathPrefix() returns the current path):

const std::string Utils::getSofaPathTo(const std::string& pathFromBuildDir)
{
    std::string path = Utils::getSofaPathPrefix() + "/" + pathFromBuildDir;
    if(FileSystem::exists(path))
    {
        return path;
    }
    else
    {
        return Utils::getSofaPathPrefix();
    }
}

What happens then in the readBasicIniFile is that it receives the path to the current dir as the input, calls iniFile.good(), which returns success, and then tries to read from it (the directory, not a file), which is where an exception arises:

std::map<std::string, std::string> Utils::readBasicIniFile(const std::string& path)
{
    std::map<std::string, std::string> map;
    std::ifstream iniFile(path.c_str());
    if (!iniFile.good())
    {
        msg_error("Utils::readBasicIniFile()") << "Error while trying to read file (" << path << ")";
    }

    std::string line;
    while (std::getline(iniFile, line))
    {
        size_t equalPos = line.find_first_of('=');
        if (equalPos != std::string::npos)
        {
            const std::string key = line.substr(0, equalPos);
            const std::string value = line.substr(equalPos + 1, std::string::npos);
            map[key] = value;
        }
    }

    return map;
}

In my case, path is equal to /home/user/some-project-build-dir/. What I did to solve the problem was commenting out the following lines in Utils::getSofaPathTo():

const std::string Utils::getSofaPathTo(const std::string& pathFromBuildDir)
{
    std::string path = Utils::getSofaPathPrefix() + "/" + pathFromBuildDir;
    // if(FileSystem::exists(path))
    // {
        return path;
    // }
    // else
    // {
        // return Utils::getSofaPathPrefix();
    // }
}

Hope what I wrote makes sense to you 🙂

Best regards,
Vlad

[bobiko]

Hi @Hugo, Hi @Guillaume,

Sorry, I haven’t tried it yet, but I am pretty sure it will do the trick. Thanks a lot!

Best regards,
Vlad

[bobiko]

It seems that these difficulties are caused by initialization of DataRepository:

FileRepository DataRepository( "SOFA_DATA_PATH", 0, {
                                   { Utils::getSofaPathTo("etc/sofa.ini"), {"SHARE_DIR", "EXAMPLES_DIR"} }
                               });

When I change it to:

FileRepository DataRepository( "SOFA_DATA_PATH", ".");

Everything works without segfaults. It seems that the problem is related to the zero in char* argument, but I am not entirely sure to what it should be changed.

[bobiko]

Whoohoo, I found the answer!The problem was in locales indeed, mine was set to de_BE.UTF-8, and somehow it worked with runSofa, but not in a custom project. When I changed it to en_US.UTF-8, it didn’t work at all. What fixed the problem though was that the device should have been setup with locales to en_US.UTF-8 and run later with this LC_NUMERIC and LANG set to en_US.UTF-8.

[bobiko]

Appearently the problem is coming from locales, as written here. I get similar behavior when changing locales and running a sample scene with runSofa. The only question now is why does this happen to a cpp project, when it uses system env vars and should be no difference.

[bobiko]

Ok, so I have added Geomagic driver sources to the code, and apparently hdhdGetDoublev(HD_CURRENT_TRANSFORM, driver->m_omniData.transform) and hdGetDoublev(HD_CURRENT_JOINT_ANGLES,driver->m_omniData.angle1) always return false values. Still need to figure out why.

Vlad

[bobiko]

I do not explicitly call calibration in the code, should I? I don’t seem to find a function for that in GeomagicDriver. Joint angles values are like that before and during the simulation. For what it’s worth, calling updatePosition() in main after initialization causes the program to crash.

[bobiko]

Hi @hugo,

The calibration seems to be fine, as the wrist angles are updated. However, the joint angles are stuck at the initial values {0 0 1.5708}. The last one corresponds to pi/2, so I guess that the actual value that is read is 0, too.

Best regards,
Vlad

[bobiko]

Hi guys,

Thank you for the tip, it worked for me!

Regards,
Vlad

[bobiko]

Hi @hugo,

Yes, I found out that MeshDiscreteIntersection, just like MeshMinProximityIntersection, are essentially parts of DiscreteIntersection and MinProximityIntersection, respectively. So I went with MinProximityIntersection. Nonetheless, capsule collision model didn’t work quiet well for me, so instead I am using line and point collision models with proximity offsets, which makes it work as a cylinder.

Regards,
Vlad

[bobiko]

Hi @hugo,

Great, thank you for the information, I will get back to that soon!

Best regards,
Vlad

P.S. Sorry, I cannot close the thread as it is not mine.

[bobiko]

Hi, @hugo!

Thank you for clarification, at least, now the behavior is known to me. I just have to think it through now.

Grtz,
Vlad

[bobiko]

Hi @hugo,

Sorry for the late response. As I said, it did work for me, thanks again. I have created a pull request, let’s see what others think about it.

Grtz,
Vlad

[bobiko]

Hi @hugo,

The example I am referring to (keyboardControl.scn) uses FreeMotionAnimationLoop. I found out that it is possible read forces if I change LCPConstraintSolver with GenericConstraintSolver (even though externalForce is empty anyway), but using LCPConstraintSolver force vector is just filled with zeros.

Regards,
Vlad

[bobiko]

Hi @hugo

Thanks for the info, looking forward to hearing from you!

Regards,
Vlad

[bobiko]

Hello, @hugo!

2. If no constraint correction can be used with CUDA do I understand it right that CUDA plugin cannot be used with FreeMotionAnimationLoop?

Regards,
Vlad

[bobiko]

Hi, @faichele!

I totally missed the last line of your answer. If you could share the changes you did that would help me a lot 🙂 Thanks!

Regards,
Vlad

[bobiko]

Hello, @faichele!

Thank you very much for the tip! Is it sort of an expected behavior? If not, do you think it’s worth to open an issue on github?

Regards,
Vlad

[bobiko]

Thanks, it did help! Sorry, I totally missed the part about RigidToQuatEngine in the scene before.

[bobiko]

Hi @Hugo,
I tried the patch you sent and, unfortunately, it didn’t work for me. I used the following line to attach the direction of the SpotLight to my instrument:

<SpotLight name="LightSource" color="1 1 1" direction="@Instrument/Instrument/Camera/CameraState.position" position="@Instrument/Instrument/Camera/CameraState.position" cutoff="10" exponent="1" fixed="1" />

However, the light still always points the same direction (down). Here is a link to a short demo: https://we.tl/t-SDWR2ppz3q

P.S. Sorry if I don’t fully understand the concepts of SOFA, I am still a newbie, but aren’t direction vector and Euler angles different things? For instance, if I want SpotLight to point up, I set its direction as (0, 1, 0). Contrarily, if I set Euler angles to (0, 1, 0) for some arbitrary object, it would mean 1 degree rotation of that object around Y axis.

[bobiko]

Hi @Hugo,

Thanks for the patch, but as I said, SpotLight direction is defined as a directional vector (for example, the default value (0, 0, -1) points downwards). So I am afraid this patch is not applicable in this case.
I was thinking of adding a <Rigid> property to SpotLight class in C++, similar to cameraRigid in OglViewport, thus we can directly attach SpotLight to a rigid object in both position and direction. Do you think it would make sense?

Regards,
Vlad

[bobiko]

Thanks very much for the tip! It did work, but only partially, as the light’s position is now attached to the object; however, direction does not change with a change of the instrument’s orientation. As far as I understand, there is no simple way of binding the orientation of the instrument and the direction of light, as the direction is given as a directional vector and not as Euler angles. Or am I missing something?

[bobiko]

Hi @Hugo!

Thank you for your response! I do realize that ViewPort and SpotLight are not realted, it was rather a poor example, pardon me for making it confusing.

My goal is to attach a SpotLight and a ViewPort to the distal part of the instrument in order to mimic behavior of a real endoscope. I managed to attach a ViewPort to the instrument by creating a MechanicalObject and linking it to the instrument with RigidRigid mapping (as I want to attach the ViewPort to the distal part of the instrument, not to its center). To be clear, here is my scene:

<Node name="root" dt="0.005" >
  <RequiredPlugin name="SofaOpenglVisual" />
  <RequiredPlugin pluginName="CImgPlugin" />
  <RequiredPlugin name="SofaPython" />
  <VisualStyle displayFlags="hideBehaviorModels hideCollisionModels hideMapping hideForceFields" />
  <LightManager />
  <SpotLight name="LightSource" color="1 1 1" position="0 4 0" direction="0 -1 0" cutoff="10" exponent="1" fixed="1" />
  <Gravity name="G" gravity="0 -9.81 0" />
  <CollisionPipeline name="pipeline" depth="6" verbose="0" />
  <BruteForceDetection name="detection" />
  <CollisionResponse name="response" response="FrictionContact" />
  <LocalMinDistance name="proximity" alarmDistance="0.04" contactDistance="0.02" angleCone="0.0" />
  <FreeMotionAnimationLoop/>
  <LCPConstraintSolver tolerance="1e-5" maxIt="1000" />
  <include name="Uterus" href="uterus_fem.xml" />
  <include name="Instrument" href="instrument.xml" position="0 -2 0 0 0 0 1.0"/>
  <OglViewport screenPosition="0 0" screenSize="300 300" zNear="0.01" zFar="10" cameraRigid="@Instrument/Instrument/Camera/CameraState.position" drawCamera="1" />
</Node>

And here I define the CameraState MechanicalObject in :

...
<Node name="Instrument" >
    <EulerImplicitSolver name="ODE solver" rayleighStiffness="0.05" rayleighMass="1.0" />
    <CGLinearSolver name="linear solver" iterations="50" tolerance="1e-10" threshold="10e-10" /> 
    <MechanicalObject name="instrumentState" template="Rigid3d" position="0 0 0 0 0 0 1.0" />
    <UniformMass name="mass" totalMass="0.1" />
    <UncoupledConstraintCorrection/>
    <Node name="VisualModel" >
      <MeshObjLoader name="VisualLoader" filename="mesh/hysteroscope.obj" />
      <OglModel name="InstrumentVisualModel" src="@VisualLoader" />
      <RigidMapping name="MM->VM mapping" input="@instrumentState" output="@InstrumentVisualModel" />
    </Node>
    <Node name="CollisionModel" >
      <MeshObjLoader filename="mesh/hysteroscope_for_collision.obj"  name="loader"/>
      <Mesh src="@loader" name="InstrumentCollisionModel" />
      <MechanicalObject src="@loader" name="instrumentCollisionState" />
      <LineCollisionModel name="instrument" contactStiffness="10" />
      <PointCollisionModel name="instrument" contactStiffness="10" />
      <TriangleCollisionModel name="instrument" contactStiffness="10" />
      <RigidMapping name="MM->CM mapping" input="@instrumentState" output="@instrumentCollisionState" />
    </Node>
    <VectorSpringForceField  object1="@Input/RefModel/instrumentCollisionState" object2="@Instrument/CollisionModel/instrumentCollisionState" stiffness="10" viscosity="0" />
    <Node name="Camera" >
      <MechanicalObject template="Rigid3d" name="CameraState" rx="90"/>
      <RigidRigidMapping />
    </Node>
  </Node>
...

Now, the only thing that’s left is to attach a SpotLigth to the same position and make it move with the instrument. Thus, my question is, is it possible to do something similar to the SpotLight? I mean, can I somehow attach it to a MechanicalObject?

[Author]

Posts