[olivier]

Hey Pasquale,
I don’t get how you can apply the pressure using the CGlinearSolver, because the constraint on pressure cannot be applied.

If your scene does not work with SparseLDL, it means there is a problem somewhere. Looking at your modelSubTopo Node, I think something is strange there. You have an identityMapping between your subtopology Node to the main node (why? I guess it would rather be a subsetMapping) and you have a MechanicalObject and a ForceField, hence mapped through the identityMapping –> This can not work with SparseLDL
To solve that you can:
– Use the component MechanicalMatrixMapper (you can find an example in main SOFA examples)
– Create a subtopology the same way it is done in the scene with the Multigait Soft Robot in the MOR plugin. I would advise this solution which is more simple.

olivier

[olivier]

Hello Pasquale!

Sorry for the delay. First of all, before looking at the MOR plugin, you should make sure your SOFA scene is working the way you want.
Having a quick look, I think that first you could simplify your scene:
it doesn’t look like you want to consider contacts, so just remove all that has do do with that (BruteForceDetection,DefautPipeline, DefaultContactManager, LocalMinDistance).
Also, since you want to use an actuator, you can not use an iterative solver like CG, you HAVE to use a direct solver like SparseLDL (because the system matrix has to be built, it is used to solve the constraints).
Let me know how you get on,
Good luck,
Olivier

[olivier]

Hello @aryakarani,

For your point 1, have a look at the folder sofa/src/examples/Components/misc/
You should see some example of data beeing exported for examples using the component WriteState for position or velocity.
If you want to know which index corresponds to what on a mechanicalObject, got to the visualisation tab when you open the mechanicalObject window, and check the boxes showIndices.

For your point 3, I am not sure I understand, but if you want to change the color of an object, don’t do it on the node but on the component itself.

Good luck!
Olivier

[olivier]

Hello @amackeith !

There are several few things to look at:

– the warning you get [WARNING] [FixedConstraint(FixedConstraint)] Unused Attribute: “indicies” with value: “1 2 3” (/Reduced_test/model_MOR/model/FixedConstraint)
is just a misspelling of “indices” in your file my_quadruped.py. Since the constraint can not understand the points you want to fix, it fixes only index 0 by default.

– Secondly, and it is a bit more tricky and comes down to how SOFA works, the fixconstraint is not taken into account when it is in a sub-node of your higher node containing degrees of freedom, so it can not work in the reduced model anyway. For fixing degrees of freedom in a scene you want to reduce, I advise you to use a spring with high stiffness, i.e. ('RestShapeSpringsForceField' , points = [...], stiffness=1e8).

– Thirdly, if you reduce a model that is fixed in some way, you should set the boolean addRigidBodyModes = [0,0,0] because you are not interested in having your model moving away in space. And actually, it should also allow not to have any constraint to fix your model in its reduced version (you may want to add one for ‘safety’), because the modes will all be fixed at this point anyway.

I hope it is clear, and do not hesitate to contact me.
Good luck!
Olivier

[olivier]

Hi Arthur,

Sorry for the late reply! I am not sure where the problem comes from, but looking at you scene, there is no reason why it should not work, and I think it should only be a minor issue. I will let @felixvanneste reply as he is more skilled in python related issues.
About the python3 compatibility, the answer is yes, it should become compatible very soon.

We keep in touch,
Olivier

[olivier]

Hello @anluong,

Maybe the easiest way to do what you want is to leave the collision detection pipeline as it is. You could use a dummy LineModel to represent your ray and whatever collision model already existing in SOFA to model the material supposed to bend.
However, regarding the response, I understand that you want to change what would be a standard contact behaviour by applying a bending force on your material, that could be done by changing dynamically its rest position. If you look at Friction contact, you have an activateMappers virtual function that you can override by your version to implement your response. For example I guess you would remove the creation of the unilateral constraints. Regarding the addPointB method, I think it has the role to create a mapping to map the contact position to the actual degrees of freedom of the material.

Good luck!
Olivier

[olivier]

Ok perfect! Do not hesitate to come back to us if you run into further issues.

