Forum Replies Created
-
Posts
-
Hello @daserk
this is a good question! As Hugo mentioned, it has to do with implementing constraints, which can be done in C++ using the SOFA and the SoftRobots-plugin codebase. In [1], Sec. 4.2 it is explained how cable actuation and pressure actuation are implemented. In [2], in Sec. IV-C, I myself made an attempt at explaining cable actuation. However, I’m not necessarily a veteran expert. For starters, you should have a look at these resources. You can then ask a followup question and we can try to answer it 😉 I do have to warn you though that doing this is more involved, i.e. probably costly in terms of time. It is possible, but it requires familiarity with the concepts in SOFA at the level of how they are implemented in C++, which would probably imply a learning effort.
In any case, after you study [1,2], I want to pose that maybe your problem is quite similar to how cable actuation is implemented. Therefore, for your first trials, you could actually use this component first to emulate the type of actuation you want. Then, you can see what improvements would be needed and take it from there.
Best
Stefan
[1] https://hal.inria.fr/hal-01649355/document
[2] https://hal.inria.fr/hal-02882039/documentHello @cathyye2000,
a similar question has been asked and answered before. Have a look, maybe it will help you:
Best
Stefan
Hi @essembly,
like you say, there’s many ways to try to do this. The one I can suggest if you don’t have any type of parametric source for your STL is the following:
1) Using FreeCAD, import the STL file.
* Switch to the “Part” Workbench and go to the “Part” menu in the top.
* Select “Create shape from mesh”
* Select the newly created shape and in the same “Part” menu select “Convert to solid”
* Select this newest object in the tree and export it to a .step file.
2) Using Gmsh, import the .step-file
* In Gmsh, navigate to the Mesh menu on the left. Select 3D. It should produce a volumetric mesh. This result you can now export as a VTK
3) You might need to reduce the mesh size in step 1) if it is too complex. In 2) you might need to tinker with the meshing parameters e.g. Tools->Options->Mesh->General->Element Size Factor to arrive at the correct results.Good luck!
Stefan
I don’t have a lot of experience with neither system, but it does sound like moving the discussions to Github would have some benefits!
Good to hear 🙂 Actually, I’ve come to expect that a properly defined geometry exported to STEP will immediately be meshable as volumetric in Gmsh. However, it’s possible, I think, to have STEP files that don’t define volumes. For instance, if you extrude an open contour and it’s not generating a proper solid. Anyways, good luck with the next steps 😉
Edit: If the issue is solved (for now), you can close the topic!
Alright, I think I found a lead.
The problem seems to come from the igs-format. If you look at the geometric entities in Gmsh when loading the .igs-file, there’s more than 12 lines (curves in Gmsh-language) making up the cube. This means that there’s repeated edges in the cube and therefore adjacent faces cannot be made to a volume, because they actually don’t share common edges!
I also tried exporting to .igs from FreeCAD and encountered the same problem. If I export to .step instead, I can immediately create the volumetric mesh, meaning the geometry is well-defined. In fact, the same cube has only 12 lines/edges, which is the correct amount.
Can you try to export to step from you CAD-software and see if it works then?
Best
Hi @anoushs,
can you share your .igs-file?
I think @jonny’s hint might actually work for your case as well. After selecting the boundaries you should be able to press ‘e’ and that should create the volume (not the volumetric mesh). You will know this worked when a yellow sphere at the center of the object appears. This indicates the geometry has a volume.
In any case, I could quickly verify with the geometry file if you share it.
Best
Hi @anoushs,
if I understand correctly from your question, you can successfully import your geometry in Gmsh. There, you are able to generate the surface mesh by clicking on Mesh->Define->2D, however, for Mesh->Define->3D there is no result, right?
One thing that this could indicate is, that your geometry does not specify a volume, only surfaces. Visually, they can look the same, but Gmsh is only able to generate volumetric meshes for volumes. To verify this, you can go to the menu Tools-Visibility. This will show a list of all the geometrical entities present. On the top of the list there should be at least one volume. If not, then the issue is what I just stated and you need to verify that you are correctly constructing the geometry in your CAD-program.
Best
Stefan
Hi @twxu,
you’re welcome!
If the monitor object is causing some issues, I would definitely prioritize having the scene running smoothly. There should be alternatives to obtain the force values through scripting by accessing data fields of the components.
As you say, try adapting the example pneunet scene to your geometries and see where the bottleneck appears. It is normal for the simulation to slow down when contacts are happening. How much, will depend on the complexity of the collisions, but more than a factor of 10 should indicate a problem, I would say. One thing you can do to optimize this, is by making sure only the relevant parts of your object are having a collision mesh. This will save time by avoiding proximity queries for the parts that are not expected to enter in contact anyways. Beyond that, I think @scheikl actually has some practical experience in this and might be able to help out.
Best
Stefan
Hi @twxu,
I looked at the meshes and they seem to be ok. I can load them with gmsh and as you say, the number of elements is reasonable, so from that side there should not be an issue.
To me, that leaves three candidates as a cause for your problem: the monitor object, the scripting and the collision pipeline. Have you tried to disable each one of them? I guess you started modeling your pneunet by modifying the existing example scene? Could that be a way to debug this issue? Concretely, I mean:
1) Take original pneunet scene and replace the geometries only (stls and vtk)
2) Add the elements you want (monitor object, collision pipeline) and test after each addition.Best
Stefan
unfortunately, I’m not an expert on the solvers, so I can not give a very technical insight. However, it does seem very weird that a simulation would take in the order of hours. Up to a few thousand elements, the simulations should run interactively (5FPS+). As an example, on my computer I run a simulation that has ~2200 points and ~7500 tetrahedra at 8 FPS, without CUDA, etc. Using the SurfacePressureConstraint, which I have often used, shouldn’t affect the performance in this way neither. So, that leaves me wondering about whether you are doing something else in your scene. Here a re a few questions for debugging and feedback:
– Are you using a script (a python controller) that writes to disk or similar?
– How did you generate your geometry?
– Does the caduceus scene run smoothly (the one launched when starting SOFA with no arguments)?
– Does the pneunet or any other example from the SoftRobots plugin run smoothly?If you want, you can post a share link to your geometries and I can have a look to see whether there’s something out of the ordinary happening with them.
Best
Stefan
Hey Lulu,
so, I’m not an expert in the handling of collisions in SOFA, but as far as I can tell, the main idea is to calculate the locations of contact interactions (which is similar to what you want) and then solve for the forces and deformations due to these interactions (not what you want).
I can try to find out if it’s easy to use the functionality available in the Collision Pipeline to calculate the intersection point of a mesh with a ray. In the meantime, you can checkout the component ConstantForceField existing in SOFA. There is an example scene available with the code:
sofa/src/examples/Components/forcefield/ConstantForceField.scn
You can play around with it and see if you can figure out how to use one or more of these components to apply a force like you want, i.e. assuming a known intersection point of the ray of light with the actuator.
Stefan
Hello @anluong,
I’m sorry, your question leaves me somewhat confused ^^
As far as I understand, this light-based actuator works because in some way light induces stress in the material that manifests itself as bending. However, I cannot follow the jump towards the implementation of a Collision Pipeline. Why would the collisions be necessary to model the bending? Or is the collision related to an external object that you want to push?
Could the bending be otherwise modeled by forces that contract/extend the material on one side of the actuator (a flat one, I’m assuming), which leads to bending? In that case you might want to try implementing a ForceField-Component or a Constraint.
Best
Stefan
Hi @jlorenze,
good luck with the installation on Ubuntu 20.04!
I think it’s fair to add the issue of the ROS initialization to the discussion in #17072. It is also possible that the issues might disappear/change when using Ubuntu 20.04 (and ROS2 Foxy), right?
Stefan
Hi @jlorenze,
I think specifying the exact python executable during the configuration with cmake might do the trick. Try setting the PYTHON_EXECUTABLE flag to /usr/bin/python3.8 (for example). It seems to me that the cmake config process will derive the rest of the dependencies from that by subsecuently calling /usr/bin/python3.8-config to find the right libs to link to, etc.
I’m not 100% sure, but it’s worth the try, I think!
Best
Stefan
Hello Cai,
as @epernod points out, there could be an issue with deprecation between SOFA and the SoftRobots plugin, I will keep an eye open. However, if you just want to test SOFA with SoftRobots, you can directly download the binaries:
Then you can run the executable:
../SOFA_v19.06.99_custom_Linux_v5.1/bin/runSofa
to launch some tutorials, for instance:
../SOFA_v19.06.99_custom_Linux_v5.1/plugins/SoftRobots/docs/tutorials/CableGripper/cablegripper-tuto.pyscn
However, this binary release still uses SofaPython with Python2.7. If you need Python3, there’s currently no way around compiling from source for now.
Best
Stefan
Hello @jlorenze,
I’m sorry that you have this issue, which can be a little bit frustrating!
Since STLIB is all SofaPython(2), it is not compatible with SofaPython3, as stated before. However, it is actually _not_ strictly necessary to have STLIB to compile SoftRobots. I think that during Cmake configuration it will give you a strong warning, but not necessarily fail. Otherwise, there is a flag in SoftRobots that is called “SOFTROBOTS_IGNORE_ERRORS”, which you can set and see if that circumvents the problem. In other words, remove the STLIB plugin from the configuration to resolve any errors generated due to its dependency on Python 2 and try again.
Overall, if you manage to compile, you should be able to adapt the simple examples in SoftRobots to work with SofaPython3. Hopefully, from there you can do your own scenes. We are currently making some porting efforts, but are lagging behind.
I hope this helps!
Best
Stefan
Hey @stonkens,
regarding your questions about splib (and STLIB): SPLIB basically has to be ported to python 3. For now SofaPython3’s functionality is mostly related to the bindings and scripting. We are slowly populating SPLIB with the functionality it had before. SPLIB is now a part of SP3 and there could eventually be a separate STLIB for python 3 to complement the SoftRobots plugin.
In any case, I think porting the code from the old STLIB (which includes SPLIB) should not be soo difficult. If you happen to do some porting for SPLIB, you can even create a pull-request!
Cheers
Stefan
@MA, you’re welcome! Although, I admit, it was a little bit of annoying work ^^
For repairing the mesh of the S-Yarn I used Blender. I could clearly see that there was a hole on one of the ends. I selected the corresponding vertices and created new faces. I think Meshlab is also quite powerful with automated functionality to improve mesh quality, etc. Just search online for something like “repair mesh with Blender/Meshlab” and you will have a few cues.
Looking at the fact that your meshes are quite simple, it occurred to me that it might be a good idea to just create them yourself, for instance using Blender or FreeCAD. My workflow would be to create a very basic geometry, like a cube, export it and then create a volumetric mesh. You will see if it works for this basic example. (In fact, to debug your problem with the volumetric meshing I created a simple cube in Blender, for which it worked.) Then, you take it from there to the more advanced shape. If you put some time into it, it should not be a problem for you to create the S-Yarn or the Woven Yarn yourself.
Just as a tip: if you create the mesh in FreeCAD and export it to brep-format, which is a parametric format, you will be able to mesh it perfectly with Gmsh. If you export it to a stl-file it will be easier to use the VolumetricMeshGeneration example.
Best
Stefan
Hi,
so, last week I had a look at the issue. I was able to mesh the S-yarn with CGAL, i.e. with the VolumetricMeshGeneration example:
However, I had to follow two steps:
1) Repair the original file, because the mesh had holes in it. Here is the repaired version:
https://www.dropbox.com/s/g8ocpvx21qot1ib/single_S_yarn3.stl?dl=0 (stl)
https://www.dropbox.com/s/g9n7350ogbl8fb9/S-yarn-volumetric.vtu?dl=0 (vtk)
2) Change the parameters, because the units of the file seem to be in cm:
cellSize="0.1", facetSize="0.1",I also tried to mesh it with Gmsh and had moderate success. It didn’t work by loading the (repaired) stl-file into Gmsh. Therefore, the binding we made in Sofa does not work either. Apparently it is not straightforward to mesh stl files with Gmsh. I had to follow the tutorial/example number 13 on their website:
http://gmsh.info/doc/texinfo/gmsh.html
To achieve good results with Gmsh you will need to look into some parameters, I think.
I know all this is fiddly, but it also was hard to pinpoint the problem, because the original geometries were partially broken (no volume or holes). To be sure the problem is not on the geometry itself, I recommend trying the meshers with geometry that is known to work. If it doesn’t work on your files, it is possible that the geometry you are trying to mesh is actually broken.
Best
Stefan
Hello everyone,
as Damien mentioned, we are working on a functionality to simplify the meshing procedure by scripting Gmsh with python from within Sofa (STLIB). In a few days we will have something (updated) available to the public.
I saw the geometries for the T-Yarn and I’m not sure it will be possible to mesh it. If I understand correctly you have two flat stripes overlapping, forming a T-shape. However, your surface mesh has no volume. Hence, it is impossible to generate a volumetric mesh with CGAL or Gmsh. Can you correct this? Your S-Yarn on the other hand looks like it would work. Can you upload the STL somewhere and I will make a test.
Best
Stefan
Hi @csullivan107,
it can be indeed hard to get used to the way software is distributed and built from scratch in Linux. Sorry for the frustration it causes! The team here is working on providing a more user-friendly solution, but as always it takes some time.
Basically, what Damien is saying is that Qt is distributed with Ubuntu (using the package manager) but can also be installed directly from its origin. The steps he has shown are for when you install it from its original providers:
This will lead to a different location of the Qt installation on your system than if you install it with the package manager. This is the reason you have to provide it in the cmake-configuration.
Now, from my experience cmake should be able to find Qt5 when it was installed through the package manager. If I’m correct, you have tried this, but I think you are still missing some packages. I’ve tried to guess which are the ones necessary:
sudo apt install libqt5core5a libqt5opengl5-dev libqt5widgets5 libqt5gui5 libqt5xml5Then try running again the cmake configuration that produce the message you posted. This should be quick to test. Otherwise you can try to install Qt from the link posted above and follow Damien’s instructions.
Best
Stefan
