Advancing Connected Workflows with Autodesk Fusion 360 and Autodesk Platform Services

JAMES: Welcome. I'm James, and today I'm going to talk about advancing connected workflows with Fusion 360 and Autodesk platform services. First, a little bit of background on myself. I'm a robotics research engineer here at Autodesk research, based in the beautiful pier 9 in San Francisco.

I have a Bachelor and master's in mechanical engineering. And I've worked on everything from 3D printers, railroad systems, helicopters, 5G antennas, autonomous construction vehicles, and now, adaptive assembly robots. And building and deploying these systems has taken me on many adventures across the globe to some very hot and some very cold places.

And what I'm passionate about is bringing innovations out of the lab and getting them to do real work in the real world. At Autodesk research, we're focused on eight key research themes. They represent areas and industries that we believe have the most potential for transformation and design and make. My work focuses on our robotics team, adaptive product assembly.

We're investigating how robots can assemble products where only the design data and specification of the robot system is required, allowing robots to easily handle part and process variations. However, what's common across all of these research themes, is the need for a connected design to make experience.

So even though the focus of today's talk will be on a robotics workflow, know that the principles can be applied to many different applications and to your own challenges, as well. Now in our adaptive product assembly research, we use Fusion 360 as our CAD program. On the left side of this red box here, we see a simple robotic work cell that consists of a robot mounted to a table in the middle of a room. And this is a model of an actual setup that we have in San Francisco.

And on the right side are two product designs that one might want to build with robots. One is a Stewart platform, a complex mechanical assembly, and the other is a skateboard truck. And we want to take these designs and go seamlessly from our CAD authoring to robots assembling these products in a work cell.

And on the left side of the blue box, we have our research robotics software platform. This is used for running simulations, as well as driving the actual robot hardware. And on the right side is a photo of the actual physical space in our lab. And so we have our physical space and its digital twin representation, and all are grounded in our ground source Fusion CAD data.

Now, this research workflow is going to be the motivating example for our case study today. And the origin of this work came from finding ourselves losing a lot of research time to import, export operations, and lacking a robust way to collaborate and share CAD files across the team. And when we started crafting this workflow, we realized it's beneficial outside of the robotics specific context, as well.

So even though I'm going to show a lot of images of robotics CAD designs in Fusion 360, know that these are just one example of the CAD that can be used. And that this workflow is generalizable to other Autodesk products and any external platforms that you might want to connect your CAD data to.

Now, I'd love to know a little bit about who you are and what brings you here today. Perhaps you're a manufacturer looking to streamline your processes by getting CAD data seamlessly from your design engineers to the factory floor. Or maybe you're a developer of next generation technology, such as VR, and want to build a workflow to get your data into your virtual reality experience.

So as we go through the presentation today, please keep in mind your unique interests and challenges, and how you might be able to apply some of those tools shown here into your own work. And keep an eye out for my contact information at the end of the presentation. And please feel free to reach out and let me know what connected workflows you're excited to create.

Now, let's get into our learning objectives for this session. The first one is identify. We're going to identify the benefits of connecting our CAD data to external software platforms, and understand why we'd want to do that. Next, we'll design. We'll design the overall workflow and understand the essential components and system architecture that makes this possible.

And then we'll demonstrate. Finally, I'll do a quick demo of the end to end process that I implemented for our research team. And this will give you an idea for what kind of workflow that you might want to make. So let's start with identifying.

Why do we want to make connected workflows in the first place? Well first, for efficiency. Manual workflows take time. And adding automation increases productivity and allows you to get your solutions working faster. Second, is collaboration. File based collaboration is hard. And when you're using different file versions, it's difficult to reproduce the results of teammates. And there may not be a single source of truth for your data if no one can agree on what the latest file version is.

