How dynamic is OCAF

[DanB]

I have been developing a Digital Twin for a robotic arm, where I have a chain of links connected by joints. Up to this point, I have used forward kinematic to calculate every joints translation and rotation based inputs coming from the real robot, and not using a "real assembly" based on XDE. Coming from ROS I am used to having a static assembly in a URDF-file, while the dynamic assembly is defined by the TF. After learning about OCAF and XDE, I see some similarities.

TF in ROS is updated rapidly(default is 10Hz), how would OCAF work with such frequent updates? And what would I benefit from building an assembly with OCAF/XDE?

I hope this question makes sense.

 

[Quaoar]

@DanB Historically, XDE was developed as a data structure that would allow for holding colors, names, and assembly structure after importing all this from a STEP file. Because OpenCascade's shapes are not capable of holding metadata, OCAF was a natural choice. I don't want to disappoint you, but that's actually it. There's nothing more behind OCAF/XDE. If you wish, you might want to develop your own alternative data structures for exactly the same purpose. For example, people often use databases for representing product hierarchies and attaching whatever metadata to parts and instances. One particularly good choice is maybe SQLite (used in Shapr3D, for example). Something like MongoDB might also serve you well.

Nowadays, XDE has become a standard de-facto data structure for all data translators developed by OCC company, including their commercial addons (XT, SAT, DXF). Also, CAD Exchanger software being developed by a former project manager of OCC (now CADEX company) is XDE-aware and it nicely integrates with OpenCascade through this data structure. But, again, this is just a data structure. To be more specific, it's a Hierarchical Assembly Graph.

Regarding performance, it all comes down to the typical performance issues of C++. E.g., allocating new OCAF attributes is essentially a heap memory allocation that might be costly if used thousands of times. Data access could also be a hotspot if you tend to search for labels by their IDs intensively. If you want to see XDE in action, you might wanna check CAD Processor software which we had developed since 2016 with a great team of folks (now totally trashed by the company).

For me, XDE is a tool to read as much data as possible from a STEP file. Other than that, it does not bring much to the table and, what is worse, it's quite horrible at data manipulation scenarios.

 

[DanB]

Thank you, @Quaoar! This answer is very helpful, in terms of avoiding trailing into a non-viable implementation. The robots I develop this for have very few generic parts, so there is not much to gain there either.