Artificial Intelligence

Developing CT Reconstruction Workflows in MATLAB: From FDK to AI-Based Methods

Johanna Pingel — Thu, 12 Nov 2026 15:38:12 +0000

This post is authored by Sagar Hukkire, Senior Application Engineer at MathWorks, and Visa Suomi, Medical Devices Industry Manager.

Computed tomography (CT) reconstruction transforms raw X-ray projection data into clinically useful cross-sectional and volumetric images. Cone-beam CT (CBCT) is particularly demanding: its wide cone angle and large detector coverage increase sensitivity to scatter, truncation, geometric calibration, and view-sampling effects.

At the same time, engineering teams must balance image quality, acquisition time, radiation dose, and computational cost. A scalable CT reconstruction workflow must therefore support rapid experimentation, hardware acceleration, AI-based enhancement, and a practical path to deployment. This need is growing as detector sizes increase and low-dose and sparse-view acquisitions become more common.

Reconstruction Approaches

Filtered back projection (FBP) with Feldkamp-Davis-Kress (FDK) reconstruction - a fast analytical baseline for circular CBCT acquisitions.
Hybrid Iterative Reconstruction (HIR) – a physics-based refinement approach that improves data consistency and helps suppress artifacts.
Deep Learning with a U-Net – a learned enhancement stage that maps baseline FDK slices toward higher-quality target reconstructions.

This blog presents an end-to-end CT reconstruction pipeline implemented in MATLAB® that combines three complementary approaches. The unified workflow supports GPU acceleration, visualization, validation, CUDA® code generation, and regulated medical-device software development aligned with IEC 62304.

Workflow Overview

The workflow spans data import, preprocessing, reconstruction, visualization, validation, and deployment. It follows the same progression as the related MRI reconstruction series: begin with a reliable analytical baseline, add physics-based refinement, and introduce AI where it provides measurable value.

Why Combine Multiple Reconstruction Approaches?

CT reconstruction requires trade-offs among acquisition speed, radiation dose, image noise, spatial resolution, and artifact suppression. Dense, high-quality scans can improve reconstruction fidelity but may increase dose or acquisition time. Faster or lower-dose scans are attractive in practice, yet their noisier or less complete projection data can make reconstruction more difficult.

Rather than relying on a single “silver bullet” algorithm, this workflow brings several reconstruction strategies into one environment. Engineers can compare methods, understand the trade-offs, and build a practical path from algorithm exploration to deployment.

Establish a reliable baseline: FDK reconstructs a full 3-D volume quickly and provides an interpretable reference point.
Improve difficult scans: HIR keeps the acquisition model in the loop and refines the volume using projection-domain residuals.
Use AI as an enhancement layer: the U-Net learns to reduce residual artifacts and improve slice appearance after physics-based reconstruction.

By unifying these approaches in MATLAB, engineers can prototype quickly, inspect intermediate results, validate image quality, and prepare selected algorithms for GPU execution and CUDA code generation without maintaining disconnected toolchains.

1. Baseline Reconstruction with FDK

We begin with Feldkamp–Davis–Kress (FDK) reconstruction, an analytical baseline for circular CBCT acquisitions. FDK is fast, deterministic, and directly linked to the acquisition geometry. It reconstructs a 3-D volume by applying projection weighting, filtering, and back projection to the measured projection stack.

Dataset and Simulation Setup

For this example, we used the XCIST simulator to generate CBCT projection data. The raw projection dataset is available through MathWorks support files.

% Load projection data and run FDK reconstruction
projectionData = fullfile(dataDir, "CBCT_lowDose_Projections.mat");
volFDK = reconFDK(projectionData, 'Verbose', true);

% Inside reconFDK.m
S = load(inputMat);
P = S.P;
angles_rad = S.angles_rad(:)';
FDKvol = simpleFDK_CBCT_vox(P, angles_rad, DSD, DSO, ...
    [du dv], [dx dy dz], nx, ny, nz, 'ramp', ...
    'u0', u0, 'v0', v0, varargin{:});

How it works. FDK applies geometry-aware weighting and ramp filtering to each projection before back projecting the filtered stack into a 3-D volume. The result is available immediately for review, quality checks, or use as the input to HIR and deep-learning stages.

CBCT reconstruction using FDK

2. Refinement with Hybrid Iterative Reconstruction

Hybrid Iterative Reconstruction (HIR) improves the initial FDK volume by repeatedly comparing simulated projections from the current estimate with the measured projections.

The resulting residual is back projected to update the volume, while regularization stabilizes the reconstruction and suppresses noise.

% Start from the FDK result and refine iteratively
volHIR = reconIR(projectionData, volFDK, 'Verbose', true);

% Core HIR update in reconIR.m
Ax = forwardProject_CBCT(x, angles_rad, DSD, DSO, ...
    [du dv], voxel_size, nu, nv, u0, v0, ...
    'UseGPU', UseGPU, 'NumSamples', numSamples);
res = single(P) - single(Ax);
grad = simpleFDK_CBCT_vox(res, angles_rad, DSD, DSO, ...
    [du dv], voxel_size, nx, ny, nz, 'ramp', ...
    'u0', u0, 'v0', v0, 'UseGPU', UseGPU);
reg = lambda * (x - imgaussfilt3(x, sigG));
x = x + alpha * (grad - reg);

How it works. Each iteration performs four steps: forward projection, residual computation, back projection, and regularization. Keeping measured projection data in the loop is especially valuable for low-dose or sparse-view scans, where analytical reconstruction alone may leave streaks, noise, or structural inconsistencies.

CBCT reconstruction using Hybrid Iterative Reconstruction

3. Deep-Learning Enhancement with U-Net

The third approach uses deep learning to enhance CT slices reconstructed with FDK or HIR. Rather than replacing the physics-based workflow, a U-Net serves as a learned image-to-image enhancement stage. In this example, the network maps FDK-quality slices toward higher-quality targets, such as HIR outputs.

% Train a U-Net that maps FDK slices toward HIR-quality slices
[volDL, net, info] = reconDL(volFDK, volHIR, 'Verbose', true);

% Key training steps in reconDL.m
lgraph = buildUNet(inputSize, BASE_CHANNELS, ENCODER_DEPTH);
options = trainingOptions('adam', ...
    'InitialLearnRate', 3e-4, ...
    'MiniBatchSize', 8, ...
    'MaxEpochs', 60, ...
    'ExecutionEnvironment', char(opt.ExecEnv));
net = trainNetwork(dsTrainPrep, lgraph, options);
yPredVol(:,:,k) = tiledPredict2D(net, sliceN, tile, overlap);

How it works. The workflow prepares paired reconstructed slices, normalizes the data, creates training and validation partitions, trains a 2-D U-Net, and applies tiled prediction to larger slices. Used as an enhancement layer, the network can focus on residual artifacts and subtle quality improvements instead of learning the complete CT reconstruction problem from scratch.

CBCT reconstruction enhanced using U-Net (brightness in pixel value due to contrast stretching).

Verification, Validation, and Deployment

Reconstruction algorithms are only one part of a practical CT workflow. Engineering teams also need visualization, verification, validation, performance benchmarking, and a route to deployment. Because all three reconstruction stages are implemented in MATLAB, the same environment can support both exploratory development and production-oriented engineering.

For a 600 × 600 × 360 projection example running on an NVIDIA® Tesla T4 GPU, acceleration substantially reduced reconstruction time:

Reconstruction Method	Before Optimization (s)	After Optimization (s)	Time reduction (%)
FDK-based CUDA Reconstruction	~400	~7	~98.3%
Hybrid Iterative Reconstruction	731 (per iteration)	~27	~96.3%

These results demonstrate that GPU acceleration and code generation are core parts of the workflow, not optional add-ons. The broader engineering workflow includes:

Automatic testing and verification: modular functions make it easier to add smoke tests, regression checks, and quantitative comparisons across reconstruction stages.
Interactive visualization and validation: reconstructed volumes can be inspected with Medical Imaging Toolbox using slice-based and volume-based views.
Parallel, GPU-aware execution: Accelerated MEX functions and CUDA-capable hardware make realistic 3-D reconstruction experiments more practical.

CUDA code generation and deployment. MATLAB Coder and GPU Coder can generate accelerated MEX functions or deployment-oriented CUDA code from selected reconstruction entry points, with support for IEC 62304-oriented development workflows.

% Generate a CUDA MEX for the FDK entry point
cfg = coder.gpuConfig('mex');
cfg.GenerateReport = true;
inputs = {P, angles_rad, DSD, DSO, du, dv, u0, v0, ...
    dx, dy, dz, padFactor};
codegen -config cfg -args inputs reconFDK_codegen

GPU acceleration and code generation allow CT reconstruction methods developed in MATLAB to scale from desktop prototypes to specialized hardware. This helps bridge algorithm research, AI experimentation, and integration into production-oriented medical imaging systems.

Conclusion and Key Takeaways

Combining analytical, iterative, and AI-based reconstruction in one MATLAB workflow addresses the varied requirements of modern CT systems. A unified environment streamlines raw-data import, reconstruction, testing, visualization, validation, GPU acceleration, and code generation.

The main takeaways are:

FDK reconstruction provides a fast and interpretable baseline for CBCT data.
Hybrid iterative reconstruction improves fidelity by combining forward projection, residual correction, back projection, and regularization.
Deep learning can enhance reconstruction quality when trained and validated with representative target data.
GPU acceleration and CUDA code generation help bridge the gap between research prototypes and deployable reconstruction pipelines, with the example workflow showing about 57× speedup for FDK and about 27× speedup per iteration for HIR on an NVIDIA® Tesla T4 GPU.

Together, FDK, HIR, and U-Net enhancement create a flexible workflow in which classical reconstruction and AI reinforce each other. Engineers can iterate quickly, compare trade-offs clearly, and tailor CT reconstruction pipelines for both image quality and deployment readiness.

Try the Examples

CT Reconstruction in MATLAB

Engineering Embedded AI with MATLAB Agentic Toolkit

Johanna Pingel — Tue, 03 Nov 2026 20:42:54 +0000

