Jul 27, 2022 10:00 AM PDT

Modeling Embedded Systems in the Cloud

Learn how and why you should be modeling embedded algorithms and systems using an intuitive block diagram environment on a cloud platform. In this webinar we will discuss:

Session Length: 45 minutes

Thank you! We look forward to your attendance!
Oops! Something went wrong while submitting the form.
Please check your information and try again.

Speakers

Brian Vetere

Brian Vetere

Application 
Engineer
Kevin Omwega

Kevin Omwega

Growth and Business Operations
Reda Dehy

Reda Dehy

CEO and
Founder

Modeling Embedded Systems in the Cloud

What this webinar covers

Learn how and why you should be modeling embedded algorithms and systems using an intuitive block diagram environment on a cloud platform.

Agenda and Speakers

00:00 - Introduction

06:36 - Model Based Design (MBD) History

12:25 - Challenges desktop tools present in MBD

20:17 - Designing a Quadcopter in Collimator Demo

28:49 - Conclusion and Q&A

Brian Vetere

Brian Vetere

Application 
Engineer
Kevin Omwega

Kevin Omwega

Growth and Business Operations
Reda Dehy

Reda Dehy

CEO and
Founder

Modeling embedded systems in the cloud webinar introduction

[00:00:00] Kevin: Thank you so much for joining. There's a couple people who weren't able to make it today, but we'll send them the video after this. But it's really great to have everyone. With that I will pass it on to Reda and Brian to introduce themselves. So Reda, do you want to kick us off? 

[00:00:25] Reda: Sure. Hi everybody. Welcome, my name is Reda Dehy. I'm the founder and CEO of Collimator. Previously, I was an electrical engineer by training. I worked as a software engineer at companies like Motorola and Samsung. After business school, I was situated at a company called medic digital health startup that's now a publicly traded company and where we used Google glass to help doctors with their documentation burden. After that I did a short stint as a VC before deciding to go back to building things and go back to my roots as an electrician. And that's here we are at Collimator.

[00:01:01] Brian: I'll pick up. I'll pick up next. Yeah. I'm Brian Vetere. First application engineer here at Collimator, before this, I came out of the space industry almost 10 years as a controls engineer, doing lots of modeling and simulation, of launch vehicles and, and some missiles. Then I did a brief stint in additive manufacturing where I 3D printed metal. Got a cool watch band to kind of prove it. That's about my only souvenir from that. And now I am here in the software world and I will be your presenter today, Kevin.

[00:01:34] Kevin: Awesome. Hey everyone, my name's Kevin Omwega. I am in charge of go-to-market here at Collimator. I joined Collimator after spending three years at a company called Samsara, Samsara is an IoT company that recently went public. And there I ran the product organization for the third largest product group, which is focused on equipment monitoring. I effectively joined Collimator to solve a lot of the challenges that I faced, while trying to run and build hardware products, hardware and software products. I saw a lot of the challenges that we faced and I knew that this was a massive problem that someone needed to solve. And I'm really glad that I've gotten the opportunity to do that, to do that today. And it seems like there's lots of people who are kind of facing a lot of the same issues. And so hopefully, during this webinar, you'll get to see how we can help improve your workflow, and really help you bring products to market faster and reduce risk on your development. I hope you guys will be able to get a better feel for what we have to offer. With that, just to recap the goals, for today. One, we want to show you exactly what benefits that you get if you move your modeling of embedded systems onto the cloud. Two, we want to make sure that you guys leave with a very good understanding of what Collimator has to offer and what it can do for you. And then, finally, we want to be able to show you all of the improvements that you can make and why, you know, we think that this will provide a kind of a step change improvement in your workflows day to day and answer any questions that you may have.

With that. I'll pass it on to Reda, just to give you a little bit of a summary for why Collimator exists and, and kind of give you a little bit more information about, what he was thinking when he decided to start Collimator.

[00:03:58] Reda: Sure. Thanks, Kevin. So, something I've experienced having been both in the, the hardware and the, the software realms, and I'm sure something that many of you here have, have experienced as well, is that the tools that software developers use are very different from the ones that, hardware engineers use, in the sense that in the software world you probably see every day a new startup with a better solution to make software development better, faster, or cheaper. And that's naturally because developers are scratching their own itch and building solutions to their own problem. But in hardware, the tools that electrical, mechanical control, systems engineers and so on, the tools that these types of engineer’s use are the same ones that they've been using for the past 10, 20 plus years.

