creo2urdf
creo2urdf copied to clipboard
[ADR] The `CREO2URDF` project
Background & Objectives
Motivated by the fact that our present pipeline for generating URDF models from CREO is broken due to an incompatibility between CREO v9 and MATLAB[^1], we decided to aim to export models bypassing the use of MATLAB and rely directly on CREO native API.
There are three essential reasons underlying this approach:
- MathWorks acknowledged the presence of the bug but replied that the patch is expected to be delivered in September 2023, which is too distant in time for our needs.
- Even if the patch arrives in time, it'll land on R2022b, while our current pipeline supports only MATLAB versions up to R2017 since we're not compatible with the multibody blockset type 2.
- In the long term, this approach should let us gain the necessary knowledge and expertise to further improve any automation related to CREO.
[^1]: For the time being, we're getting away with a workaround based on exporting mechanisms from CREO v9 to CREO v7 in order to be able to use the current workflow.
Outcomes
Eventually, we will deliver a SW component capable of interfacing with CREO through its native API with the goal of exporting all the necessary information to fill in a URDF model and formatted in the required files (e.g. XML, STL...).
Task Breakdown
From our preliminary brainstorming, it came out that we will tackle the feat with the following incremental deliveries.
✅ MVP-1 – ETA PI14
- We will decide which API to use (C++, Java, Javascript, CREOSON...).
- We will learn it.
- We will consider adding idyntree to the dependencies.
- We will attack the simple toy case described in https://www.mathworks.com/matlabcentral/answers/1879607-incompatibility-between-ptc-creo-9-and-simscape-multibody-link. In this context, we will consider both the options, with and without the intermediate shrinkwraps.
✅ MVP-2 – ETA PI15
- We will focus on one single iCub mechanism. For example, we could address the case of the head, which sports at least 2 joints.
✅ MVP-2.5 – ETA PI15
- We will focus on one subassembly of ergoCub that contains more than one kinematic chain, e.g. the lowerbody.
✅ MVP-3 – ETA PI15
- We will deal with the whole robot.
✅ MVP-4 – ETA PI16
- We will deal with the sensors as much automatically as possible.
✅ MVP-4.5 – ETA PI17
- Beta testing and dissemination.
⚙️ MVP-5 – ETA PI18
- We will aim to improve the automation grade of the overall pipeline, including the generation in the CAD of the intermediate steps (e.g., simreps, shrinkwraps, mounted mechanisms). Other possibilities may include the modification of the intermediate deliveries (e.g., adding a missing frame to existing shrinkwrap) instead of starting over from the original CAD model.
This is the entry-point Epic to the whole project and serves as an architectural decision record (ADR).
cc @Nicogene @mfussi66 @fiorisi @traversaro @salvi-mattia @Mick3Lozzo @maggia80 @Lawproto
Hi @Nicogene @mfussi66
We may consider accounting for a MVP-4.5 for:
- Beta testing. We need to identify a bunch of testers.
- Further refinements in the background.
- Finalize documentation.
- Present the work together w/ some mechies at Robotics Knowledge Base at IIT as a remote seminar.
What do you think?
cc @traversaro
Cool, thanks a lot to everyone!
Beta testing. We need to identify a bunch of testers.
To suggest someone: iRonCub mech team has been historically a long time user of simmechanics-to-urdf, I guess they may be interested in trying creo2urdf, probably we can ask to Gabriele Nava.
@Nicogene @mfussi66 @traversaro
I've just created the MVP-4.5 epic (ETA PI17) for dealing with beta testing and dissemination.
See #50 for tracking the potential activities of the iRonCub team as beta tester.