Can Agentic AI Develop Embedded Systems with Model-Based Design?

追加: 2026-05-21

[00:00:00]This is an inverted pendulum that spins up from rest and then is balanced autonomously using a control system that my colleague Narin and I built. And what's interesting about it though is how we built this system. An AI coding agent helped generate requirements, helped update a model of the system that we had, helped design the controller, run simulations, test the generated code, and helped deploy it to the hardware you're looking at now. But it didn't happen in a single pass. a so-called oneshot approach where you describe a goal and let the agent figure out everything on its own. Instead, this was a collaborative iterative process.

[00:00:35]We guided the agent step by step. We reviewed what it produced, clarified our intent when necessary, and made targeted changes to the artifacts along the way.

[00:00:44]And that guiding is the important part because it's how you get outcomes that are verifiable, efficient, you know, in the sense that it reduces the amount of tokens that the agent uses. and importantly suitable for safety critical systems. And that's what we're going to talk about in this video. How to use powerful AI agents alongside trusted engineering tools like mat lab and simulink to design, build, and test engineered systems and why following proven engineering workflows matter even more when AI is involved. I'm Brian and welcome to a mat lab tech talk.

[00:01:20]Okay, the goal here is to control a physical system. in this case a Quanzer cube servo which is an inverted pendulum and it's connected to a Raspberry Pi running embedded control software. I also have a development machine running mat lab and simulink and an agentic AI tool which in this case I'm using claude code. I'm also using the Simulink agentic toolkit which connects Simulink with an agentic tool so that the agent can read and create Simulink models. But in addition to that, it also gives the agent the expertise to be proficient in modelbased design. So with this setup, what I want to do is develop the embedded code that will swing up the pendulum from rest and then balance it.

[00:02:02]And you've probably seen dozens of stories of people just vibe coding entire software applications in a weekend, right? And so it's tempting to think, why don't we just apply this same approach to engineering problems? I mean, can't we just open up a coding agent and start prompting and see what it produces? It'll then go look up some data sheets online and then probably ask some clarifying questions along the way and then eventually it'll create something. The problem though with this approach, at least for engineering problems, is that you're skipping the process that makes the result trustworthy and therefore you might not know what you've actually built until something goes wrong. You know, maybe the control loop is running faster than the hardware can reliably execute. Maybe the code doesn't comply with your safety or regulatory requirements. Or maybe it just works most of the time, but you're not sure if it works all of the time. I mean, if the output is wrapped up in a big blob of code that the agent wrote, most of which it might have created from scratch, narrowing down where the problem is can mean a lot of back and forth prompting where you're describing symptoms in natural language and then hoping the agent fixes the right thing.

[00:03:10]not exactly an efficient or a safe approach.

[00:03:14]Therefore, we probably want to approach this problem differently. Instead of asking an agent to solve your problem however it wants, you tell it to follow an engineering workflow that you understand. You direct it to use trusted tools at each step and you reuse tested solutions whenever possible. So in this way, every stage in the process produces artifacts that are inspectable, traceable, and verifiable. And it reduces the amount of custom solutions that the agent has to create. So with all of that being said, let me give you an example of what this can look like in practice. And I'm not going to explain step by step everything involved in getting this inverted pendulum working.

[00:03:52]We have other videos and documents for that that I've linked to below. But I do want to highlight a few aspects of the design that I think emphasize the points I'm trying to make in this video.

[00:04:03]Specifically, those points are to think first before you just start building.

[00:04:08]Have the agent create things that you understand and can inspect. Minimize the amount of design from scratch that the agent is doing by reusing things that have already been verified. And to test the design early and often to catch errors as soon as you can. So, let's get started balancing this pendulum.

[00:04:27]When you start a project, before you just start designing and building things, it's important to slow down and think about what you actually want the system to do. For us, we want the pendulum to spin up and balance. That's the big objective. But we also want to meet certain performance goals as well.

[00:04:43]These are things like how quickly should it spin up? How fast should it settle afterwards? How much wobble can we allow? And then, you know, there's hardware considerations like to not exceed motor commands over 12 volts or that the code has to be able to fit and execute on a Raspberry Pi.

[00:05:01]So, we started our project by giving the agent an overview of what we ultimately wanted to do so that it knew where we were going. But then we directed it to first help us come up with some requirements for the system. And this was a bit of back and forth where we iterated on what we thought was necessary for this particular project and what the parameters should be. And you know the depth of the requirements and the specifications that you choose will depend on your particular project.

[00:05:27]But it is important to start here because if you don't think about exactly what you want in quantifiable and verifiable ways, then you don't know how to direct the agent to help you and you won't know whether it was accomplished in the end. So, just like with traditional specdriven engineering, this is an important first step in the process. And we're going to come back to these requirements later when the agent is verifying that the design works.

[00:05:51]We're using modelbased design for controller development, simulation, and verification, which means that we need a model of the system. Now, instead of just letting the agent create a model however it wants, again, we want to think about what it is creating so that we can understand it and check it and potentially reuse existing models if available. So, for this project, we could ask the agent to produce a Simulink model. And this is great because it addresses both of those issues. The first is the problem of not knowing what it created because here we can just open it up and see how the agent interpreted the physics. we can run it ourselves and if there's an issue we know how to go in and change it. And then the second benefit is that Simulink has lots of verified blocks for any model that you want to create. So for example, instead of the agent building its own integration function, it just uses the one in Simulink. And this means that it doesn't have to use resources and tokens to recreate it from scratch.