So, we're not seeing the same level of innovation in the hardware space and we wanna change that. And we're doing that by bringing the same mindset, the same software mindset to the hardware tooling. Specifically we focused on modeling and simulation which is becoming increasingly more important because systems are becoming more and more complex, with the trends in electrification, autonomy, 5g, IoT, and so on. These trends are making systems and the interaction between these systems more complex and therefore much more critical to simulate before going into production. So, we need more sophisticated tools to be able to design better, better hardware.

Ultimately our goal has always been to empower hardware engineers with better tools in order for them to build the next generation of physical product that will make the world better. And, and just to touch on the point of why now, and the reason why this is actually possible at this moment, it's because of two major inflection points. You’ve got Python and you’ve got Cloud. So, on the one hand, Python has now become the most popular language out there. It is ubiquitous, but in academia and in enterprise, and it is used for most machine learning applications as well. On the other hand, we have Cloud, which means two things.

First, web technologies like WebGL, web assembly, etc, are making it possible to create a user experience that is richer, more intuitive, more collaborative, than a traditional desktop application. And then you also have distributed computing. So, for instance, with AWS engineers can now easily access clusters of CPUs and GPU on demand and therefore be much more productive.

My colleague will share more on these points in a minute. With that just wanna say thank you again for joining and I hope you enjoy our new tool and you find it helpful in your work.

Model Based Design (MBD) History 

[00:06:36] Brian: Awesome. Thanks Reda. So before I kind of dive into some of the presentations, I just wanted to ask everybody if you would just type in the chat, kind of what either, what brought you here today, kind of what you're hoping to see in the session or, I would also love it if you would share what problem you're trying to solve would you're trying to model, that would help help me kind of tailor this towards you guys.

So, if you can throw that in the chat, that would, that would be great. Thank you. And with that, I’ll dive in.

All right. So, kind of the first question everybody generally asks is how has embedded development gotten where it is today? Why do I need the Cloud? Why bother when what we've been doing works.

We are still developing these systems. And so, I just wanted to talk through a little bit of the history that led us here. So, the V model, the design V, many of you have probably heard of. This came out in around 1990. It basically solved a big problem of communication among everyone.

We had a defined process that everybody could follow and everybody communicated well, all the different stakeholders in a major system that was very complex could talk. So, if I was building an airplane, this worked really well and solved a ton of pain points. But out of that from the nineties, came basically a waterfall process.

I do one thing then do the next step and it didn't have any model. There was nothing in the process written about operations or maintenance. Once I produced an airplane and delivered that to a customer. I was done, you know, there was, there was nothing after that point. So as we sort of have ‘software start eating the world’, as they say around the two thousands, that sort of led to model based development.

And what model-based development did for us was basically let us work in a kind of an agile software framework for our embedded development instead of a waterfall process that really solves a huge problem. These two things are still core fundamental things that any tool today needs and has to have, they were great, but that kind of led us to what are a few of the more modern problems as we've gone forward.

What else has this change kind of led us to. Basically, three things that have really kind of changed systems over about the last 15 years. First, even my embedded systems are now connected. And you can think about this in many ways. When I have a light bulb in my house, it's connected, and I can ask Alexa to turn it on and off.

That's not just true for simple consumer products or cell phones, but it's also true for cars. Tesla’s have been connected since 2012. And this has really led to a lot more data being available. And the fact that I have to support this system, push out updates and different things over time. This has also led to one of the core things that the V model also didn't really consider at the time of the V model.

Everything was essentially one direction in connection. I had a speed sensor that talked to a throttle control. The throttle control didn't have to send any data back to the speed sensor. Everything was one directional - unidirectional - and there wasn't a lot of bidirectional communication. 

Now in the modern world if you think back to that light bulb example, my light bulb and Alexa both have to talk, and they're both gonna evolve. Alexa’s gonna get better. The interface might need to change as Amazon improves it. And I might need to update my light bulb, which means that now as I have this kind of bidirectional communication between all of my systems, that makes them a lot more complex, and it makes creating derived requirements harder, and they're gonna constantly evolve, which sort of leads to kind of this last thing, which is. Everybody now from 2008 on, we've kind of just expected that our devices are gonna get new features and new capabilities without me buying new hardware. So, if you bought the first-generation iPhone in 2007, in 2008 Apple gave you new features and new capabilities at no cost.