Guest blogger: Arkadiy Turevskiy

Arkadiy is the product manager for AI and controls products at MathWorks. He has been with MathWorks for more than 20 years. Before joining MathWorks, he designed aircraft engine control systems at Pratt & Whitney.

Developing an embedded AI application involves preparing data, training a network, reducing its memory requirements, and verifying the generated code. These steps require engineering judgment about accuracy, resource constraints, and implementation behavior. I wanted to explore how a coding agent could help carry out this workflow using reusable engineering guidance, while keeping me involved in the decisions.

My test case was a battery state-of-charge estimator intended for an Arm Cortex-M7 processor. The objective was to minimize storage for the network’s weights and biases while allowing no more than a 5% increase in root mean squared error (RMSE) relative to the uncompressed network.

I asked a coding agent to use the matlab-deploy-embedded-ai skill in MATLAB Agentic Toolkit with battery data from the state-of-charge estimation example. The objective was to train a deep learning virtual sensor in MATLAB®, integrate it into Simulink®, and generate C code for deployment. The sensor estimates battery state of charge from temperature, voltage, and current measurements.

Package Best Practices with the Code

Large language models train on vast amounts of source code, so a coding agent can quickly write a deep learning training script. Engineering practice is harder to learn from public data. It lives in an organization’s standards, project reviews, and experience.

That knowledge may live in an engineer’s head, but putting it into every prompt is impractical. A skill file makes the guidance reusable.

A skill packages best practices as readable, versioned markdown that engineers can inspect. The agent usually invokes a relevant skill from your prompt, but in my experience, it occasionally failed. To make sure, name it explicitly. In Codex, type $matlab-deploy-embedded-ai or tell the agent to use matlab-deploy-embedded-ai.

The Embedded AI skill gives the agent a workflow to follow, including recommended functions, verification steps, and review checkpoints. For example, the skill directs the agent to train the neural network with trainnet, then open the trained network in Deep Network Designer for my review. The next step is model compression: reducing the storage required for the network’s weights and biases while evaluating the effect on prediction accuracy. The skill also calls for numerical comparisons between the approved network in MATLAB, its Simulink implementation, and generated code. At each checkpoint, the agent saves a script and presents results for my review before continuing. MATLAB Agentic Toolkit and Simulink Agentic Toolkit connected the agent to a live MATLAB session for running scripts, simulating models, and reporting results.

Reviewing each step let me correct a wrong turn before it propagated.

Let Requirements Choose the Model

The battery data spanned −10, 0, 10, and 25 °C. I followed the data preparation procedure in the MATLAB state-of-charge estimation example, dividing the data into 500-step sequences and using a 70/30 training–validation split. This produced 201 training and 87 validation sequences. The example’s separate test data yielded 288 test sequences. The baseline network had 463,489 learnable parameters and achieved an RMSE of 0.034258 on the independent test set.

Figure 1: The agent opened the trained battery state-of-charge network in Deep Network Designer for review before compression.

After training, I wanted to compress the model for a resource-constrained microcontroller. I used a Pareto frontier to compare accuracy and parameter storage. Projection and quantization can reduce parameter storage, alone or together, with different accuracy tradeoffs.

Compression methods need to suit the network architecture. For this network, I compared projection, which reduces the number of parameters in its long short-term memory (LSTM) layers, and quantization, which uses lower-precision numbers. I evaluated the methods separately and together.

I allowed no more than a 5% increase in RMSE relative to the uncompressed model. The agent calibrated the quantized candidates on all 201 training sequences and evaluated the three compressed candidates on the same 32 held-out sequences. Using a common comparison set kept a change in data from looking like a change in model performance.

Here, parameter storage means the memory that estimateNetworkMetrics reports for learnable weights and biases. It is a proxy for flash or ROM and excludes generated code, network states, activations, and runtime SRAM.

Candidate	Parameter storage	RMSE change	5% budget
Uncompressed: Baseline float32	1.768 MB	Baseline	Pass
Projected float32	0.0464 MB	+1.64%	Pass
Quantized baseline	0.4464 MB	−3.94%	Pass
Projected and quantized	0.0160 MB	−0.62%	Pass

Table 1: Measured results on the same 32-sequence comparison set. RMSE change is relative to the baseline on that set; negative values indicate lower RMSE.

Figure 2: The measured Pareto frontier for the four candidates.

At 0.0160 MB, the projected and quantized model cut parameter storage by 99.10% versus float32. Its RMSE was 0.62% lower on the 32-sequence comparison set and 8.69% lower on the full validation set. I selected it as the smallest candidate within the limit.

Agent: The projected and quantized model is the smallest within the 5% RMSE budget. Its RMSE is also 0.62% below baseline on the comparison set. Next comes Simulink integration and numerical equivalence testing. Shall I proceed?

Engineer: Yes, but first explain how the quantized model could have lower RMSE.

Agent: Quantization rounds values to the nearest value representable at lower precision. On this dataset, those changes happened to move predictions closer to the targets. The result is specific to this model and data; quantization does not generally reduce RMSE.

Engineer: Ok, proceed.

Agent: The Simulink equivalence test passed. The next step is code generation and software-in-the-loop testing. Shall I proceed?

Engineer: Go ahead.

Separate Compression Effects from Implementation Drift

Compression changes a model, so its acceptance test measures application performance on held-out data. That is the RMSE comparison above. Implementation testing asks a different question: Does the approved model produce equivalent numerical results as it moves from MATLAB to Simulink and generated code?

I had the agent run one 500-step sequence at each temperature, producing 2,000 outputs for each implementation. The quantized network in MATLAB, normal Simulink simulation, and software-in-the-loop (SIL) simulation produced bit-identical outputs on those test vectors. MAE, RMSE, and maximum error were all exactly zero. Those zeros measure implementation drift, not prediction error against the measured state of charge.

C code generation completed with an Arm Cortex-M configuration, and the generated source used fixed-width integer types. The quantized workflow reported a fixed-point saturation warning in the second LSTM layer. The implementations still showed no drift in this test, and any effect on model quality was already reflected in the held-out RMSE. The warning warrants broader testing. Without a development board or cross-compiler, flash use, SRAM use, and execution time remain unmeasured. The agent stopped its claims at that boundary.

Let Proven Tools Produce the Evidence

You may reasonably ask whether the agent invented those metrics. It did not estimate them. The agent orchestrated the workflow; MATLAB, Simulink, code generation, and verification produced the evidence. I set requirements, reviewed tradeoffs, and approved important decisions.

The skill tells the agent to compute metrics from current variables and avoid hard-coded results. The LLM remains nondeterministic and unqualified. With the network, test data, and configuration fixed, code generation and test execution follow repeatable procedures. In qualified workflows, qualification belongs to the specific tools, process, and project evidence. It never extends to the coding agent.

Make the Workflow Reusable

My earlier post introduced an early version of this skill in the MATLAB Agent Skills Playground. Since then, broader testing with coding agents such as Claude and Codex has shown that the skill helps agents complete user objectives and select recommended MATLAB functions and capabilities more consistently. The skill is now available in MATLAB Agentic Toolkit.

Because skills are text files, teams can review them, place them under version control, and adapt them with their own budgets, tests, reports, and approval gates. Try the Embedded AI skill with a real deployment objective: inspect the scripts, challenge the model choice, and trace the measurements. A useful engineering agent should make expert practice easier to apply while leaving the evidence and final decisions where they belong.

© 2026 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.

Teaching AI Agents How Engineers Work

Johanna Pingel — Tue, 27 Oct 2026 13:12:04 +0000

Guest blogger: Akash Gopisetty

I'm pleased to welcome guest blogger Akash Gopisetty, Product Marketing Manager, Radar and Signal Processing. Akash explores how reusable skills help AI agents follow established engineering methods.

Connecting AI agents to engineering tools gives them the ability to write code, execute workflows and evaluate results, all within an established engineering environment. This ensures the results are inspectable, testable and verifiable.

Figure 1: Grounding AI in engineering tools

However, access to engineering tools alone does not provide the agent with the domain expertise needed to solve specialized engineering problems. That is where skills come in.

Skills are a way to capture how an experienced engineer would approach a problem. They are especially useful in technical domains like wireless communication, signal processing, and RF and antenna design, where there may be multiple valid approaches and the right choice depends on domain-specific assumptions, selecting the right methods and engineering tradeoffs. For example, an RF or antenna engineer may need to translate requirements for frequency, gain, coverage and polarization into various antenna and array architecture. They may also need to factor in impedance matching, mutual coupling and array effects and evaluate whether the resulting design meets the system-level performance requirements. Skills could be used to capture this reasoning and guide the agent through a workflow, allowing the engineer to focus on reviewing the design choices and exercising judgement over the final design.

Instead of asking an agent to discover or guess the right procedure at each prompt, engineers can codify proven methods into skills, version them like any other artifact and reuse them across relevant workflows and across compatible AI agents.

Skills are especially valuable when workflows require:

Domain knowledge: The assumptions, calculations, tool choices, and validation steps that define a sound approach to tasks such as digital filter design, standards-based wireless waveform generation, model calibration, or test development.
Consistency and traceability: A repeatable workflow whose instructions can be reviewed, tested, audited, and improved like any other engineering artifact.
Reusability: A portable way to apply the same engineering process across projects, teams, and compatible AI agents without rebuilding the guidance from scratch.

Using Agentic AI Skills with MATLAB:

AI Agents can be connected to MATLAB using MATLAB Agentic Toolkit. With the guardrails of MATLAB engineers can produce verifiable results with AI Agents. For technical domains like radar, communications, RF and mixed signal design the toolkit also includes a catalog of reusable skills.

Figure 2: Connect AI Agents to MATLAB

You don't need to choose individual skills for each task. Install the skill groups relevant to your work, and the agent can identify and apply appropriate skills based on your request.