[00:06:49]And then you don't have to use resources chasing down potential problems from that recreation.

[00:06:55]Now, it turns out that we don't have to create a model for this project because we already have a Simulink model of the system. So, we just pointed the agent to use it. And since we gave the agent the ability to interact with and modify Simulink models through the Simulink Agentic toolkit, it was able to fully understand and work with the model that we provided. So, for example, the agent needed a linearized version of the model around the balance point in order to later design the controller. And instead of doing that with some linearization technique that it created on the fly, it was able to do that more efficiently by using the linearization tools within Simulink control design. And then the agent came back and helped us interpret the resulting linear model. It explained the four poles in the model and how each of those poles were typical for an inverted pendulum. And this is something that Narin and I were able to verify was correct through our own expertise and understanding of the problem. All right, with a linear model, we now want to develop a controller. And in this case, we asked for a model predictive controller. And once again, I feel like I'm saying the same things over and over again, but here is where it doesn't make sense to have an agent invent an optimizer from scratch, right? I mean we want to create things we understand and we want to minimize how much design from scratch the agent is doing. So instead of a custom optimizer we told the agent to use model predictive control toolbox which contains a deterministic and validated set of algorithms for designing MPC controllers. This way we know exactly which algorithms are being used and we can inspect and tune the parameters. We can manually run a simulation and if something needs to change, we can modify it directly or ask the agent to change it using the same tools. It's actually pretty cool to be able to have this back and forth progress with an agent. It felt like it was helping us execute a process that we understood and had control over rather than creating some magical solution and just hoping for the best.

[00:09:00]Okay, with the controller designed, it's time to start testing. And it's probably not ideal to just start on the physical hardware. That seems a bit dangerous.

[00:09:10]And remember, one nice thing about breaking up the design process into these stages is that we were able to test early and often. We can catch errors at a point in the process where it's still easy to fix them. So, we're going to do this in several steps. The first step is to do model in the loop testing, which is basically simulating the system in Simulink and verifying that the performance requirements are met. That basically means that the controller under the assumption that our model is accurate can actually spin up and balance the pendulum. And once that passed, we moved on to creating the embedded code for the controller and running that in a software in the loop test. And this is where the real embedded C code is running, but it's still running on the development computer. And mostly here, we're checking to make sure that the generated code matches the simulated code to within some required threshold. So, we asked the agent to plot what we got from the simulated run against what we got running the embedded code during the sill test. And it's a bit hard to see here on this graph, but there are actually two different lines plotted here. And it's just that they match so well. You know, they're effectively right on top of each other that it's hard to distinguish between the two. And that's what we want to see. So, now let's talk about how we got this embedded code that perfectly matches our simulation. And it's important to note here that instead of having the agent convert the model or the control software into embedded code on its own however it wants, we're taking advantage of the code generation capabilities within Simulink.

[00:10:40]And the reason this is important is because Simulink generated embedded code from a model using well- tested deterministic workflows. So the same design always produces the same code and every piece of that code can be traced back to the original model and requirements. If you rely on AI to generate code directly, that process is much less structured. The outputs can vary from run to run, and it's often unclear exactly how or why a particular implementation was created, making it harder to trust and verify. So now that we have this deterministic and traceable embedded code, the next step is to move on to processor in the loop testing where the embedded code is deployed to the Raspberry Pi and then that runs in conjunction with a simulated inverted pendulum. And this is where we verified runtime requirements and assessed hardware safety one more time before we actually run it with the real hardware.

[00:11:36]We also asked the agent to show that the system was meeting the requirements along the way. So we were able to see which requirements were verified at each testing stage and how they were reverified as the tests became more representative of the final hardware.

[00:11:53]And having passed these tests, we now instructed the agent to move on to deploying to the hardware and final verification. And I don't want to give you the impression that we just deployed to the hardware and it worked the first time. We kind of assumed that the model that we had previously of the pendulum was accurate and we didn't realize that there were significant differences between the hardware and the model until we got to this stage. And so while the testing and simulation looked great, it didn't do what we were expecting on the hardware. And it required us to go back and with the help of the agent update the model and then cycle back through this process again. And if we were to do this over, I don't think we would have skipped the step of comparing the model to the hardware. But this is precisely the point I'm trying to make here. You don't want to let your AI agent skip parts of your engineering workflow.

[00:12:42]That's how you can get yourself into trouble with a final product that doesn't meet your objective or worse is just purely unsafe. And there's a reason why we design, build, test, and deploy engineered systems the way we do. And so to take advantage of these benefits, you want to use the agent to accelerate your process within your proven workflow, not bypass it. There's still value in thinking about what you want to create before you start creating it. There's still value in creating artifacts along the way that you understand and that don't need to be built from scratch each time. And there is value in a process that allows you to verify the design early and often rather than waiting until the end. And this is how you can get an AI agent to help you be successful in your engineering project.

[00:13:33]So if you take just one thing away from this video, hopefully it's this. Aentic AI is powerful, but for engineering, the value comes from how you use it. When you guide it step by step, have it generate artifacts that you can inspect and modify, have it reuse trusted tools and existing components and follow established workflows, you get the speed and productivity benefits of AI without sacrificing trust, safety, or understanding.

[00:14:03]All right, this is where I'm going to leave this video. And like I said earlier, if you want to know how we set up this project, I've left a link to some resources below that walk you through more of the details of how to connect an agentic tool with mat lab and simulink. And if you enjoyed this explanation, you can find all of the tech talk videos across many different topics nicely organized at mathworks.com. Thanks for watching and I'll see you next