And that update process while it started there in cell phones has spread. And I think the best large product example out there is Tesla. Tesla connected all their vehicles back in 2012, and really from a controls perspective and look at what they did with all that data from 2012 to today.

They took that Model S, the first connected car and improved just the software, the controller, and made it 30% more efficient. They didn't do anything to replace or upgrade hardware. They just used software, pushing updates over the year and made it 30% better. Now, how great is that? If I have a car five years into ownership, it has 30% more range.

That's unbelievable! Everybody loves it. And now it's kind of a consumer expectation. So, I'll dive into a couple more specifics, but I just wanna pause there. Any questions on this? Any surprises here? No, nobody's surprised at all. Okay. We’ll just keep going then.

[00:12:07] Kevin: I think I see, I see something in the chat. Someone's excited to see a demo.

[00:12:11] Brian: Oh, okay. We'll be getting to that.

[00:12:15] Kevin: Yeah. So let's breeze through the next couple of slides and then, we'll get into the demo so that you guys can actually see what it looks like in real life.

Challenges desktop tools present in MBD

[00:12:25] Brian: Sounds great. Thanks, Eric. Yeah. So just a couple other quick points, the tools that are available today were largely designed as desktop apps that leads to a couple pain points. One is just generally that my data's already in the cloud. My devices tend to stream there. And the other is that, I'm now putting a burden on the engineer, software developer, or the control system designer, to stay current.

If there's a bug found and it's on a desktop app, the burden's on them to go find it and install the fix versus in the cloud, you're gonna get it and probably be notified automatically that, “Hey, something, this is a problem and it's been fixed!” But every piece of software, every development tool has bugs. They always will. And you don't really wanna have to deal with this burden of every day, checking and saying, what else? What else? 

[00:13:22] Kevin: And actually, one interesting anecdote here is that, we have a case study, that if you guys haven't had the opportunity to read through it's actually really insightful, where, one of our, one of our users was building a groundwater desalination plant, and she ended up having to spend at least one day, every single time she had to upgrade MATLAB and Simulink. And every single person on her team had to do the same. And so, if you actually look at the lost productivity and complexity managing versions, upgrading and installing, I mean, it is immense.

And so to us being on the cloud, is a way in which we can actually kind of give you back your productivity and allow you to spend more time designing your system rather than managing your tools.

[00:14:19] Brian: Awesome. Thanks, Kevin. And then the next one is what Reda kind of talked about in his welcome. Basically, there are a lot of proprietary languages associated with the engineering tools out there. What we've kind of seen is that as you connect systems, they need to talk. There needs to be a glue language. The world has kind of decided for us what that language is. So, a lot of the reasons that these proprietary languages made sense 20 or 30 years ago, are because they were designed perfectly to work in that bubble to do that specific application. It really doesn't apply anymore when I need to work with the whole world and my system's gonna talk to the whole world. I need a language that meets that need.

[00:14:07] Kevin: Yeah. You know, I think here I get reminded of actually a conversation I had with a customer yesterday and he pointed me towards a 100-page tutorial on how to convert Python code into MATLAB code. I thought it was really funny. We want to give you the tools to be able to be more productive.

And so, that's why everything that you'll get to see today in the demo is really centered around the language that people are using every day in data analysis and developing control systems in AI ML and all that.

[00:14:19] Brian: Awesome. And then the next one that comes up is that I have a lot more data now to do in design, and I'm gonna constantly get more as my system goes into operation and I'm supporting it, but as systems also become more autonomous and we expect them to do more. That means I have more test cases.

So that's kind of a big, big challenge. If I just have a desktop computer, I've got four or eight cores, I can only maybe run four or eight simulations at a time, but now I need to do thousands or potentially millions of simulations. And so that can be kind of hard to both set up and to access from just a desktop computer.

Okay. And then the last one, collaboration. I kind of like this one. I've gotta, I'm gonna take the story here instead of Kevin. But basically, everybody in an organization needs to use or wants to use a model and make use of it. So, I don't know if any of you are working at one of the larger organizations.

There are many out there that have established these digital transformation offices to kind of do digital engineering and, and make models available to the whole organization. So, one of the things that I thought was funny working back in the space industry, one day, I'm just sitting at my desk and I get a phone call from finance. And why would a controls engineer ever get a phone call from finance? I basically assumed I was in trouble. But they wanted my model. They were like, “Hey, you have a model of an upcoming launch. I'd really like to get my hands on that and kind of see where all the different pieces are gonna land as the stages separate, and fall to the ground.” and I was like, “Oh, sure. Okay. Why do you want this?”