Skill Group	Example Workflows
Radar	Design and analyze radar waveforms Design radar systems in Radar Designer Simulate radar detections
Reporting and Database Access	Generate MATLAB and Simulink reports Read and write relational databases Connect MATLAB to Databricks
RF and Mixed Signal	Design antennas and arrays Model and simulate RF systems Model PLL frequency synthesizers
Robotics and Autonomous Systems	Build robot manipulator models Plan robot motion and trajectories Fuse inertial sensor measurements
Signal Processing	Design and validate digital filters Analyze signal spectra Analyze time-frequency content
Test and Measurement	Connect to cameras and acquire images Connect to OPC UA servers and browse nodes Set up CAN and CAN FD communication
Wireless Communications	Generate 5G NR waveforms Generate IEEE 802.11 waveforms Transmit and capture RF waveforms with USRP radios

Table 1: Selected MATLAB Agentic Toolkit skill groups and example workflows

Applying Skills to a Real-World Design Challenge:

Let’s put these skills to the test. Consider a wireless system that uses the same infrastructure and spectrum for both communication and radar sensing. Commonly referred to as Integrated Sensing and Communication (ISAC), this approach enables a system to exchange data while also detecting and locating objects in its coverage area. ISAC is becoming increasingly important as wireless spectrum grows more congested.

In this example, an ISAC base station operates at 28 GHz and must sense targets within its coverage area while communicating in spectrum shared with a neighboring system. The sensing waveform must provide the required range resolution, maintain low range sidelobes, and minimize transmitted energy within the portion of the band occupied by the neighboring system.

The ask. The agent was given a single prompt (below) describing the system goals, while specific functions and preferred design methods were intentionally omitted. The agent was asked to formulate a plan before implementing any code. The skills included in the MATLAB Agentic Toolkit should help the agent select the appropriate tools and workflow.

I'm working on an ISAC system. A 28 GHz base station panel needs to sense targets in its coverage area while a neighboring operator uses part of the band. Design a pulsed sensing waveform in MATLAB that gives me 2 m range resolution, keeps range sidelobes below 40 dB, and puts as little energy as possible into the 100 MHz slice at the center of my sweep where the other system operates. Explain your approach before writing any code.

Here Open AI Codex identifies and applies the relevant MATLAB and radar-waveform-design skills. These skills do not contain a fixed answer to the problem. Instead, they provide the engineering process the agent should follow, including how to translate requirements into waveform parameters, evaluate design tradeoffs, and generate evidence that the final design meets its objectives.

Figure 3: AI Agent identified a relevant skill to apply

Figure 4: Proposed plan from the AI Agent that uses MATLAB functions and System objects

Added a few more system requirements to characterize the targets:

Targets move up to 30 m/s. Maximum range of interest is 600 m.

Figure 5: Additional system requirements

Figure 6: AI Agent writes, runs and tests a MATLAB script

Figure 7: Resultant MATLAB Plots - I/Q data, spectrum, pulse compression response and Doppler tolerance

The results. The four panels show that the waveform produced indeed meets all the stated requirements, so the agent was able to use the skill to create and run MATLAB code. The transmit spectrum shows the protected 100 MHz slice suppressed by more than 50 dB to avoid interference with the neighboring system. The pulse compression response puts the main lobe inside the 2 m range resolution requirement with peak sidelobes near 55 dB down, 15 dB better than what was required. The Doppler curve shows negligible loss of a few kHz at 30 m/s.

What the skill changed. Rather than leaving the AI agent to determine the process from scratch, the skill provided reliable, constraint-aware engineering guidance. It directed the agent to derive waveform parameters from the system requirements, select an appropriate spectral-shaping method, and verify the resulting design against resolution, sidelobe, and Doppler constraints. This produced a more repeatable and verifiable result without requiring the engineer to specify every design and validation step in the prompt. A two-attempt debugging limit also prevents the agent from entering unproductive loops and returns unresolved issues to the engineer for review and decision-making.

Teaching agents how engineers work

This points to a more effective way for engineers to work with AI. Instead of encoding an entire procedure in every prompt, engineers can focus on requirements, constraints, and design decisions. Skills supply reusable engineering methods, agents carry out the workflow, and engineers review the evidence and make the final call.

Jump into Test Authoring Straight from Requirements Using an AI Agent

Johanna Pingel — Tue, 13 Oct 2026 14:53:38 +0000

Guest writer: Pat Canny

Pat Canny is a Principal Technologist at MathWorks specializing in safety-critical systems development, Model-Based Design, and digital engineering workflows for aerospace and defense.

Authoring test cases is a tedious process. Authoring good, requirements-based, systematic test cases is… well it’s not always fun. When I created test cases to test my colleague’s designs in Simulink, the day-to-day requirements work often looked something like this:

This reflects what day-to-day requirements work can feel like.

This is a time-consuming workflow, and I haven’t even talked about test coverage!

This is an ideal use case for Agentic AI because an Agent can help “automate the boring stuff” and allow me, an engineer with domain expertise, to focus on authoring the best requirements-based test case possible while minimizing the context-switching between a text-based requirement and a Simulink model.

To do this, I created a set of skill files in Codex which:

Analyzes a text-based requirement which follows EARS (Easy Approach to Requirements Syntax), a popular, structured methodology for writing requirements
Creates a human-reviewable “mapping” between “symbols” in the requirements text (e.g., “Enter Communications Mode”) and the Simulink model
Generates a test harness for the Simulink model with a draft test sequence as a source

A Short Demo

Here is what it looks like in action.

Demo of generating a draft Simulink Test sequence from requirements.

What’s Inside

A set of skill files used for MATLAB and Simulink workflows typically includes a SKILL.md and a suite of MATLAB utility functions (*.m files). The SKILL.md defines the specialized workflow, instructions, and guardrails the agent should apply to a particular class of tasks. The MATLAB utility functions are invoked by the agent to perform specific, repeatable computations.

For this use case, I created a SKILL.md and a suite of MATLAB utility functions specifically tailored for analyzing text-based requirements, creating a “mapping” between the text and the Simulink model under test, and for creating a test sequence within a test harness (available on GitHub).

The SKILL.md includes a brief name and a description:

---
name: simulink-test-sequence-from-EARS
description: Generate Simulink Test Sequences from EARS-compliant requirements. Use when creating test cases from EARS requirements, generating Test Sequence blocks from .slreqx files, or testing Simulink models against text-based requirements.
---

The SKILL.md also includes sections that describe:

Goal: What the skill is intended to accomplish.
Supported “EARS” patterns: Which requirement formats the skill can process.
Inputs Required: What files and context the agent needs.
Triggering phrases: Example prompts that invoke the skill.
Setup: Dependencies and project configuration.
Workflow: The steps the agent follows.

The workflow is broken up into two phases. I’ll use a simple example to explain.

Let’s say I have requirements for a quadcopter’s flight mode logic. These requirements follow the “EARS” syntax. Here’s a snippet of the “Establish Communications Mode” requirements from Requirements Toolbox:

Requirements Toolbox snippet of the “Establish Communications Mode” requirements.

I want to write a set of requirements-based tests against this Stateflow state chart:

Stateflow state chart for the quadcopter flight mode logic.

A quick note on what I mean by “requirements-based tests.” This type of testing ensures the intent of the requirement (the expected behavior) is being met by the design. For this specific example, I want to ensure that the quadcopter is commanded to enter the correct mode based on the conditions.

Requirements-based testing differs from workflows like “robustness testing,” which is when I’d try to deliberately “break” the design by injecting faults, attacks, or anything along those lines which go beyond just the “if this, then that” type of test cases. Requirements-based tests are the “first line of defense” and can also help ensure you have the right set of requirements to begin with before diving into robustness testing.

OK, back to the workflow!

Phase 1 starts by reading requirements from a Requirements Set (*.slreqx file), then inspecting the Simulink model before creating a .yaml file containing the “mapping” of text elements for each requirement to an element in the Simulink model. For example, the term “Establish Communication” corresponds to the “WaitForComms” state in the Simulink model’s Stateflow state chart. I need to approve this “mapping” artifact (.yaml file) before the agent can proceed.

Mapping artifact connecting requirements text to Simulink model elements.

Phase 2 begins once I approve the “mapping” between the requirements text and the Simulink model elements. The mapping is used to generate a test harness using Simulink Test, which isolates the Simulink model for testing, as well as a corresponding draft Test Sequence, which is a stepwise test source. The Test Sequence is then opened for me to inspect and modify.

Generated Simulink Test harness and draft Test Sequence.

Why This Matters

AI agents, like any tool, have their strengths and weaknesses. One of their strengths is their ability to translate between different levels of abstraction, such as a text-based requirement and a Simulink model. But AI agents are not trained in every engineering domain, which is where you come in. Skill files allow you to leverage the strengths of AI agents while validating the agent’s outputs along the way through human-readable artifacts.

Try It Yourself

You will need MATLAB R2023a or newer with Simulink, Stateflow, Requirements Toolbox, and Simulink Test installed. You will also need the skill files (available here) and Simulink Agentic Toolkit installed. Simulink Agentic Toolkit includes MATLAB MCP Server, which is required for Agentic AI workflows with Simulink. I tested the skill files using Codex, but the setup should be straightforward to port to other coding agents.

Drop the skill folder into your project’s /skills/ directory, start the agent, and invoke the Skill using a phrase like “create test cases for the requirements in mode_logic.slreqx”.

We’re always looking for insights into your challenges in testing your Simulink designs, so please leave a comment below!

From Differential Equations to Data: Exploring Inverse Problems with PINNLab

Johanna Pingel — Tue, 15 Sep 2026 14:07:50 +0000

Guest writers: Mohan Parthasarathy and Padmanabhan Seshaiyer, PhD

Mohan Parthasarathy is a student at Thomas Jefferson High School for Science and Technology. Padmanabhan Seshaiyer, PhD, is Professor of Mathematics at George Mason University.

In this blog post, we discuss PINNLab, an interactive MATLAB application for exploring parameter estimation in differential equation models using physics-informed neural networks (PINNs).

The Inverse Problem

Many scientific and engineering problems require working backward from limited observations to understand the system that produced them. Suppose you know the equations governing a population, an epidemic, or a chemical process, but not the growth rate, transmission rate, or reaction constant. Given a small collection of noisy measurements, how can you recover those missing parameters?

