Stop solid merging at the Robot node level

[ShuffleWire]

Hi everyone,

I'm importing CAO (FreeCAD) to Webots. I've wrote a Python script for that, and work nicely ! It simply export my CAO into a proto (Robot) file.
However, translating CAO "constraints" to Webots "joints" is not easy : the former is a object with two members to link, and could be used anywhere, whereas the latter use an object with only one member, and link with the parent.
To deal with that, the easiest way was the following : declare as children of the Robot node all my parts (to get all my part in place, eventually adjusting the translation/rotations values). Then, for each of my constraints, I choose one of the two members (usually the first of the two), and I add a SolidReference to the second member as a children of the first part.
To make things clear, here is an example :

CAO (total mass = M)
   Constraints
       Axial Alignement
          Part1
          Part2
       Point Coincidence
          Part1
          Part3
       Point Coincidence
          Part3
          Part2
   Parts
       Part0 (no mass, just a shape of the body)
       Part1 (mass = m1)
       Part2 (mass = m2)
       Part3 (mass = m3)

Will produce the following pseudo proto :

Robot
  physics 
     mass = M-m1-m2-m3
  children
      Shape using Part0
      Part1
          physics 
             mass = m1
          children
             SliderJoin
                SolidReference
                   endPoint
                      name = Part2
             BallJoin
                SolidReference
                   endPoint
                      name = Part3
      Part2
          physics 
             mass = m2
      Part3
          physics 
             mass = m3
          children
             BallJoin
                SolidReference
                   endPoint
                      name = Part2

This should work like wonder, BUT !
Their is solid merging. And all my part will be merged as one, because they all define a physic node, as well as the Robot node.
My solution was to add a Solid node without physic as a children of Robot, and place all my parts as children of this Solid node.
Hence, it stop solid merging because there is no Physic on this node, and all my parts are free to move again !

However, this solution has two issues : It involves an artificial Solid node, and I'm starting to experiment issues when working with this. Especially using connectors to Solid outside of the Robot, it get messed up. (I've try without this additional Solid node, and apart from the fact that the robot is stuck, the connector work fine, for instance. That why I blame this "hacky" Solid node)

One solution would be to deactivate solid merging at the Robot node. It should not be that bad in term of performance because we should not have often solid needed to be merged with the Robot node. Moreover, The doc state :

By Solid child of a given Solid node, we mean either a node directly placed into the children list or a Solid node located into the endPoint field of a Joint placed in the children list. We extend this definition to nested Groups starting from the Solid children list and containing Joints or Solids.

If a Solid child in the above sense is not related to its Solid parent by a joint while both have a Physics node, they are merged at the physics engine level: ODE will be given only one body to represent both parent and child

That would match the description, given that currently, all solid that derivate from Solid are used, and not only the Solid themself. Or if we don't want to change things, I thing it would be wise to warn that solid merging will act also on the Robot node. For beginner Robot and Solid node might be two separated concepts (that the mistake I've made, anyway...), even if they are actually linked.

To sum up, I'm arguing on the fact that Solids being direct children of Robot shouldn't be merge together, I don't see use case for that to be useful. I totally agree on the solid merging process otherwise, but I don't see is point is this particular case. Moreover Robot node are always at the top of the node tree, which emphasis this particularity.

In the code, we could change only a bit of code :
in WbSolid:750 :
const WbSolid *const us = jointParent() ? NULL : upperSolid();
could become :
const WbSolid *const us = jointParent() ? NULL : dynamic_cast<WbRobot *>(upperSolid());

Careful however, that the condition on "left wheel" / "right wheel" (in case of a differential robot, I'm correct ?) should be studied : do we need it still ? Is it handled by the proposed modification ? Should we keep it as a special case ? (I'm not sure about it, if possible I would prefer remove hard coded value, and if need be move the wheels of the Samples that need to be updated to put the wheel as a direct children of the Robot node)

In addition, it should be checked that it doesn't cause trouble to this part of the documentation :

When designing the robot tree structure, there is one important rule to remember about the Physics nodes: If a Solid node has a parent and a child with a Physics node then it must also have a Physics node (1). A consequence of this rule is that, in a robot tree structure, only leaf nodes and nodes included in the static basis (see first note above) can have a NULL physics field. In addition, top Robot nodes do usually have Physics because this is required to allow any of their children to use the physics simulation.

Thank for reading up to here, I'm obviously open to any point of view, and aware that my use case is not the usual way of doing things in Webots.

Cheers

[ShuffleWire]

Well, I replied myself !
After looking for options, my best one have been to write a script which transform a CAD file format to something that Webot could read natively, without any additional "hacks".
Basically I'm transforming a representation based on constraint linked to 2 parts (the way CAD work) to one based on part linked to constraint link to part (the way Webot, and I assume other robot simulation software, work).
Now I'm happy with that, I have a full python script doing that !
I'm aware that VRML export could exist on CAD software, but I've not found it promising, nor including the option I wanted. The generated files was missing a lot of info on the robotic aspect...
I'm closing that for now, feel free to ping me if anyone in the future is interested for detail (or if I've time to spare writing something, depending on what come first).
Cheers

[omichel]

Would you agree to share your python script here?

[ShuffleWire]

I would be pleased to share with you such script, and I was thinking about posting it as well on the FreeCAD forum, which could lead to link the two software :)
However, I've been developing the script professionally, I'm not sure if I could share it. Moreover it's actually some really crappy Python code, with a lot of duplication and hard coded value and node, matching my use, but it's not pretty.

So I will see what I could do in that direction !

However, I could share the overall algorithm, which is actually not bound to FreeCAD, but could be used to anything as long as it use the CAD representation and the data is programmatically fetch-able.
Additionally, the python API on FreeCAD I've used is not rocket science, so I should be able to break it down to allows people to build something better on it. In particular I've been fighting with issues that I've solved now and I could share my solution to avoid people getting stuck at the same place :)

Overall, it's more at a PoC level, but I'm able to add Join/Sensor/Actuator properties in FreeCAD and never have to edit the generated file, which is so nice :)

I will keep you updated !