So, I sent it to them by email, and then obviously they didn't know how to run it. So, I had to walk down the hallway and walk them through it, but basically, they wanted to run it. If something falls a hundred miles off the coast it turns out that's an export and finance needed to run my model to show that and have a reference point of what they used in case the IRS audited them.

So my model needed to be used by finance, not just other engineers, which was kind of surprising to me. Those are kind of the four. Oh, go ahead, Kevin. 

[00:18:00] Kevin: Yeah. At this stage, maybe let's take reactions. Do any of these pain points resonate with you? Have you experienced this in your day today? I'm curious to see, just type in a reaction if any of this resonates with you, like a thumbs up.

[00:18:31] Brian: Thanks, Eric. Yeah, nobody else? No other takers? 

All right. So again, just before I dive into the demo, here, what Collimator made, is really a modern cloud-based platform. To support all of these modern kinds of changes in embedded development to really unlock digital engineering. Digital engineering, we all talk about that's really, really challenging to do as it is now.

That's why these organizations may have created digital transformation officers that are huge organizations. Some of them are like 60 people big to do this. It's not an easy thing. It's very hard and I'll show you how to make it easy with Collimator. So, I'm gonna kinda start with a really simple demo. Basically, it is a quadcopter trade study.

I am going to attempt to make a selfie drone, see if I can just pull some off the shelf parts and see how that will work. So basically, for myself, if you take a picture of me I wanna make sure I get a good background. So, it's gotta be able to fly at least five meters above ground level. It's gotta hover for at least two minutes, you know, in case I need to fix my hair or anything like that, and I wanna fit it in my pocket.

So, it should be lightweight, something less than five pounds. All right. Any questions on that? oh, Sanjay, I think has a question there. Let's see the effort of maintaining version control, integration to cloud certainly resonated with auto. Yeah, absolutely. Thanks, Sanjay. Yes. I agree with that. And that is a huge challenge as you have to support a lot more different branches and software releases.

Designing a Quadcopter in Collimator Demo

[00:20:17] All right. So, I'm gonna leave the slides. I already logged in. So, this is the first page you'll see. When you log into Collimator there is a list of projects here on the left. And then a couple just pretty simple things, I can build either a new model or a new notebook. So today we can just jump in and, you know, if I was doing a trade study like this, if I'm a control systems engineer, you can think of yourself that way. The first thing you're gonna do is probably get text sheets. From websites or otherwise, and then maybe even just start and Excel and add up weights of components and that kind of thing, quickly, which you'll realize is that you need to do some kind of pre preliminary design work, some kind of a dynamic simulation to know things like, all right, I've said, this can hover.

And I picked a battery that I think has enough power to do that. But how long does it take to get there? I can't really figure that out without doing some kind of a dynamic simulation. So, Excel won't be enough. And I might jump to something like some Python code in a Jupyter notebook. So as this takes a minute to load here, maybe slightly longer than a minute, here we go.

Okay. So, I might start coding something like this. And right now, what's probably happening is everybody watching this is probably starting to read that code. Just don't do that. Don't don't even bother. I can already kind of see the fact that… I can see different eyes in the videos that you're trying to read and figure out what's going on.

And so, you can already see that it’s hard to follow. So, I want to kind of contrast that with the model of this same thing. And so here. My model of just a simple quadcopter and the modeling environment. So, kind of before we dive into what all these blocks are just a quick high-level overview, I've got a library of different blocks or components that I can drag to a canvas.

So, we'll just, let's just do that quick. I'll make something super simple, like a clock and then maybe yeah, a clock and a delay we'll wire those up and connect them. Play button to run the sim and then I can click and see any bit of my data. So now I've got two pieces of data. What do those look like?

I'll zoom in a little, cuz that's too much, too much time so, we can see the separation there. Oh, a little too far, but basically, we got two lines there and let's just, let's just rerun this for less time, 10 seconds will be easier.

Then you can clearly see those two lines. So pretty simple to kind of do some modeling and look at data. Well, let's get back to my, well, I think we have a question. Is that right? Kevin? alright, let me read. Dave's question goes. Oh, Kevin, I can't hear you're on mute.