This is an inverse problem: working backward from observations to infer the parameters that produced them. We built PINNLab to make that process interactive. Users choose a model, provide observations, train a physics-informed neural network, and examine whether it recovers both the system trajectory and its hidden parameters.

Figure 1. The PINNLab interface for configuring and solving inverse problems.

What Makes a PINN Different?

A standard neural network learns by fitting observed data. A physics-informed neural network, or PINN, learns from both the data and the governing equations describing the system.

For an ODE, the network approximates the system state x(t), while automatic differentiation provides its derivative. Training balances data fit, the differential equation residual, and the initial conditions, while estimating the unknown parameters θ.

Figure 2. How a PINN combines data and governing equations during training.

This does not mean PINNs replace numerical methods. Conventional optimization may be faster for small, well-identified models. PINNs become especially interesting when data are sparse, some states are hidden, or states and parameters must be reconstructed together. PINNLab helps users explore that tradeoff rather than assume the PINN will always win.

Why We Built PINNLab

Most differential equations courses focus on forward problems: you are given the equation and parameters, and your job is to solve for the state.

Research rarely works that way. More often, you have the equations and data, but the parameters are exactly what you are trying to discover. That drew us to inverse problems and, eventually, PINNs.

As we experimented, we kept rebuilding the same pieces: physics residuals, custom training loops, trajectory plots, and parameter comparisons. Many examples we encountered were research-oriented Python implementations: useful for reproducing results, but not designed for students to change assumptions and see why the model behaved as it did. Eventually we realized something had changed. We were not just building models anymore; we were building a learning environment, one we found equally useful for rapidly prototyping and testing inverse problem workflows during research.

PINNLab grew from the questions that kept coming up: Where does the network get its information? What happens when data become sparse? When does the differential equation help? MATLAB gave us a natural way to bring those questions into one place. Deep Learning Toolbox handles automatic differentiation and custom training, while App Designer puts the mathematics, controls, and visual feedback into an interactive app.

Learning by Building the Model

PINNLab follows the 5E instructional framework: Engage, Explore, Explain, Elaborate, and Evaluate. Learners begin with a scientific question, experiment with a simpler system, and gradually build the mathematics needed to address it.

We also drew on the U.S. Department of Labor's AI Literacy Framework, which emphasizes understanding what AI can and cannot do, evaluating its outputs, and keeping human judgment central. In PINNLab, learners do more than click Train: they are encouraged to experiment. What happens if you remove half the observations? What if you estimate six parameters instead of two? What if the governing equation is slightly wrong? PINNLab lets users change those assumptions and immediately see how the trajectories, residuals, and parameter estimates respond. The goal is not simply a low loss, but an understanding of why the model succeeded or failed.

In that sense, PINNLab becomes more than a PINN implementation. It is a place to see how inverse problems behave, making machine learning more accessible and helping users develop the judgment needed to apply AI responsibly in scientific work.

Estimating Predator-Prey Parameters

PINNLab's current curriculum follows an ecological storyline centered on Canadian snowshoe hares and lynx. Open the app, choose the Lotka-Volterra predator-prey model, select which parameters the network should learn, and import or generate observations. When you click Train, the PINN reconstructs both populations while estimating the ecological parameters.

Figure 3. Exploring parameter estimation by changing observations and retraining the PINN.

During training, the network weights and ecological parameters are optimized simultaneously. Once training finishes, PINNLab reports the recovered parameter values alongside their initial guesses and, when the true values are known, their relative errors. The curriculum then introduces logistic prey growth and a Holling Type II functional response, creating a six-parameter inverse problem.

The table below shows one result for the Holling Type II model.

Parameter	True Value	Initial Guess	Estimated Value	Relative Error (%)
α	1.0000	0.9000	0.9471	5.29
K (carrying capacity)	50.0000	45.0000	50.8846	1.77
β	2.2000	2.0000	2.5492	15.87
c (half-saturation constant)	8.0000	9.0000	7.0448	11.94
γ	0.7000	0.6000	0.7899	12.84
δ	0.9000	0.8000	0.8040	10.67

Table 1. Recovered parameter estimates for the logistic-growth Holling Type II predator-prey model.

The estimates recover the overall parameter scale, although some parameters are identified more accurately than others. Differences like these help learners see that parameter recovery depends not only on training performance, but also on how strongly each parameter is identified by the available observations.

The six-parameter inverse problem raises a natural question: How many parameters can a PINN estimate at once? There is no universal answer. It depends on the information in the data, parameter identifiability, and model quality. In several PINNLab experiments, we were able to estimate as many as eight unknown parameters, although accuracy depended heavily on the model and data. But as the number increased, the problem quickly became one of identifiability, not just computation. That is exactly what we want learners to discover.

Finally, learners upload historical Hudson's Bay Company hare-lynx records and compare competing models against real data.

Figure 4. Comparing competing predator-prey models using historical hare-lynx observations.

What Surprised Us

Before building PINNLab, we assumed that if a network reproduced the observed data, it must also have learned the correct parameters. Inverse problems taught us otherwise: an accurate-looking trajectory does not guarantee accurate parameters.

A network may fit the observations while compensating for an incorrect parameter elsewhere in the model. Conversely, a physics residual that refuses to converge may reveal that the governing equation itself is inconsistent with the data.

That is not necessarily an algorithmic failure. It may be evidence that the model needs to change.

This distinction between fitting data and validating a scientific explanation became one of PINNLab's most valuable teaching features.

Where We're Taking PINNLab Next

Once PINNLab worked well for ecology, the next question was: Where else can this idea go? We are now expanding the platform toward disease dynamics, contaminant transport, hemodynamics, and pharmacological modeling. We are also interested in exploring how PINNs fit within the broader modeling ecosystem, including established parameter-estimation workflows such as those available in SimBiology.

We are in the process of adding guided modules, stronger diagnostics, and support for more complex parameters. Our goal is not to make every problem look like a PINN problem, but to help users recognize when physics-informed learning adds value.

Try PINNLab

We built PINNLab because inverse problems deserve the same kind of interactive learning environments that already exist for solving differential equations. Physics-informed neural networks can combine mathematical models with observational data, but understanding when they work is just as important as knowing how to run them.

We hope PINNLab gives you a place not only to train a PINN, but to ask the more important questions: What did the network actually learn? Why should you trust it? And what does the governing equation contribute that the data alone cannot?

Let us know in the comments what kinds of inverse problems you'd most like to explore with PINNLab. Check out the open-source PINNLab code and examples on GitHub and read our accompanying CODEE Journal article.

Developing MRI Reconstruction Workflows in MATLAB: From k-Space to AI-Based Methods

Johanna Pingel — Thu, 06 Aug 2026 14:25:08 +0000

The following post is from Sagar Hukkire, Senior Application Engineer at MathWorks, and Visa Suomi, Medical Devices Industry Manager.

Magnetic Resonance Imaging (MRI) reconstruction plays a critical role in transforming raw scanner data (in the frequency domain, known as k-space) into clinically usable images. In the examples shown here, we use low-SNR input k-space data from a T1-weighted MRI modality, which makes robust reconstruction especially important.

Building a scalable, flexible MRI reconstruction workflow that supports experimentation, acceleration, and deployment is a challenging but increasingly important task as MRI datasets continue to grow in size, advanced reconstruction methods such as compressed sensing and deep learning become more prevalent, and the demand for faster, higher-quality imaging in both research and clinical environments continues to increase.

In this blog post, we present an end-to-end MRI reconstruction pipeline implemented in MATLAB® that combines classical physics-based techniques with modern AI methods. The workflow integrates three complementary approaches:

Inverse FFT (IFFT) – a baseline reconstruction using the inverse fast Fourier transform on fully sampled data.
Compressed Sensing (CS) with wavelets – an accelerated reconstruction using undersampled data and sparse-signal recovery.
Deep Learning with a U-Net – a data-driven reconstruction that learns to restore high-quality images from undersampled data.

These techniques are realized in MATLAB and support GPU acceleration, enabling rapid prototyping and easy transition to deployment via automated code generation with IEC 62304 certification support. By blending tried-and-true signal processing methods with AI-based approaches, we can achieve high-quality MRI images with shorter scan times and maintain a smooth path from R&D to production.

MRI k-space in a nutshell – an MRI scanner uses controlled RF & gradient pulses to fill k-space (frequency data). The inverse 2D FFT then produces the final image. Efficient reconstruction must balance scan time, image quality, and compute cost.

Why Combine Multiple Reconstruction Approaches?

MRI reconstruction involves trade-offs between acquisition speed, image resolution, and artifact suppression. Traditionally, collecting a fully sampled k-space grid and applying an IFFT yields a high-quality image with minimal aliasing. However, fully sampling k-space is time-consuming, which can prolong scan durations for patients and reduce scanner throughput in busy clinical environments. Modern methods speed up scans by undersampling k-space, but a basic IFFT of undersampled data produces artifacts such as aliasing and blurring that can limit diagnostic quality. More advanced computational techniques are therefore needed to reconstruct images from incomplete data.

Instead of betting on a single “silver bullet” algorithm, our MATLAB workflow incorporates multiple reconstruction strategies in one environment. This approach lets you:

Establish a reliable baseline: The IFFT method provides ground-truth reconstruction on full data. We use it to validate our pipeline and as a quality benchmark.
Explore accelerated acquisitions: Compressed sensing (CS) allows scanning with fewer k-space samples and reconstructs images by leveraging sparsity – cutting scan time significantly at the cost of computational effort.
Leverage AI for improvements: Deep learning with a U-Net network architecture can further enhance reconstruction quality or speed by learning from data, reducing residual artifacts and possibly enabling even faster acquisitions without sacrificing image fidelity.

By unifying all three methods in MATLAB, you get the flexibility to switch or combine approaches as needed. For example, you might start from the IFFT baseline and then compare it to a CS reconstruction or use a deep network to refine a physics-based output. And because these solutions share a common environment, it’s straightforward to integrate them with common tasks like visualization, image post-processing, and deployment.

