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