[00:23:43] Kevin: Oh yeah. I was saying, let's keep going. We'll tackle the questions towards the end.

[00:23:48] Brian: All right. All right. Let me know. And yep. Just diving through the model here, I've got just six blocks to build up my quadcopter. So, I've got command, whatever I'm asking you to do in this case. See if I can fly to an altitude of five meters, a flight controller.

This is kind of my world as a control system engineer. So, this is just a simple PID controller. And then going back, you know, I've got a battery pack here, so I just got four cells and a battery pack that I've modeled. This was kind of an off-the-shelf battery that I put in the components. Two signals that I’m telemetring out and then a thruster or a rotor. So, the four of these are my quadcopter. 

Then I have my dynamics model. Basically, in this case, it's a one off, it can only go up and down. And my model here, that's all I'm exploring right now. But just a simple set of equations of motion to go kind of up or down. Okay, does anybody have any questions on the model? Or we can kind of get into doing, checking out those requirements, seeing if we meet them.

All right. Again, this is a lot easier to kind of read and just drill into just what you're interested in. So, for me, as the controls engineer, probably the controller. Kevin happens to be an electrical engineer. Maybe he would work on something like the battery. But let's run this and see if we meet our requirements.

So, I'll run it for five minutes and of time and let's just take a look at what I asked for and what we got. So, let's just make this big. Drag this over and I think I'm gonna zoom into the beginning first. So, what I've asked of my drone to do was first to fly to five meters. Let’s see if it did that. 

What am I seeing here? I think I can put the blame on me as the controls engineer. My controller doesn't quite hit its target, but I can tune it. That's okay. So, I also then asked it to go to 15 just to check, and see if it would fly higher than five meters and it did. So I achieved my requirement 1 that we can fly to five meters.

And then my second thing was I wanted to make sure that it flew for at least two minutes. Is my battery big enough for two minutes? It looks like we are crashing to the ground horribly at around 147 seconds, but that's past two minutes. So perfect. 

And then for this, you know, I've added up the components. I'll show you kind of back here. Weight is one of my model parameters here. And it's one kilogram right now, which is less than my five-pound requirement. And, you know, I, I've just kind of added up these components to put this parameter in outside of this and done. So, I've gone ahead now and I've, I've modeled this and now I might need to do something like save it.

I've got a model that I'm happy with. So, to Albert's question in the chat, what does that look like? So, anybody that's working on this, I'm in here and you can see the history of the last few minutes. I've run a couple simulations. I've also flagged a few different versions of this that I might want to go back to.

So, at any time I could go back to a different version. You can click on it and it would show me what it looked like when I had those other blocks in here. I can go kind of forward and backward in time, pretty easily. And if I needed to restore a version, I could do that.

So, the version history is pretty good there. And then the other kind of feature that there is, is that I might need to share this with somebody like either Kevin who might work on the battery model and maybe improve it. Or again, finance, what if, what if finance needs to run my model? And so, for that, I can go back to my project and just add a member at any time.

So, I could add Kevin right here. I could get to choose what I want. I can even let him edit it if he's gonna build the boundary or it might just need to look at it because that's all he needs to do. I'm gonna let Kevin edit it though. I'll save this. Kevin's gonna go ahead now and receive an email and he'll get that.

And then from there, if Kevin made any changes or even ran my SIM, it would show up on this list. So, that's kind of how that works and then it's pretty easy to collaborate and let anybody run it or edit it at the same time.

Awesome. Thanks Eric. Yep. Eric. Perfect.

Conclusion and Q&A

[00:29:49] Kevin: Yeah, there's a couple of questions. Okay. Go ahead. we're gonna get into recap, but we'll wanna make sure we are, we tackle the questions as we go along. 

So question from, Dave, it's clear that cloud performance, easy collaboration and easy open source integration is key to improving efficiency. Why aren't companies such as MATLAB doing anything to adapt to their market needs? I think Brian, you're ex-MathWorks and so, I'm curious to hear, what's the sentiment there?

[00:29:24] Brian: Sure. So, for a company… Using the same example, Mathworks, but you could take any of them including ANSYS. It’s the same. It's really hard for them to walk away from what they have today. They have a desktop app that makes lots of money, that thousands or millions of people use, I guess, in, in MathWorks case. How do they move on from that? That's not kind of the way that a company can work. It's hard to do it.