Baseline Reconstruction with Inverse FFT (IFFT)

We begin with the simplest case: fully sampled k-space data. If all required frequency samples have been acquired, reconstructing an image is as direct as performing a 2D inverse Fourier transform. In MATLAB, we can do this with a few lines of code (including coil combination if multiple receiver coils are used):

% Read complex k-space data from HDF5 file
kspaceData = h5read(filePath, datasetPath);

% Move the zero-frequency component from the center to the corners
% (undo the scanner/vendor-specific k-space centering)
kspaceShifted = ifftshift(ifftshift(kspaceData, 1), 2);

% Construct a complex-valued k-space matrix from real and imaginary parts
kspace = complex(kspaceShifted.r, kspaceShifted.i);

% Perform 2-D inverse Fourier transform to reconstruct coil images
imageC = ifft2(double(kspace));

% Shift reconstructed images so that the image center appears in the middle
imageC = fftshift(fftshift(imageC, 1), 2);

% Combine multiple receiver coils using Root-Sum-of-Squares (RSS)
% Coil dimension is assumed to be the 3rd dimension
reconImage = sqrt(sum(abs(imageC).^2, 3));

% Remove singleton dimensions to obtain the final image matrix
reconImage = squeeze(reconImage);
imshow(abs(gather(reconImage)), []);              % display magnitude image

This baseline IFFT reconstruction is fast, deterministic, and rooted in the physics of MRI. With fully sampled data, it produces a high-quality image that can serve as our reference. However, the need to capture all of k-space means long scan times in practice. Next, we look at how to get good images faster by collecting less data and using smarter reconstruction algorithms.

Compressed Sensing: Faster Scans with Sparse Reconstruction

Compressed Sensing (CS) is a technique that enables accurate reconstructions from significantly fewer samples by exploiting sparsity in some transform domain. For MRI, a common approach is to assume the image has a sparse representation in the wavelet domain. By undersampling k-space (skipping many phase-encode lines), we speed up acquisition; then, an iterative algorithm recovers the image by enforcing wavelet sparsity and consistency with the measured data.

In our workflow’s CS example, we simulate an undersampled acquisition (e.g., retaining 25% of the original k-space points in a variable-density random pattern). The reconstruction uses an iterative refine-and-threshold algorithm:

% Initialize storage for compressed sensing reconstructions
im_cs = zeros(size(kspace_data));

% Reconstruct each coil and frame independently
for frame = 1:num_frames
    for coil = 1:num_coils

        % Apply undersampling mask in k-space
        undersampled_data = kspace_data(:,:,coil,frame) .* mask_vardens;

        % Initial image reconstruction from undersampled data
        im_cs(:,:,coil,frame) = ifft2s(undersampled_data);

        % Apply coil sensitivity map
        im_cs(:,:,coil,frame) = ...
            im_cs(:,:,coil,frame) .* coilSensitivityMaps(:,:,coil,frame);

        % POCS-based compressed sensing reconstruction
        for iter = 1:num_iters

            % Transform to wavelet domain and enforce sparsity
            [C, S] = wavedec2(im_cs(:,:,coil,frame), 2, 'db1');
            C_thresh = wthresh(C, 's', threshold);
            im_cs(:,:,coil,frame) = waverec2(C_thresh, S, 'db1');

            % Enforce k-space data consistency
            kspace_estimate = fft2s(im_cs(:,:,coil,frame));
            kspace_estimate(mask_vardens) = ...
                undersampled_data(mask_vardens);

            % Update image estimate
            im_cs(:,:,coil,frame) = ifft2s(kspace_estimate);
        end
    end
end

% Combine all coils using Root-Sum-of-Squares (RSS)
rss_CSimage = sqrt(sum(abs(im_cs).^2, 3));

% Remove singleton dimensions
rss_CSimage = squeeze(rss_CSimage);

How it works: The loop alternates between enforcing measured data (swapping in the acquired k-space lines each iteration) and enforcing image sparsity (zeroing out small wavelet coefficients). Over iterations, the image converges as missing information is filled in by the constraints. The result is a high-quality image reconstructed from a fraction of the data.

If we directly applied an IFFT to undersampled data, we would see strong artifacts due to violation of the Nyquist sampling criterion. With compressed sensing, many of those artifacts are suppressed and the image quality can approach the fully sampled baseline, even when only a fraction of the original k-space samples are acquired. Depending on the sampling pattern, pulse sequence, scanner constraints, and reconstruction setup, this can support meaningful scan-time reductions while helping preserve image quality.

Compressed sensing reconstruction of a representative T1-weighted MRI slice from undersampled, low-SNR input k-space data. The image shows how sparsity-based reconstruction can suppress undersampling artifacts while preserving major anatomical structures.

Note: The above code uses functions from Wavelet Toolbox™ (wavedec2, waverec2) and can automatically leverage the Parallel Computing Toolbox™ to run on a GPU if available (via gpuArray). The iterative CS algorithm is more computationally heavy than IFFT, but GPU acceleration can make it practical for routine use.

Deep Learning Reconstruction with U-Net

Our third approach uses deep learning to push MRI reconstruction further. Instead of relying on hand-crafted transforms or optimization, we train a U-Net (a type of convolutional neural network) to learn the transformation from incomplete data to fully reconstructed image. U-Nets are well-suited for image-to-image tasks like segmentation and, here, reconstruction, thanks to their encoder-decoder structure with skip connections that captures both global context and fine details.

In our MATLAB example, we feed the network zero-filled IFFT reconstructions of undersampled data as inputs and the corresponding fully sampled images as targets. Using the Deep Learning Toolbox™, we can set up and train the U-Net as follows:

% Define a custom U-Net architecture for MRI reconstruction
lgraph = createCustomUNet([256 256 18], 18);

% Specify training parameters
options = trainingOptions("adam", ...
    InitialLearnRate = 1e-3, ...
    MaxEpochs = 600, ...
    MiniBatchSize = 12);

% Train the network using undersampled and reference images
net = trainNetwork(inputDataTrain, groundTruthDataTrain, ...
                   lgraph, options);

% Reconstruct images using the trained network
reconDL = predict(net, inputDataTest);

What’s happening? We define a custom U-Net architecture for image-to-image regression and train it on paired data: zero-filled reconstructions from undersampled k-space as inputs and fully sampled reconstructions as targets. The encoder-decoder structure with skip connections helps the network capture both global context and fine image details. Training options such as the optimizer, learning rate, number of epochs, and mini-batch size control the learning process. When a supported GPU is available and the execution environment is set appropriately, MATLAB can use GPU acceleration through Parallel Computing Toolbox™. After training, the predict function generates rapid reconstructions for new undersampled inputs.

This deep learning approach learns to map artifact-corrupted, zero-filled reconstructions to reference-quality images. If trained and validated well, the U-Net can reduce residual artifacts compared with conventional undersampled reconstruction and may support higher acceleration factors for a given image-quality target. It also runs very fast at inference because reconstruction is essentially one forward pass through the network. However, deep learning models require representative training data, careful validation, and quality-control checks to ensure that they generalize to new scans and do not introduce unintended artifacts. In practice, combining AI with physics-based methods, such as using a CS reconstruction as an input to the U-Net, can further improve robustness.

Deep learning reconstruction of a similar representative T1-weighted MRI slice from the same low-SNR input k-space dataset. The U-Net output is generated from an undersampled input reconstruction and is intended to reduce residual artifacts while preserving fine image detail.

Verification, Validation, and Deployment

Developing these algorithms is only part of the story – practical MRI workflows also require rich visualization and an eye towards deployment:

Automatic Testing and Verification: Because our three methods are implemented in one environment, we can easily create test scripts to verify that each reconstruction matches expected results (within tolerance) or to measure performance (like PSNR, SSIM) across a dataset. This can be integrated into a CI/CD pipeline (Continuous Integration/Deployment) to ensure code changes don’t break the pipeline.
Interactive Visualization and Validation: MATLAB’s Medical Imaging Toolbox™ provides apps and functions to explore 2D slices and 3D volumes, adjust colormaps (colormap), and even use cinematic volume rendering (volshow). This helps in visually validating results side by side: for example, comparing a CS reconstruction to the IFFT baseline, or overlaying error maps to spot differences.
GPU Code Generation and Deployment: A standout feature is the ability to automatically generate C/C++ and CUDA® code from our MATLAB algorithms for deployment with IEC 62304 certification support. Using MATLAB Coder™ and GPU Coder™, we can translate the IFFT, CS, or U-Net reconstruction into highly optimized code for embedded applications or integration into an MRI scanner’s software. For instance, we can generate a MEX function or a standalone library from our MATLAB code with just a few commands. The image below shows a snippet of the code generation process in MATLAB:

GPU code generation in MATLAB for the IFFT reconstruction algorithm. The code generator converts our MATLAB reconstruction function into a C/CUDA implementation (left: generated code preview and analysis) and reports a successful build (bottom). This enables integrating the proven algorithm into production systems, such as scanner software, with minimal manual coding.

Thanks to GPU acceleration and code generation, MRI reconstruction methods developed in MATLAB can scale from desktop prototyping to execution on specialized hardware. For example, once a U-Net is trained and validated in MATLAB, GPU Coder can help deploy inference code that uses optimized NVIDIA® libraries such as cuDNN and TensorRT, reducing the need to hand-code the inference engine.

Conclusion and Key Takeaways

By combining classical and AI-based reconstruction techniques in a single MATLAB workflow, we can address the diverse needs of modern MRI systems. A unified environment streamlines the process: raw data import, reconstruction, testing, verification, visualization, validation, and certification can all be done in one place, and when it’s time to deploy, the same code is ready for automatic translation to C/CUDA.

In summary, this workflow shows how MATLAB can support MRI reconstruction from early experimentation to deployment:

IFFT reconstruction provides a fast and reliable baseline for fully sampled data.
Compressed sensing enables accelerated acquisitions by combining undersampling, sparsity, and data-consistency constraints.
Deep learning can help reduce artifacts in undersampled reconstructions when trained and validated with representative data.
GPU acceleration and code generation help bridge the gap between research prototypes and deployable reconstruction pipelines.