That means work is duplicated across teams, and it makes it really complex. It can also be difficult to share your designs within your team, and especially outside of your organization with external stakeholders. And finally, there's the idea of convergence. We want interoperability across platforms and across industries. We want to get more granular data access and detail into what is going on in our systems.

So let's look at a rough example based on my experience working on a robotics project using manual import and export workflows. For each CAD model that I want in my robotics platform, I first need to export it from its CAD program that it was authored in. I need to save it to my local file system somewhere, then I find it on my computer, re-import it into the robotics software. And finally, move it around and adjust it to get it into the right position and orientation.

And this can take up to 10 minutes for just one file. Now typically, a robot worksite will have many different tools and parts in it. And my product assemblies also consist of many different parts. And furthermore, after importing a design into the Robotics Platform and going through that whole workflow, I might realize I need to tweak the design in CAD and have to go back into Fusion 360 and restart that whole process again.

So especially at the beginning of a project, I could expect to be doing these import export steps up to 10 times per day, just tweaking my design and getting it right. So over the course of a month, this all adds up to over 30 hours in total of this tedious, frustrating work. Work that isn't core to the problems that me or my team are trying to solve. And now creating a connected CAD workflow, we can take this time to zero. Saving almost a week per month of effort that can be redirected to a more productive activity.

So now let's look at a concrete example. Here, I have a Fusion 360 work cell open, and a robotic work cell I'd like to export. I need to click through the menus and select the right action for each part. I need to select the right file type to export to, the location to save the file to, then I need to wait for the file to process before moving on to the next one.

And as you can see on the left side of the Fusion window, there are a lot of models in this work cell. So this is going to take a long time. And I'm not even showing the import process into my robotics platform. And so we really want to do less of this and more of this. Simulating and running robots to put together product assemblies.

Now just a reminder, the Robotics Platform I'm sharing here is an internal research robotics platform. And it's the motivating example for the case study today to just show what is possible, and what you can do with a workflow like this. So as you go through the presentation today, I'd ask you to think about your own workflows and where you think you can add automation to save you time and effort.

So now we've identified why we might want to create connected workflows and how they can make your processes more collaborative, more efficient and bring us closer to convergence. So now let's look at the major components needed to make this work so we can design a system to do the automation.

Let's take a look at these major components. To start, everything centers around your application. When you have a Fusion design or any CAD design you want to connect to your application, we'll open that file in Fusion. Now keep in mind, all Fusion data is backed up and stored to your Fusion Cloud account. And each Fusion asset has a cloud URN, Uniform Resource name, that is a unique identifier for that design in Fusion.

This URN can be read from the API infusion. So you'll run a Fusion script or add in that writes the URN to your external applications project. This might be a database or a file stored locally on your computer. Now once this connection between your project's data and the Fusion URN is created, you won't need to reopen Fusion or do any import or export workflows if the design changes. And why not?

We'll use Autodesk platform services. These are APIs, application programming interfaces hosted by Autodesk, that allows us to programmatically access the Fusion data stored in the cloud. And so the APIs we're going to use today for this workflow is first, the authentication API. This is going to make sure we're accessing the right data and that your data is safe from others.

Then we'll use the manufacturing data model to get different versions of the Fusion assets and see if any of our projects files have been updated in Fusion. And if there are new files that we can get the latest version of into our application, we'll use the Model Derivative API to extract that data and convert that file into a format for viewing in our application.

And then finally, we'll integrate the Autodesk viewer SDK, software development kit, into our application so that we can interact and view our CAD data, native and embedded inside of our own application. Now just remember, for any given Fusion design, we only need to run that script from Fusion once. After it's connected, every time you start your application or an interval of your choosing, you can use Autodesk platform services to get that data and to check for updates to it.

So let's take a little bit of a closer look at the Fusion 360 API. First, we'll open a design in Fusion. You should look a little bit familiar by now. And then we're going to run a Fusion 360 script or add in. This will be a Python or C++ code that runs inside of your Fusion environment. And there's plenty of great documentation on creating API scripts and add ins and that will be linked at the end of this presentation. So we won't go through all of those details here.