It's the same in any industry. You can look at automotive. Tesla's got some advantages and edges and could do connectivity really easily, because it didn't have a dealer network. But if you looked at how much Ford struggled to connect their vehicles because the dealers wanted to make sure that they were involved in that and they weren't getting cut out of service work as over the years, updates took over some of the service work.

So, it is really hard. Any kind of legacy company is gonna have those challenges, including MathWorks, to kind of modernize. They can't throw out what they're doing. That's gonna upset millions of users. Does that answer your question, Dave? Awesome. 

[00:30:26] Kevin: Awesome. All right. I'm gonna combine two of Albert's questions and pass them on to Reda. So, first, will our tool work with Git and how will it connect to my existing git repos? And then the second question is can you generate code for the flight controller model?

[00:30:52] Reda: Yeah. So, regarding the git integration that is on our roadmap, we hope to be able to offer it in the coming months. In the meantime, the version history and the version, the sharing capability that you've seen here, it's all tightly integrated within the app itself. And you can maintain a version within the app, but obviously we wanna make it available for, for people to connect, to their existing GitHub repo, and, and other, other students as well.So, we're working. We'll be working on these APIs pretty soon. 

Now the code generation is something that's, that will be coming up in the, the actually next week. People will be able to, to generate code for, for some of their, their models. If you, in this case, wanted to generate code for the controller you'll be able to, to click a button and you'll generate C code that can then go into the actual hardware to be. We can actually test it, in, in real life. So, stay tuned. Awesome.

[00:31:46] Kevin: Exciting, exciting updates coming. All right. Let's see. So, let's go to Eric's question. I love that it's on the browser. Does this mean I can send it to someone on my team and have him review it in real time? I think Eric we probably answered your question already. You do have, we do have, the capability to add someone to your model and you will get a version history of all of the changes that happen to your model. Kind of very similar to what you'd expect from Google docs, which is a feature that a lot of our customers are excited about. 

All right. A question from Sanjay, I will pass this to Reda automated version control is really cool. How do you avoid or take care of version conflicts where two members are editing at the same time?

[00:32:39] Reda: Right. So currently there is a locking mechanism. So only one person at a time can edit and that's exactly to your point to prevent these conflicts when, in the rare cases where some, where two people edit exactly the same part of the model. So we're blocking this capability for now, but in the future, what we'll see you coming is we will be enabling this real time collaboration where two people can be interacting with the exact same model at same time. just like when you see a Google docs, you might be able to see things moving. Obviously, it's much more complicated. The use case is much more limited, so we'll, it's in our roadmap, but it's not available for now.

[00:33:20] Kevin: Awesome. Awesome. All right. question for you, Brian, from Ethan, why is there only one thruster and not four, or is a thruster block representing all four rotors.

[00:33:33] Brian: Absolutely. Good question, Ethan, to catch onto that. Let me just go over here. So basically, I kind of just took it and then multiplied it by four, threw a gain in here and just said, “Hey, whatever, whatever one's giving me, let's just do four.”

Since this is only a one, one off dynamics model, I could kind of get away with that. but as I went to detail design, yes, I would have to break this up into four separate thrusters. Does that make sense?

[00:34:05] Kevin: Awesome. Thanks, Brian. Yeah. All right. If there's no other questions, maybe we can kind of get into, into, the recap.

[00:34:18] Brian: Sure, sure. Let’s just dive back to some slides then. Yep. Awesome. Oh, all right.

[00:34:29] Kevin: So, what, what, what did we see here? First we showed you a way in which you can model your systems in either a graphical user interface or text-based environment and this has advantages, but really what we're trying to do is we're trying to give you the flexibility and the power to select exactly how you build your models. And so that's kind of the first thing that you saw there, the second is around simulation, right?

With the click of a button, you have the ability, next slide, please.

So with the click of a button, you have the ability to simulate using high performance compute in the cloud. You don't need to provision servers. You don't need to manage a new cloud provider. You don't need to go into an AWS and pay AWS versus several other vendors where you need to do this in order to run your simulations in parallel and to compute thousands or even millions of test cases.

The third thing that we showed you today was around visualization. You have the ability and we're giving the power to you to explore, get insights from your model, understand patterns and do that in a way that's incredibly efficient and incredibly easy. 