We hope this example has shown how classic reconstruction techniques and AI can reinforce each other. By exploring baseline, compressed sensing, and deep learning methods within a unified setting, engineers are empowered to iterate quickly and tailor MRI reconstruction workflows to achieve both faster scans and high image quality, all while maintaining a clear path to real-world deployment.

Try the examples yourself: MRI Reconstruction in MATLAB

From PyTorch to Jetson via Simulink: Deploying YOLOv26 Instance Segmentation with Code Generation

Johanna Pingel — Mon, 06 Jul 2026 12:48:00 +0000

Guest blogger: Bill Chou

Bill Chou has spent more than 20 years at MathWorks working on code generation technologies. As a Product Manager for MATLAB Coder, GPU Coder, and deep learning code generation, he helps engineers deploy applications in controls, signal and audio processing, embedded vision, and machine learning across workstations, edge devices, and embedded targets.

A previous post showed how to generate standalone C/C++ and CUDA source code directly from PyTorch and LiteRT models, with no runtime or inference engine, just portable source code compiled with your existing toolchain. That post started with a simple MLP to illustrate the idea. This one picks up where it left off and asks: what does this look like with a real model processing real video and deployed to real hardware?

The answer involves YOLOv26, a driving video, Simulink, and a Jetson AGX Orin. Let’s walk through it.

Why YOLOv26?

If you work in perception, including autonomous driving, robotics, industrial inspection, or video analytics, you’ve probably encountered YOLO at some point. YOLOv26 has a trick that makes it particularly appealing for code generation: no NMS. The model uses an end-to-end detection architecture with 300 learned object queries. Each query directly produces a unique detection: bounding box, confidence, class, and mask coefficients, without the non-maximum suppression step that traditionally complicates deployment.

This matters because NMS involves dynamic-length operations (sorting, filtering with unknown output size) that are less than ideal for static code generation. YOLOv26 sidesteps the problem entirely. You always get exactly 300 detections; just filter by confidence.

The updated model does instance segmentation: not just boxes, but pixel-level masks for each detected object.

Detected vehicles and traffic lights from input video

We use the nano variant (~3M parameters, 6.7 MB). Small enough to run on edge hardware, accurate enough to be useful for our purposes.

Starting in PyTorch

Many state-of-the-art models are released as PyTorch checkpoints, and YOLOv26 is no exception. We start in Python to grab the pretrained model, wrap it to emit only the two outputs we need, and export to .pt2:

Python export wrapper for YOLOv26 nano

The .pt2 format (PyTorch ExportedProgram) freezes the computation graph into a static representation. No Python interpreter is needed at inference time and there is no dynamic dispatch, just the math that’s captured cleanly. This static representation is also what enables execution on edge devices. While the Jetson is a capable platform, every cycle counts when you run on the edge. When running your real-time application, you do not want the hardware to burn resources on a Python runtime and dynamic graph overhead alongside it.

We are not just checking that the file loads. We compare the exported model against the original PyTorch model on 128 COCO images, and the outputs match within floating-point tolerance. That gives us confidence that the next stages are validating deployment behavior, not debugging a PyTorch export mismatch.

Into MATLAB: Test, Then Generate Code

Loading the model in MATLAB takes one line:

Load the PyTorch ExportedProgram in MATLAB

That loadPyTorchExportedProgram call from the MATLAB Coder Support Package for PyTorch and LiteRT Models is part of the entry-point function yoloSegmentImagePt2_v26.m, which wraps the full pipeline: resize, normalize, permute to PyTorch’s NCHW layout, run inference, filter by confidence, generate masks, and annotate. The permutation matches MATLAB image data to PyTorch’s tensor layout, ensuring YOLOv26 receives the input data in the expected shape and order. The function is designed from the start to be code generation-compatible:

Run MATLAB inference on a test image

To verify we’re still getting the same results, we run the MATLAB interpretation against the full COCO128 dataset, the same 128 images used for Python validation. Detection counts and segmentation outputs match what we saw in Python, confirming that the .pt2 import preserves model behavior end-to-end.

But the whole point is to not stop at MATLAB interpretation. We want compiled code.

Generate C/C++ code with SIL verification

MATLAB Coder generates C/C++ source code, compiles it, and runs it on the host back-to-back with the MATLAB interpretation using Software-in-the-Loop (SIL) testing. The outputs match, verifying correctness on the x86 architecture before we move to any other target. We reuse the same testing infrastructure here to compare the generated code’s results against both MATLAB execution and the original Python outputs. Under the hood, the same MLIR-based optimizations from the previous post are at work: operator fusion, vectorization, and hardware-aware code emission.

CUDA on the host GPU

Add coder.gpu.kernelfun to your entry-point function and replace coder.config with coder.gpuConfig in the build script to enable CUDA code generation using GPU Coder:

Generate CUDA code with SIL verification

The function and model don’t change, only the target language does. The generated CUDA kernels are standalone by default with no calls to cuDNN or TensorRT. Just CUDA code that compiles with nvcc (NVIDIA’s CUDA compiler) and runs on any modern NVIDIA GPU, whether that’s a desktop workstation, a Jetson, or a cloud instance with an A100.

If you do want to leverage TensorRT for optimized layer implementations and FP16 inference, simply replace with these two lines:

Optionally enable the generated CUDA to call TensorRT with FP16

The standalone path is simpler to deploy as it requires no library dependencies on the target while the TensorRT path trades that simplicity for runtime performance, though with an additional startup cost. Choose based on your constraints.

We used the MATLAB Agentic Toolkit with an AI coding agent throughout the Python and MATLAB sections. The agent acted on our behalf to call MATLAB and import the .pt2 file into the MATLAB code base, set up testing infrastructure, and iterate through the code generation steps for each target. This sped up development considerably, automating many of the steps needed to get our code up and running on the host machine.

Deploying to the Jetson AGX Orin

With CUDA code generation working on the host, the next question is: does it run on the actual target hardware? GPU Coder will help us verify this by automating the deployment to the Jetson.

You don’t need to SSH into the Jetson and run commands manually. The entire deployment, including cross-compilation, file transfer, on-target builds, execution, and result retrieval, is orchestrated from MATLAB on your development machine. The jetson() hardware object gives you a programmatic connection to the device, and everything flows through it.

The deployment uses a two-phase build to handle a common cross-compilation wrinkle: we need OpenCV for image I/O on the Jetson, but it’s not installed on the Windows host. Linking at this stage would result in an error.

Phase 1 (from MATLAB on host): codegen cross-compiles the entry-point function into ARM64 .o files and transfers them to the Jetson automatically via the hardware object.

Phase 2 (triggered from MATLAB, runs on Jetson): MATLAB issues a system(hwobj, ...) call that compiles a custom C++/CUDA main on the Jetson, linking against the device’s local OpenCV and cuBLAS:

Deploy and run inference on Jetson from MATLAB

The custom main handles the layout conversion that every OpenCV-to-MATLAB bridge needs: BGR row-major (OpenCV) to RGB column-major (MATLAB-generated code) on input, and the reverse on output. It also includes a GPU warm-up step and inference timing.

Image processed on Jetson matches the results on host machine

The whole workflow (connect, cross-compile, transfer, build, run, retrieve) is wrapped in a single script (deployToJetson.m). One command from MATLAB, and you go from source code to running inference on the Jetson and viewing the result on your host.

Simulink: From Single Images to Video Streams

With single-image inference validated on both host and Jetson, we move to video. If you’re building a perception system for a vehicle or a robot, you’re processing streams, frame after frame, in a pipeline that might include sensor fusion, control logic, and hardware I/O. That’s Simulink territory.

The YOLOv26Pt2VideoSimulink.slx model does exactly what you’d expect: reads a driving video (winter_driving.mp4), runs YOLOv26 on each frame, and overlays the segmentation results.

YOLOv26 in Simulink model processing input video

The interesting part is what’s inside: a PyTorch ExportedProgram block from the MATLAB Coder Support Package for PyTorch and LiteRT Models. This block loads the .pt2 file directly. You point it at the same yolo26n-seg-2out.pt2 file used previously in the MATLAB stage, configure the input/output dimensions, and it handles inference during simulation and generates C/C++/CUDA code when you build. Two MATLAB Function blocks flank it: one for preprocessing (resize, normalize), one for postprocessing (processMasks.m, createClasses.m). These are largely shared with the standalone MATLAB workflow, so little additional work was needed. The permutation to PyTorch’s NCHW layout? That’s handled inside the ExportedProgram block itself, so the flanking blocks stay simpler than in the standalone MATLAB path.

YOLOv26 running in Simulink with the detected objects in the output video stream

The output is an annotated video with colored segmentation masks, bounding boxes, and class labels for vehicles, pedestrians, and other road objects, all computed frame-by-frame inside Simulink.

We could have done all the Simulink work ourselves, but as we did with the MATLAB stage, we opted to use the Simulink Agentic Toolkit to help inspect block connections, verify signal dimensions, and iterate on the integration of the YOLOv26 network via the PyTorch ExportedProgram block.

Generating CUDA from Simulink

Here’s what we’ve been building toward. We’ve validated the model in simulation. Now we generate CUDA code directly from the Simulink model:

Generating CUDA code from Simulink with GPU Coder

The %#codegen pragmas and coder.gpu.kernelfun calls in the helper functions tell GPU Coder to map parallelizable operations to CUDA kernels automatically. Since the pragmas and kernelfun calls were already in place from the MATLAB stage, we’re not doing anything extra here. We’re reusing the same code generation-ready functions. The PyTorch ExportedProgram block automatically generates optimized C/C++ or CUDA code to match the code generation settings configured in Simulink, so no additional configuration is needed. The result is standalone CUDA that processes the complete video pipeline: read frame, infer, post-process, annotate, and write frame.