Cheers,
Olivier

[olivier]

I let @felixvanneste reply to you on this one. I think he should be able to give you a good hint, but you might have to go back to Python2

[olivier]

Hello @brunob81hk,

For your second question, actually, the Data constraintForces does give you the value of Lambda (so the intensity of the constraint forces).
So to answer your first question, to output lambda, I think the easiest will be to get it using a PythonScriptController in which you recover the value of that data calling findData(‘constraintForces’) on the object genericConstraintSolver, or just read it from the GUI if you do not need it at each timestep.
(You can find an example of controller in SoftRobots/docs/examples/component/constraint/CableConstraint/CableConstraint.pyscn)

Olivier

[olivier]

Hello @robclark ,
Sorry for the delay, I am back from vacation.

Thank you for your remark. Actually, the problem comes from the scene that has hard-coded values in it (making it unstable to a time step change) :
If you look in the code of the scene, an initial value of 5 for pressure is given. In the first step, the pressure jumps from 0 to that value, which is OK if the jump is not too big and over a large-enough timestep. When you reduce the timestep, this jump has to be integrated over a smaller time which can lead to unstability.

If you want to try, if you reduce the InitialValue to 1 in the textfile of the scene, and then change the timestep to 0.001, the scene is still stable.

Hope this is clear enough, and do not hesistate if you need more explanations,
Olivier

[olivier]

Hey @sherpa and @hugo,

Yes Hugo, you’re absolutely right. To add some info, H will give you the force direction, while lambda will give you the intensity. You can get H from the python code in your SOFA scene by calling the “constraint” field of the MechanicalObject. For lambda, I think you will have to go in the constraint solver (typically GenericConstraintSolver) and print it out at the end of the solveSystem(…) function.

Do not hesitate if you need more details,
Good luck!
Olivier

[olivier]

Hello,

Yes it looks like there is a problem at phase 3 actually, when the plugin generates the unassembled FEM contributions into the files ending by “_Gie.txt”. According to the output of your terminal, it looks like they are empty:

Reading file : '/home/pasquale/Script_SOFA/pneumatic_fingers/multimaterial_material_finger/MOR-finger/MOR/debug/reducedFF_finger_1_Gie.txt'
nbLines 0  lenght 289

If you look at your folders mentioned in the execution, you can maybe figure out what is going wrong:

[139654015743744] processing threaded sofa task in: /tmp/sofa-launcher-HFAQKe/phase2_prepareECSW.py
[139654007351040] processing threaded sofa task in: /tmp/sofa-launcher-G_UJKN/phase2_prepareECSW.py

[olivier]

Hello Pasquale!

Sorry for the delay to reply! So you said you managed to solve your problem? It looked like it was coming from the hyperReduction phase, where your reduced integration domain seemed empty which leads to a crash. Do not hesitate to contact us again in case of future issues!

Best Regards,
Olivier

[olivier]

Hello Mr Wong,

Sorry for the delay I’m just coming back from vacation.
Thank you for your message! The meshes that should go with the scene were missing.
I have just fixed the problem and hopefully it should work fine now.

Olivier

[olivier]

Hi @outtt,

What kind of accuracy are you looking for? It depends if your are looking for an accurate description locally in a small neighbourhood around the instrument, or only the global deformation of the brain.
In the first case, indeed it will be challenging to perform a reduction that catches the local deformations while still running at a high frame rate. However, if it is the global deformation of the two parts of the brain touched by the instrument that interest you, I think it should be possible to generate a good reduced model.

Maybe consider implementing your own shaking, “shakingSofia” moves the actuator in a circle which may not be the most realistic way to stimulate your brain.

Olivier

[olivier]

Hi @outtt,

Feel free to write your own shaking. Have a look at the file “shakingAnimations.py” in the folder python/mor/animation of the plugin. This where the shaking you are using is defined, and you can modify it. It is calling the function “rotationPoint” and I think that is the one you want to update.

Olivier

[olivier]

Hello @outtt,