And then finally, we showed you a way in which you can collaborate with everyone on your team. We know that no one designs a system by themselves. It is a collaborative effort. And so, we're giving you the opportunity to collaborate with your team in an incredibly easy way, with out of the box version control and next slide, with out of the box version control, with version history, so no longer do you ever have to worry about what is my one, source of truth.

With that, I think I saw a few more questions. Let's see from Ethan. I'll pass this on to Reda. Before exporting C code for the microcontroller. we would have to make this model more complete.

[00:37:02] Reda: Right. So, typically, yeah, in this modeling and simulation process, you will start with the most simplified version of your model and then test it, iterate it, and you’d want to simulate it throughout the process.

So, you can see and actually debug things, sooner and then add more complexities. So, in this case, we'll break down the model into more components, add more, more logic and essentially be able to cover more and more complex interactions and more use cases.

And then, somewhat touched on the next question, which is a 1D versus 3D simulation. If you mean 3D in the sense of the, the quadcopter being able to operate in 3D right now, the 1DOF makes the quadcopter basically go up and down, but if you wanted to make it, you know, turn and rotate and so on in all directions, that is, that is definitely feasible. Again, for the sake of, of simplicity, this starts with, with just 1D types of simulation, but we will add more, more complexity. We'll add more parameters, for instance, you'll be able to get the data from your accelerometer and control your quadcopter in that sense.

Now if you're referring to 3D simulation in the sense of the actual geometry, maybe like the thermal dissipation of the quadcopter, or maybe the wind, the turbulence, this type of 3D simulation. That's much more about multiphysics. That is not what our tool does at the moment.

So, we have tools like ANSYS that are more focused on that type of 3D simulation. But, again, if you're talking about 3D in the sense of, of multi, like spatial 3D, then, that is totally doable. Okay, perfect. Thank you.

[00:38:50] Kevin: All right. And so, just a couple of housekeeping items. If you haven't signed up yet, sign up here. We do have a free tier, that you can use and run up to 500 simulations a month. And so, feel free to go and try it for yourself and see what we have to offer. If you would like to talk more specifically about your use case, or you'd like to understand a little bit more about the quadcopter that Brian, showed or virtually anything else, you know, you can schedule a meeting with us here.

We would love to talk to you. We'd love to hear your feedback, your comments, and effectively give you a guided tour of what we have to offer. With that I'll pause for about 15, 20 seconds and see if anyone has a question. At this point you can feel free to go off mute, and ask a question or you could ask it directly in the chat.

All right. I feel like Brian did such a good job. There's no more questions. Actually, Albert has a question. All right. Perfect. Sure. 

[00:40:22] Brian: Yep. I'm gonna just jump back to the model then. So, to Albert's question, basically. Yes. Whenever I'm here, I have a list of global parameters and then anything that's a sub model. I can also apply parameters directly to that that only apply to this block. So that's kind of the basics of parameters there. And then to your second question here, I'm gonna jump over to the Notebook as an example. So, if you wanted a scripting environment that just calls the model that you've created over there, I could do that. This is calling a separate model. It's an e-bike model, but basically I can grab all the parameters in this case. I have mass and a speed target. And then if I wanted to do something like either run it. This just runs it as is, or I could change these and pass in new parameters to do like a parameter sweep or Monte Carlo. I could do that here in the notebook side of Collimator.

[00:41:18] Kevin: Awesome. And so the answers are yes and yes. We do have the Python notebook that you can use to run scripts, run multiple test cases. You can use it to call your model and run simulations. And it's also kind of self-contained, and so, you could feel free to model there. You could feel free to model on your model editor as well. The main thing here is that we have the flexibility and virtually anything that you could do in your existing tool today, we'd be excited for you to try it out in Collimator and see how it works. Thank you for the question, Albert.

Awesome. Well, thank you everyone. We really appreciate the time. This was really incredible to hear from you. We'd love to talk to you so feel free to send us a note, or schedule a demo. We'd love to answer any more specific questions that you may have, but again really appreciate the time. This has been enlightening and really incredible. Thank you. Have a good one, everyone.

Unlock the full potential of your engineering team with powerful features

Design

Explore the vast number of possibilities, model to your desired complexity

Simulate

Move faster with speed and agility, get high fidelity insights earlier

Visualize

Analyze your results, increase confidence on your designs, iterate

Deploy

Automatically generate code and deploy code to your target hardware

Collaborate

Integrate your workflows and streamline
collaboration