Deploying to the Jetson is simpler this time around. We configure the same Jetson settings directly into the Simulink code generation settings, and Simulink + GPU Coder takes care of the rest. The end result is the same: cross-compiling the video pipeline for the Jetson’s ARM64 + CUDA architecture, managed from Simulink instead of the MATLAB command line.

The Agentic AI Angle

A quick sidenote on how this workflow was developed. As briefly mentioned in previous sections, we paired the MATLAB Agentic Toolkit and Simulink Agentic Toolkit with an AI coding agent throughout this project. The toolkits give AI agents direct access to MATLAB and Simulink for running code, inspecting models, tweaking code generation settings, and diagnosing build failures.

This is especially valuable for the code generation steps, where users will often iterate as they tweak and tune the generated code running on the edge to match their requirements. Having an AI assistant that can run code generation, inspect the results, and retry shortens this loop considerably. And since the AI agents use MATLAB Coder and GPU Coder as trusted tools to generate C/C++ or CUDA code, you still get the same deterministic, reproducible output as if you were using those products directly. Finally, the toolkits are built on an open protocol (MCP) and so this approach extends to any AI assistant that supports it, including Codex, Gemini, or whatever comes next.

Wrapping Up

Here’s the pipeline in full:

PyTorch: Export YOLOv26 to .pt2, validated with outputs matching within tolerance
MATLAB: Integrate YOLOv26, test against COCO128 images, generate C/C++ and CUDA code with SIL verification
Simulink: Apply YOLOv26 to input video stream and generate CUDA code with minimal changes from MATLAB stage
Jetson: Deploy standalone CUDA on NVIDIA Jetson AGX Orin from both MATLAB and Simulink stages

The same YOLOv26 model and shared set of MATLAB functions carry you from interpreted prototyping through edge deployment, verified in Python, MATLAB, and Simulink environments along the way. The MATLAB Coder Support Package for PyTorch and LiteRT Models is what ties it together, bridging PyTorch’s research ecosystem with MATLAB and Simulink’s production deployment infrastructure.

If you’re working on perception for autonomous systems, robotics, or video analytics and want a traceable path from your PyTorch model to embedded hardware without hand-writing CUDA or managing inference runtimes, this is the workflow.

Resources

An AI Coding Agent for Embedded AI

Johanna Pingel — Mon, 08 Jun 2026 13:11:46 +0000

Guest blogger: Arkadiy Turevskiy

Arkadiy Turevskiy is the Product Manager for AI and Controls products at MathWorks. Arkadiy has been with MathWorks for over 20 years. Before MathWorks he designed aircraft engine control systems at Pratt & Whitney.

When I deploy a deep learning model from MATLAB to an embedded target, I follow a specific workflow. I know which Deep Learning Toolbox blocks to use in Simulink for simulation speed and code generation. I know when to apply pruning, projection, or quantization to fit a model onto a constrained processor. I've built that expertise over years.

The first time I asked Claude Code to help with this workflow, it didn't have any of that context. It burned tokens trying approaches I would have skipped, and missed tools I would have reached for immediately.

That was the gap I wanted to close.

For the last several weeks my colleague Lucas Garcia and I have been building a skill file for Embedded AI that captures that workflow knowledge and gives it to an agent to avoid the frustrating iterations I experienced. I am excited to share that the improved version of this skill has now been published as part of MATLAB Agentic Toolkit. The skill will trigger when a coding agent detects it is relevant to your project. You can also explicitly tell the agent to invoke this skill.

What We Mean by Embedded AI

Embedded AI is AI that runs on resource-constrained hardware, integrated alongside control logic, signal processing, and application code, and validated as part of a larger engineered system. Model accuracy is necessary, but not sufficient: the algorithm must also behave correctly under real-world constraints and remain maintainable.

The skill covers two workflow patterns that account for most projects:

Pattern 1 for small models (under 500 KB) on lean hardware such as ARM Cortex-M, Cortex-A/R, and DSPs. Pattern 1 has two pathways. In the first, you train the model directly in MATLAB using Deep Learning Toolbox or Statistics and Machine Learning Toolbox. In the second, you bring in a pre-trained model from a third-party framework such as PyTorch or ONNX, and the agent imports it as a dlnetwork. From there the path is the same: the agent applies compression - pruning, projection, and/or INT8 quantization - depending on your objectives, integrates the network into Simulink for system-level simulation, and generates C with Embedded Coder.
Pattern 2 for larger models (over 1 MB) on high-performance hardware such as x86, GPUs, and Cortex-A. The agent generates C/C++ directly from a PyTorch or LiteRT model using the MATLAB Coder Support Package for PyTorch and LiteRT, with no native rebuild required.

The skill picks the pattern automatically after a short conversation about your model, your target, and your constraints.

A Short Demo

Here is the agent walking through Pattern 1 - importing a PyTorch LSTM, compressing it for a Cortex-M7, and generating the C code:

This demo plays without sound and is shown at accelerated speed. Your experience might be different from what is shown as the skill is frequently updated.

A few things worth noticing:

The agent pauses after every workflow step and asks before moving on. You see each MATLAB script before it runs or after it runs.
It detects your installed toolboxes and support packages silently before the workflow starts, so it never asks you to use something you do not have.
It opens Deep Network Designer so you can inspect the architecture visually, rather than trust a wall of layer-by-layer text output.
After import, it runs the original model through PyTorch and the rebuilt MATLAB model side by side, then reports mean absolute error and max error explicitly.

These behaviors are explicitly encoded as rules in the skill file.

What Is Inside

The skill is plain markdown - a top-level SKILL.md plus about a dozen reference files split between pattern1/ and pattern2/, with shared references for environment discovery, project discovery, and AI verification. SKILL.md itself is a router with a decision tree, a list of banned legacy functions (trainNetwork, DAGNetwork, importONNXNetwork, etc), and explicit ALWAYS / ASK FIRST / NEVER rules.

A few examples:

ALWAYS create a MATLAB script for every workflow step - never run ad-hoc commands - so the engineer can read it, re-run it, and put it under version control.
ASK FIRST before code generation: is the target an ARM Cortex-M? If so, enable CMSIS-NN for a significant speedup.
NEVER install support packages on the user's behalf.

The result is an agent that behaves the way an experienced embedded engineer expects a junior teammate to behave: methodical, transparent, and willing to stop and ask.

Why This Matters

Agentic coding tools are fast, but the code they produce is non-deterministic and hard to verify. The Embedded AI skill bridges this gap: the agent gives you the speed of natural-language iteration, while MATLAB, Simulink, and Embedded Coder give you deterministic code generation, system-level simulation, and a path to SIL, PIL, and HIL verification. Every step is a MATLAB script and/or Simulink model you can read, re-run, and put under version control.

The agent does the typing while you stay in control.

Try It Yourself

You will need MATLAB R2026a with Deep Learning Toolbox, MATLAB Coder, Embedded Coder, and the support packages listed in the repo's README. You will also need MATLAB Agentic Toolkit and Simulink Agentic Toolkit - both provide the MCP servers the agent uses to talk to MATLAB and Simulink. I tested everything with Claude Code, but the skill format should be straightforward to port to other coding agents.

Drop the skill folder into your project's .claude/skills/ directory, start the agent, and describe what you want to deploy. The first thing the agent will do is ask about your model, your target hardware, and your constraints.

If you build something with this, I would love to hear about it. Leave a comment below with your thoughts and feedback!

From PyTorch & LiteRT to C, C++, and CUDA source code

Johanna Pingel — Fri, 22 May 2026 13:19:14 +0000

Guest writer: Christoph Stockhammer

Christoph Stockhammer is an application engineer at MathWorks, focusing on AI use cases. Christoph holds a Master's in Mathematics from the Technical University of Munich.

If you have ever tried to deploy a PyTorch model on embedded hardware, you know the story: the model itself is only half the battle. The real challenge starts when you need a runtime, shared libraries, hardware-specific builds, and a toolchain that somehow still fits on your target device.

Starting with MATLAB R2026a, there is an alternative route. Instead of shipping a runtime to the device, you can now generate standalone C/C++ (and CUDA®) source code directly from PyTorch ExportedProgram and LiteRT models. No interpreter. No inference engine. No import process into MATLAB. Just readable and portable source code that you compile with your existing toolchain.

Why standalone code generation?

Embedded targets--from microcontrollers to devices like Raspberry Pi or NVIDIA® Jetson™--care deeply about predictability. Memory usage, startup time, and binary size often matter more than flexibility. Runtime-based solutions such as LiteRT (for Microcontrollers) or ONNX Runtime do a great job, but they still bring dependencies and abstraction layers that require more processing power and memory usage above and beyond pure source code.

Standalone code generation removes that layer entirely. The generated code contains only what your model needs: loops, math, and data. That makes it easier to analyze, debug, certify, and integrate with existing embedded software.

Under the hood: MLIR as the secret sauce

The key technology behind this workflow is MLIR (Multi-Level Intermediate Representation). MATLAB Coder lowers PyTorch ExportedProgram and LiteRT models into MLIR, applies a series of graph- and hardware-aware optimizations, then emits C/C++ or CUDA source code.

Because the optimizations happen at the IR level, the generated code can take advantage of:

Operator fusion to reduce memory traffic
Parallel execution using OpenMP on multicore CPUs
Vectorization (for example, ARM® Neon or Intel® AVX)
Hardware-specific kernels where available

The result is code that can be both portable and efficient.

PyTorch and LiteRT, supported directly

The workflow supports two input formats:

PyTorch ExportedProgram, for a clean and stable representation of PyTorch models
LiteRT, whether it originates from TensorFlow or is converted from PyTorch models

A classic example: multi-layer perceptron (MLP)

Feedforward networks based on dense layers are one of the most popular network architectures and they are ideal for introductory examples. So let's look at one:

Defining such a network only takes a few lines of code in torch:

self.net = nn.Sequential(
    nn.Linear(in_features, hidden1),
    nn.ReLU(),
    nn.Linear(hidden1, hidden2),
    nn.ReLU(),
    nn.Linear(hidden2, out_features)
)

Usually, we would train the model with actual data, but for our purposes it suffices to just write the model to disk with the original (randomly initialized) weights and biases:

example_inputs = (torch.randn(batch_size, in_features),)
exported_program = torch.export.export(model, example_inputs)
out_file = "three_layer_mlp.pt2"
torch.export.save(exported_program, out_file)

This will produce a file "three_layer_mlp.pt2" and we can visualize it in tools such as Netron. As expected, we see three dense layers (titled "linear") with relu activations in between:

Now, we can go ahead and load this model in MATLAB as well:

>> mlp = loadPyTorchExportedProgram('three_layer_mlp.pt2')

Loading the model. This may take a few minutes.

mlp =

  PyTorchExportedProgram contained in three_layer_mlp.pt2:

    Input Specifications
    ______________________________________

    Input  Name    Size       Type
    _____  _____   ________   ________

    1      "in1"   "1 x 16"   "single"

    Output Specifications
    _______________________________________

    Output  Name     Size      Type
    ______  ______   _______   ________

    1       "out1"   "1 x 8"   "single"

This looks good: We see the correct number of input features (16) and output features (8). It is advisable to also run some inference tests from within MATLAB. For example, I can have the model predict just with some random data:

>> invoke(mlp, randn(1,16,'single'))

ans =

  1×8 single row vector

   -0.0442   -0.2474    0.3094    0.1759   -0.0768    0.0293    0.1398   -0.0767

We now want to move ahead and generate C source code from the model's prediction function. To this end, we just need to put the above commands into a MATLAB function:

function predictions = predictModel(inputFeatures)
    mlp = loadPyTorchExportedProgram('three_layer_mlp.pt2');
    predictions = invoke(mlp, inputFeatures);
end

As a final step, we generate C source code files with a single MATLAB command:

>> codegen -c predictModel.m -args {zeros(1,16,'single')}

My laptop has an Intel i7 processor. In order to improve performance, the code generator recognizes my processor configuration automatically (I could also manually override this with a different configuration if I wanted to). Using this piece of information, the code generator leverages AVX instructions (which my processor supports) for calculating the matrix-vector multiplications which are at the heart of the dense layers. So rather than naive for-loops, I get something like the following in the generated C code:

c = _mm256_add_ps(c, _mm256_mul_ps(_mm256_loadu_ps(&A[idxA]), b));

Here _mm256_mul_ps is the single precision (FP32) packed multiplication operation using Intel intrinsics, which can lead to much better performance. The above is just one example of how the generated code is optimized to the specific hardware it is intended to be executed on.

More than just inference

In real applications, neural networks almost never run in isolation. Preprocessing, postprocessing, other control logic and more are almost always part of the story, too. One nice thing about using automated code generation is that you can generate code for the entire application--signal processing, feature extraction, and neural network inference--in one deterministic step.

Example applications, including the MATLAB code and Simulink models, ship with this capability. For example, running monocular depth estimation using Depth Anything V2 PyTorch Model can be used for applications such as autonomous driving and navigation.

The segmentation and object detection using YOLO v11 LiteRT model example shows how to identify and outline objects to enable image segmentation and detection, all without relying on NVIDIA cuDNN or TensorRT™ libraries.

Finally, the predict battery state of charge using LiteRT model example shows the workflow to deploy an AI model that predicts the battery state of charge (SOC), a key metric for energy management systems in electric vehicles and other battery-powered devices.

In this day and age, one could also consider Generative AI tools when looking for C or C++ source. One major distinction of the workflow we described above is that it is deterministic and traceable. If you generate the C sources ten times (using the same configuration) it will produce the exact same C sources ten times. No dependency on backend large language models, context or prompts.

A practical alternative to runtimes

Our benchmarks show that the generated code delivers performance quite comparable to runtime-based approaches. Just as importantly, the code is human-readable, configurable, and re-entrant as needed.

Here is a chart showing the performance of the automatically generated code vs LiteRT for several popular network architectures on Raspberry Pi 4. In the initial release, our focus is on supporting as many networks and layers as possible given our users' propensity to use many different types of networks. Many optimizations are planned and we anticipate matching and exceeding the performance of the interpreter in subsequent releases:

In summary: If you are looking for an AI deployment workflow that prioritizes transparency, portability, and tight integration with embedded systems, standalone code generation from PyTorch and LiteRT using MATLAB Coder is well worth a look.

Less Typing, More Creating: MATLAB Copilot Comes to Your Android Phone

Yann Debray — Tue, 07 Apr 2026 14:07:52 +0000

Guest Co-author: Tharikaa Ramesh Kumar, PhD

Tharikaa is the Product Manager for MATLAB Mobile. She holds a PhD in Aerospace Engineering from Auburn University, where she taught dynamics and systems courses using MATLAB as a graduate instructor.

I'm excited to share some news that I think will change the way many of you use MATLAB on the go. We've brought MATLAB Copilot to MATLAB Mobile, and it's available for now on Android with two features: Copilot Chat and Explain Code. If you've ever been on a commute, in a lecture hall, or out in the field and wished you could quickly prototype an idea in MATLAB, you know the challenge. You pull out your phone, open MATLAB Mobile, and start typing on a small touch keyboard. It works, but it's not exactly the same as sitting at your desk. That's where Copilot comes in.

Why an AI Assistant on Your Phone Changes Things

Let's be honest: coding on a phone has its limitations. The screen is smaller, the keyboard is touch-based, and switching between your code and documentation is a juggling act. MATLAB Copilot reduces that friction significantly.

With Copilot Chat, you describe what you want in natural language and get MATLAB code you can run right away. Instead of typing out every function call and argument, you tell Copilot what you need and it writes the code for you. Less typing, more creating!

Here is a bonus: your phone keyboard already has a microphone button for speech-to-text. Tap it, speak your Copilot prompt, and the code appears. You do not even need to type your request. Between voice input and AI-generated code, this is as close to a low-code experience as it gets on a phone. And when you do type, your phone keyboard's predictive text and autocomplete suggestions help you write prompts faster than you would on a desktop keyboard.

For the many students and educators who use MATLAB Mobile every day, this is especially valuable. Your phone is the one device that's always with you and always charged. It's more personal and more accessible than a laptop. With Copilot on that same device, you get answers and explanations on the spot, right where you are, instead of waiting to get back to a computer.

Copilot Chat

Copilot Chat is a conversational AI assistant built right into MATLAB Mobile. You can access it from the Command Window, the Editor, or the app menu. Ask a question, describe the code you need, or request an explanation. Copilot responds with answers grounded in MathWorks documentation.

Here is where it really shines on mobile. Say you've just collected accelerometer data from your phone's sensors using MATLAB Mobile's built-in sensor support. You want to plot the x, y, and z axes on a single figure, but you can't remember the exact syntax. Open Copilot Chat and describe what you're looking for. Copilot generates a ready-to-run snippet that handles the plot calls, axis labels, and legend for you. Tap to insert the code, hit Run, and you're looking at your data.

It works just as well for broader questions. If you're wondering how to apply a low-pass filter to audio you recorded on your phone, ask Copilot. Need a quick refresher on how fft works? Ask Copilot. It handles everything from basic syntax help to signal processing workflows, and every response draws from official MathWorks documentation so the code follows best practices.

As with all things GenAI, your results will depend on your specific question and context.

Explain Code

The second feature we're bringing to MATLAB Mobile is Explain Code. Select any block of code in the Editor, tap Explain Code, and get a plain-language overview of what the code does along with a line-by-line walkthrough in the Chat panel.

On a small screen, dense code can be tough to read. Explain Code helps you make sense of it quickly. Say you open a shared script from MATLAB Drive, maybe a classmate's assignment or an instructor's demo file, and encounter a block of code using fft, windowing functions, and inverse transforms. Instead of switching apps to search the documentation, select the code and tap Explain Code. Copilot gives you an overview of the block's purpose and annotates each line so you understand not just what the code does, but how.

This is incredibly useful for learning. Students can review code before an exam and actually understand each line. TAs can quickly parse student submissions between classes. Professors can pull up a demo script and get a refresher before a lecture. All from their phone.

When Will You Use This?

The student on the bus. You're reviewing the signal processing examples your professor shared on MATLAB Drive. You select the Fourier transform code block, tap Explain Code, and get a line-by-line breakdown. By the time you arrive, you understand exactly how the frequency domain conversion works.

The professor between classes. A student messages you about an error in their script. You open MATLAB Mobile, describe the issue to Copilot Chat, and get a suggested fix. Share the chat history directly through your phone's messaging apps, or save it as a .txt file to MATLAB Drive for later reference. No laptop needed.

The engineer in the field. You're collecting magnetometer data with MATLAB Mobile's sensor support and want to visualize the magnetic field direction. You ask Copilot Chat how to create the visualization. It generates the code, you run it on the spot, and you see results immediately.

And here is the thing: none of this work is stuck on your phone. Every script you create with Copilot syncs to MATLAB Drive, so you can start prototyping on the bus and pick up right where you left off on your desktop. Copilot on your phone is not a separate experience. It is part of the same workflow.

We hear from students and researchers all the time that their phone is always with them, even when their laptop isn't. Now, MATLAB Copilot is right there too.

How to Get Started

Getting started takes just a few steps:

Install or update MATLAB Mobile from the Google Play (Android). The app is free to download.
Check your MATLAB Copilot license. You'll need a MATLAB Copilot license to use Copilot Chat and Explain Code. Many university campus-wide licenses already include MATLAB Copilot. Check with your institution's MATLAB administrator. Individual and team licenses that include Copilot work as well.
Start using it. Open MATLAB Mobile and access Copilot Chat from the Command Window, the Editor, or the app menu. To try Explain Code, select code in the Editor and choose "Explain Code." That's it.

For more details, visit the MATLAB Copilot documentation and the MATLAB Mobile product page.

Try It Out

We've been looking forward to getting this into your hands. Update MATLAB Mobile, open Copilot Chat, and ask your first question. I think you'll be surprised how quickly it becomes part of your workflow.

We'd love to hear how you're using MATLAB Copilot on Mobile. Drop a comment below or share your experience with #MATLABMobile.