But at minimum, what we need to do is we need to read that project ID file version and file version ID for your Fusion design. And we need to write that out to our own application. And these will be used later with the platform services APIs to get the data from the cloud into your application.

So these are the three things that we are requirements that we have. But we might also want to add other data and write that to our application, as well. So in the case of a robotics program, things that I'm looking for are component poses relative to some work cell origin and the relationships between components.

And so we're going to write all of that out and save it to our application. And that's up to you where you want to store that data inside of your own application. So that's how we'll use the Fusion 360 API to write our designs URNs and get them into our application. Now let's take a look at how we'll use Autodesk platform services APIs to actually get that CAD data into our application and viewable, and allow us to interact with it.

But before we can create our own app, we need to create an APS application and to do that we'll register it through the APS developer portal. The developer portal is where you can access design and engineering data in the cloud. If you already have an Autodesk account, you'll proceed to log in, and create your app. If not, this will be the opportunity for you to create a free account. And these are pretty standard steps.

So we'll go through them quickly. And there's great documentation that will also be linked. So we're going to create a new application. We're going to use a traditional web app. And then we're going to give it a name, a description, a callback URL, and select what APIs we want this application to have access to. And then finally, make sure you note down the client ID and client secret, because we'll need these in the next step when we create an authentication workflow.

So in order to access Fusion data and use the manufacturing data model and Model Derivative API, we need to authenticate this newly created app to act on a user's behalf. And so using that client ID and client secret from the App we just created, we'll direct the user to a Three Legged token authentication workflow.

And so we won't go into all the details here, but in the UI of our app, we'll send our credentials to APS authentication service and specify the redirect URI. This is the same as that callback URL that we saw when we were creating our application. And then from there, the user will sign in to their Autodesk account and allow the App permission to the required APIs.

And when authentication is successful, you'll get back an access token with the appropriate authentication context that can be used for the following API calls. So now that we have an APS app running and we have authenticated, now we can access our Fusion data stored in the cloud inside of our own application programmatically. And for that, we'll use the manufacturing data model API.

The manufacturing data model API allows you to programmatically read, write and extend the product design and manufacturing data stored in the cloud. Some common use cases are getting the hierarchy of a model, getting its bill of materials, and generating step files and thumbnail images.

For our workflow today, we're going to use the API to check if there are newer versions of a specific Fusion file. So we'll start with our application again. And we're going to need that Fusion project ID, file ID and file version ID. And now the manufacturing data model uses GraphQL to send queries to its API.

And we won't get into the specifics of the specific structure of that GraphQL query, but again, there's plenty of great documentation readily available. Now, something worth noting here, is that in order for the manufacturing data model to access the data, the user that authorized the App must of course, have access to that underlying data. And so a great way to organize your projects is to have a common Fusion team, and a Fusion project where all that shared data can be stored.

So now we know that all of our users have access to the right data. And then when we make our API call, we can get all the different file versions that have been authored for that Fusion file. And then, with knowing the file version ID that we have locally inside of our own project, we can check to see what the latest file version is and if that matches what we have.

And if not, we'll use the API in the next step to translate the Fusion 360 model into something that we can view embedded in our own application. So if a Fusion file needs an update, we'll use the Model Derivative API to translate the design from the Fusion 360 file format to something that we can view inside of our application with that viewer SDK.

And then the Model Derivative API can be used with over 70 different file formats to translate designs into SVF, serial vector format, so they can be rendered in a web page for viewing and for interacting. And so to do that, we need that Fusion file version ID. That's going to be that latest file version, typically, that we got from the last step. And we'd like to send a request to the API for it to translate that model into something that is viewable. And if that translation is successful, the API will return a new Uniform Resource name, a new URN, with that translated file that's now viewable in that SVF format.