– For the reduced model to be giving reasonable results, the snapshot generation phase is very important, because it what the reduced model will be based upon. You can run the debug scene in the debug folder: runSofa debug_scene.py and runSofa debug_scene --argv step2_stateFile.state to check what shaking was actually made in snapshot generation phase and the reduced Snapshot phase respectively. What kind of shaking did you use? I had a look and I think your shaking is not exhaustive enough for the reduced model to be really accurate. Consider adding mode actuators at various location on your brain.
– For the windows crash, thank you for the update, we will check if we can solve that issue.

Olivier

[olivier]

Hello @outtt,

Just so you know, I have just made a few changes that could hopefully resolve some of your bugs, if you want to try.

Let me know how you get on,
Olivier

[olivier]

Hello @outtt,
OK, there is one zero missing, reducedFF_liver_2_weight.txt should actually contain:
11 1
1
0
0
0
0
0
0
0
0
0
0

Hope this works!

[olivier]

Hi @outtt,

Several reasons why this does not work completely:
– 1) the actuator node has to be a child of the “attachedTo” node to be aside the reduced model, and the link for the position of the actuator needs to updated. This how it should look like:

    actuator = attachedTo.createChild('actuator')
    actuator.createObject('MechanicalObject', name = 'actuatorState', position = '@'+boxROIactuation.getPathName()+'.pointsInROI', template = 'Vec3d')

together with creating a pointer to the boxROI:

boxROIactuation = liver.createObject('BoxROI' , name= 'boxROIactuation' , orientedBox= newBox([[-5.0, 0.5, -0.5], [-5.0, 0.0, -0.5], [-4.0, 0.0, -0.5]] , [0.0, 0.0, 0.0],translation,rotation,[0, 0, 0.5],scale) + multiply(scale[2],[1.0]).tolist(),drawBoxes=True)

Here we used the function getPathName() which is quite useful to make links.

– 2) Indeed there is a little bug with the way the RestShapeSpringForceField is created. It will be corrected next week. In the meantime you can solve it by hand by going to the “data” folder (inside the folder where your reduction is), and editing the 3 files: reducedFF_liver_2_listActiveNodes.txt, reducedFF_liver_2_RID.txt and reducedFF_liver_2_weight.txt .
reducedFF_liver_2_listActiveNodes.txt should contain just:
0
reducedFF_liver_2_RID.txt should contain just:
1 1
0
reducedFF_liver_2_weight.txt should contain just:
11 1
1
0
0
0
0
0
0
0
0
0

Hopefully this should work!
Olivier

[olivier]

Hello @outtt,

Yes that is normal because the reduced scene does not include the node “actuator”, with the mechanical object “actuatorState” by default (you removed the “external_rest_shape” link in “HyperReducedRestShapeSpringsForceField” ?). If you want to keep it in the reduced scene you also need to add it:

    actuator = rootNode.createChild('actuator')
    actuator.createObject('MechanicalObject', name = 'actuatorState', position = '@'+boxActuation.getPathName()+".pointsInROI", template = 'Vec3d')

Olivier

[olivier]

Hello @outtt,
I am coming back to you. I modified your scene slightly and it is working now. Check the scene following the link: https://pastebin.com/fRQmKFma

The reduced scene generated will not contain what you added in your rootnode (FreeMotionAnimationLoop, GenericConstraintSolver), but can just edit the reduced scene generated and add it.
Please try it and see if it works on your computer.

Best Regards,
Olivier

[olivier]

Hello Wong @outtt,

First of all, well done if you solved some compile issues and got the plugin to compile for your computer.
About your two questions:
1) Could you give us your modified version of liverFine.pyscn? In principle, there is no reason why this should not function.
2) About using the MOR plugin in a scene with haptic feedback.
To be honest, we have not tried yet, but it should be working as it stands. An optimised version of the haptic loop when used with an FEM model reduced with the plugin could be implemented in the future however.

Let us know!
Olivier

[olivier]

Hello Bassam,

I am currently developing a projection-based Model Order Reduction technique in SOFA (namely snapshot-POD), with an application to soft robotics in mind.
We could have a chat if you want.

Cheers,
Olivier

[Author]

Posts