creo2urdf icon indicating copy to clipboard operation
creo2urdf copied to clipboard

[ADR] The `CREO2URDF` project

Open pattacini opened this issue 2 years ago • 4 comments

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:

  1. 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.
  2. 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.
  3. 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-1ETA 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-2ETA 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.5ETA PI15

  • We will focus on one subassembly of ergoCub that contains more than one kinematic chain, e.g. the lowerbody.

MVP-3ETA PI15

  • We will deal with the whole robot.

MVP-4ETA PI16

  • We will deal with the sensors as much automatically as possible.

MVP-4.5ETA PI17

  • Beta testing and dissemination.

⚙️ MVP-5ETA 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

pattacini avatar Feb 11 '23 10:02 pattacini

Hi @Nicogene @mfussi66

We may consider accounting for a MVP-4.5 for:

What do you think?

pattacini avatar Sep 01 '23 09:09 pattacini

cc @traversaro

pattacini avatar Sep 01 '23 14:09 pattacini

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.

traversaro avatar Sep 01 '23 14:09 traversaro

@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.

pattacini avatar Sep 05 '23 12:09 pattacini