And so finally, we have the viewer software development kit. This is a web based 3D viewer that can be embedded inside of your own apps web page. And this will be how your application displays CAD data that we've pulled from Fusion 360. And now the viewer has some powerful tools that enable interactivity, such as pan tilt Zoom in 3D space, adding toolbars and menus to the viewer, you can create exploded views of assemblies, you can display different layers. And you can even mark up your CAD files.

Now using the URN that we got from the Model Derivative API, that translated Fusion 360 file, we'll use the viewer SDK to get a viewable object from cloud storage and display it in our web app. And so now let's put it all together. And just remember, all of this is happening inside of your app using these APIs without any additional user input.

So to start, we have our authentication API. We're going to use the client ID, client secret and callback URL, and if that's successful, we'll get an access token. And that access token will allow us to use the manufacturing data model with that Fusion metadata that we wrote out from the Fusion 360 API. So that project ID file, ID and file version ID.

And from that we'll get the latest file version. So we'll be able to tell if the part that we have in our local project is up to date or needs to be updated. And if it needs to be updated, we'll use the Model Derivative API that's going to translate that file into something that's viewable in our viewer.

And so in the end, we'll have our custom app something like we have here on the right hand side. We have our custom application running the viewer so we can see our 3D models. You can see my robotic work cell displayed. And you can see on the left hand side some custom toolbars and interactive elements that we've added.

So let's take one more look at all these major components together. At the very top, we have our Fusion Cloud model, where all our Fusion data is stored. We'll use the Fusion 360 API to write out the URN of our designs into our application. And then from there, when our application starts, we'll use the platform services APIs to get the latest version of the files, translate them into a format for viewing, and then we can embed that and interact with it inside of our own native application.

So now we have identified why we might want to create a connected workflow. And we've looked at the major components in the design of what a system like this might look like. So now let's see a demo of the end to end process.

On the left hand side here, I have my Fusion 360 work cell. I'm going to run my script. And it's going to write out that metadata to my own project. Great. Successful. Now, on the right side, I'm going to start my application. Then I'm going to authenticate.

I'm already signed in, so I don't need to type my username there. My application is going to start. We can see the viewer loading the model. And here we go. On the right side, we have my viewable and interactive robotic work cell that's the same as what I show in my Fusion 360 model design.

And so now something to note here, is that the viewer window on the right and how I started my application is specific to how we've implemented it in our own workflow. But your application might look a little bit different.

So now I've gone through all three learning objectives for today. But let's go beyond. What else can we do? What else is possible with a connected workflow like this? We can do things like property extraction. We can calculate the physical properties of components. We can do materials analysis. We can do automatic checks on our Fusion files, like Fusion file linting, to make sure that it's in the right format before we export it to our application.

We can get better data granularity. We can use the manufacturing data model API, or the Model Derivative API to get a more detailed view of our Fusion files. We can look at some components of designs and even get their properties. And then finally, there's this idea of bidirectionality. The workflow that I just showed today is a one way data flow.

When an underlying Fusion file is updated, we're able to automatically get those updates pulled into our own external application. But what happens if we generate some data or modify a design in our application and we want to push that data back into Fusion 360? That's also possible. And now, it actually allows your Fusion Cloud model to be your single source of truth for all data. This is a very powerful feature that we have.

And so to finish off here, just want to remind you that all the APIs shown here are public APIs. And there's some great documentation online and example code that can be found for the Fusion 360 API, as well all the Autodesk platform services APIs that I've shown. And although I'm an Autodesk employee, I haven't used any internal tools or special treatment to create the workflow that we showed.

And there are plenty of customer success stories on the APS website where you can learn how Autodesk customers have successfully used these same APIs to create their own connected workflows.

So I'd like to thank you for joining me today for this case study. And please, feel free to reach out. There are numerous ways to connect with Autodesk research and our community. You can feel free to visit our website, any of our socials, or email me directly. Thank you.