Student Lounge

Using Lidar for 3D Object Detection

Tanya Kuruvilla — Mon, 01 Jun 2026 14:33:04 +0000

Today, we’re going through each step of creating a 3D object detector using Lidar data. We’ll start with an introduction to 3D point clouds and how to process them, then we’ll label point clouds for deep learning, train an 3D object detector, and wrap up by discussing a few options for deploying the detector to your projects or hardware.

The complete dataset, code, and videos we’ll be discussing in this blog can be found at this GitHub Repository.

Understanding and Processing Point Clouds
Labeling Point Clouds for Deep Learning
Training a 3D Object Detector with Deep Learning
Deploying a 3D Object Detector

1. Understanding and Processing Point Clouds

The dataset used in this example can be found in this ‘parkingLot’ folder and will need to be downloaded in order to follow along. A video explanation of this topic can be found here.

Understanding Point Clouds

Lidar sensors record spatial data and store it as a point cloud, or a collection of points that represent the world around the sensor. In a 3D point cloud, these points are stored as x,y,z coordnates and can be visualized, so if your environment looks like this:

your point cloud might look like this:

This is a way of numerically representing the world around us in 3 dimensions, which is helpful for developing algorithms that rely on things like distance from a robot or size of an object.

Processing Point Clouds

Processing point clouds before using them for deep learning can often lead to better results. The Lidar Viewer App lets you import, view, and process point clouds interactively, and is demonstrated in this video.

You can also process point clouds programmatically. Load in a point cloud from our dataset using the pcread function:

singlePtCld = pcread(‘./parkingLot/frame_0001.pcd’);

pcshow(singlePtCld)

Denoising

Point clouds can have “noise”, or data points that are outliers to what you’d expect to see in your point cloud. Use the pcdenoise function to remove or reduce these. The purple points in the figure below represent points that were removed.

ptCloudDenoise = pcdenoise(singlePtCld);

figure

pcshowpair(singlePtCld, ptCloudDenoise)

Downsampling

Depending on your LiDAR and the environment you collected data in, you may have a lot of data points, which can lead to slower computaton. Use the pcdownsample function to make your point cloud less dense through downsampling. Use pcshowpair to view which data points were removed (purple) and which stayed (green).

ptCloudDownSampled = pcdownsample(ptCloudDenoise,‘random’,0.60);

pcshowpair(ptCloudDenoise, ptCloudDownSampled)

Check out this documentation page to see further options for processing lidar data.

It can be helpful to test out different preprocessing methods on a single point cloud to see how it affects your data. Once you have a combination of steps and settings that you’re happy with, you can apply it to the whole dataset. This is easy to do with the Lidar Viewer app, which exports the processed dataset to a folder called parkingLot_Edit by default.

2. Labeling Point Clouds for Deep Learning

Once the data is processed, you can label the objects in the point clouds. First, split the data into a train and test dataset, which helps for the deep learning step.

pcd_files = dir(“./parkingLot_Edit/*.pcd”);

test_data = pcd_files(1:366);

train_data = pcd_files(367:807); 

if ~exist(“./parkingLotTrain”, ‘dir’)

 mkdir(“./parkingLotTrain”);

end

if ~exist(“./parkingLotTest”, ‘dir’)

 mkdir(“./parkingLotTest”);

end

for i=1:length(train_data)

 fileName = fullfile(train_data(i).folder, train_data(i).name);

 copyfile(fileName, “./parkingLotTrain”);

end

for i=1:length(test_data)

 fileName = fullfile(test_data(i).folder, test_data(i).name);

 copyfile(fileName, “./parkingLotTest”);

end

For this example, we label cars, cones, and barrels using the Lidar Labeler app. You can start a new labeling session by running the ‘lidarLabeler’ command below

lidarLabeler

or by selecting the Lidar Labeler app from the ‘APPS’ tab.

Watch this video to see how we label the dataset and save the labels to a variable called gTruth:

3. Training a 3D Object Detector with Deep Learning

With a labeled dataset, it’s time to train your object detector! A video explanation of this topic can be found here.

Import Labeled Data

Create datastores to access the data and associate labels with their corresponding point clouds.

[pcds,bxds] = lidarObjectDetectorTrainingData(gTruth, “SamplingFactor”,1);

dsTrain = combine(pcds, bxds);

preview(dsTrain)

ans = 1×3 cell 

1
2
3

1
1×1 pointCloud
4×9 double
4×1 categorical

	1	2	3
1	1×1 pointCloud	4×9 double	4×1 categorical

When you read from the datastore dsTrain, it returns a point cloud, bounding boxes of each object in the point cloud, and the labels for each bounding box.

Augment the Data

Augmentation is a great way to make your dataset, and therefore your object detector, more robust. Use the sampleLidarData function to collect point cloud samples from each of the classes present in the data.

classNames = [“car”, “barrel”, “cone”]; 

sampleLocation = fullfile(pwd, “parkingLotSampled”);

[ldsSampled,bdsSampled] = sampleLidarData(dsTrain,classNames,…

 WriteLocation=sampleLocation,Verbose=false);

dsSampled = combine(ldsSampled,bdsSampled);

Then, apply the ‘pcBboxOversample’ function to insert these samples into each point cloud, ensuring that each point cloud will have at least 3 of each object. The images below are an example of what this process looks like.

totalObjects = 3;

dsOversampled = transform(dsTrain,…

 @(x)pcBboxOversample(x,dsSampled,classNames,totalObjects));

Configure Object Detector

Specify the point cloud range, class names, and anchor boxes that you’ll use to train the detector.

anchorBoxes = calculateAnchorsPointPillars(gTruth.LabelData);

xMin = 0;

xMax = 69.12;

yMin = -39.68; 

yMax = 39.68;

zMin = -0.5157;

zMax = 5;

pcRange = [xMin, xMax, yMin, yMax, zMin, zMax];

pretrainedDetector = load(“pretrainedPointPillarsDetector.mat”,“detector”);

oldDetector = pretrainedDetector.detector;

detector = pointPillarsObjectDetector(oldDetector.Network,pcRange,classNames,anchorBoxes);

Use the trainingOptions function to specify how the model will be trained. Choosing training options is an iterative process, so try adjusting some of these options and see how it affects the performance of your detector.

options = trainingOptions(‘adam’,…

 ‘MaxEpochs’,60,…

 ‘MiniBatchSize’,3,…

 ‘GradientDecayFactor’,0.9,…

 ‘SquaredGradientDecayFactor’,0.999,…

 ‘LearnRateSchedule’,“piecewise”,…

 ‘InitialLearnRate’,0.0002,…

 ‘LearnRateDropPeriod’,15,… 

 ‘LearnRateDropFactor’,0.8,…

 ‘BatchNormalizationStatistics’,‘moving’,…

 ‘ResetInputNormalization’,false);

Train Object Detector

Use the trainPointPillarsObjectDetector function to train your network!

[detector,info] = trainPointPillarsObjectDetector(dsOversampled,detector,options);

Test Object Detector

Now that you have a trained detector, test it on a frame from the test set:

player = pcplayer([xMin xMax],[yMin yMax],[zMin zMax]);

testframe = pcread(‘./parkingLotTest/frame_0014.pcd’);

view(player,testframe);

ax = player.Axes;

[bboxes,scores,labels] = detect(detector,testframe,“Threshold”,0.4);

showShape(“cuboid”,bboxes,Color=“green”,Parent=ax,Opacity=0.3,LineWidth=1);

By showing the detected objects, we can see that the detector is successfully detecting the row of barrels!

Once you have a 3d object detector that you’re happy with, save it to a .MAT file for later use.

save detector detector

4. Deploying a 3D Object Detector

You will need to do some setup before you can deploy a neural network. Watch this video to learn more about the setup steps and for an explanation of the following options.

Generate a static library
Generate an executable ROS2 node

Option 1: Generating a Static Library

To get started, create an inference function called pillarPredict that loads the trained network, makes a prediction, and returns the detection results.

function [bboxes, scores, labels] = pillarPredict(pcloud_3d, intensities)

%#codegen

 persistent mynet

 if isempty(mynet)

 mynet = coder.loadDeepLearningNetwork(‘detector.mat’);

end

 %Converting to pointCloud so the model can detect objects. pointCloud

 %function can be used in code generation

 pcloud = pointCloud(pcloud_3d, Intensity=intensities);

 [bboxes,scores,labels] = detect(mynet,pcloud,‘Threshold’,0.5);

end

Then, create an entry point script. This helps in defining the input and output variable types and shapes.

% Load a test data point and convert it from point cloud to 3D array

pcloud = pcread(“..\testData\frame_0001.pcd”);

pcloud_3d = pcloud.Location;

intensities = pcloud.Intensity;

[bboxes, scores, labels] = pillarPredict(pcloud_3d, intensities);

Now, open MATLAB Coder and set it up to generate a static library. The code generation function will be the pillarPredict function and the entry point script is the entry point function shown above.

coder

Ensure that ‘Enable code generation for deep learning’ is checked and the right library is used. This can be set under Settings -> Deep Learning as shown below.

The next step is to generate code. Here, choose a static library, then click ‘Generate’ to begin code generation. The static library can then be used with your project!

ROS Node Generation

These steps show how to generate a ROS2 node that subscribes to a point cloud message and publishes the inference of the trained network. To get started, setup MATLAB Coder to generate a ROS2 node and to use the appropriate deep learning library. For this example, we’ll generate a node that can run on a Jetson Orin Nano using the CUDNN library, which uses CUDA cores to speed up inference.

% Setup the coder to generate a ROS2 node on a remote device

cfg = coder.config(“exe”);

cfg.Hardware = coder.hardware(“Robot Operating System 2 (ROS 2)”);

cfg.Hardware.DeployTo = “Remote Device”;

cfg.Hardware.BuildAction = “Build and run”;

% The Jetson board has an ARM 64 bit processor so we choose that as the device type

cfg.HardwareImplementation.ProdHWDeviceType = “ARM Compatible->ARM 64-bit (LLP64)”;

cfg.HardwareImplementation.ProdLongLongMode = true;

% The next three lines sets up the GPU coder and sets up to use CUDNN

cfg.GpuConfig = coder.GpuCodeConfig;

cfg.GpuConfig.Enabled = true;

cfg.DeepLearningConfig = coder.DeepLearningConfig(‘cudnn’);

% The last 4 lines provides information of the remote device so the coder

% can transfer the generated code and build it.

cfg.Hardware.RemoteDeviceAddress = ‘172.21.89.193’;

cfg.Hardware.ROS2Workspace = ‘/home/ubuntu/ros2_ws’;

cfg.Hardware.RemoteDeviceUsername = ‘ubuntu’;

cfg.Hardware.RemoteDevicePassword = ‘ubuntu’;

With the coder setup, you can create a MATLAB ROS2 node that can then be used to generate a CUDA ROS node. The below function lidarInfer creates a simple node that subscribes the topic “static_cloud” (which is being published by another node that reads the point cloud file) and publishes the bounding box location and object labels.

function lidarInfer()

 %#codegen

 node = ros2node(“/detector_node”);

 pclSub = ros2subscriber(node, “/static_cloud”,“sensor_msgs/PointCloud2”);

 % Create a bounding box publisher

 bboxPub = ros2publisher(node, ‘/bbox’,‘std_msgs/Float32MultiArray’);

 bboxMsg = ros2message(“std_msgs/Float32MultiArray”);

 % Create a label publisher

 labelPub = ros2publisher(node, ‘/label’, ‘std_msgs/String’);

 labelMsg = ros2message(“std_msgs/String”);

 r = ros2rate(node, 30);

 reset(r);

We set the rate to 30Hz, but this would depend on the hardware you use and the inference speed that can be achieved along with the rate at which the Lidar is publishing.

 while(1)

 [data, ~, ~] = receive(pclSub, 5);

 if ~isempty(data)

 % Using raw data to pass to the predict function since a pointcloud object cannot be passed to a code generation function

 rawData = rosReadXYZ(data);

 [bboxes, scores, labels] = pillarPredict(rawData);

 [~,idx] = max(scores);

 bboxMsg.data = zeros(6, 1, ‘single’);

 labelMsg.data = ”;

 if ~isempty(scores)

 bboxMsg.data = single(bboxes(idx,:)’);

 label_data = cellstr(labels(idx));

 labelMsg.data = label_data{1};

end

 send(bboxPub, bboxMsg);

 send(labelPub, labelMsg);

end

 waitfor(r);

end

end

The main loop shown above reads the point cloud message and then passes it to the pillarPredict function shown below, which loads the trained network and returns the inference results. The results are then passed into the bounding box and label variables before being published.

function [bboxes, scores, labels] = pillarPredict(pcloud_3d)

%#codegen

 persistent mynet

 if isempty(mynet)

 mynet = coder.loadDeepLearningNetwork(‘detector.mat’);

end

 %Converting to pointCloud so the model can detect objects. pointCloud

 %function can be used in code generation

 pcloud = pointCloud(pcloud_3d);

 [bboxes,scores,labels] = detect(mynet,pcloud,‘Threshold’,0.5);

end

For the purpose of code generation, save these functions in separate files. Now, pass the function and coder setup to the codegen function

codegen lidarInfer -config cfg

The generated code is then transferred to the remote device and built before being executed. Now the node runs on the Jetson independent of MATLAB and can be stopped or started again through the device.

Bringing DB-15 to Life with Model-Based Design

Tanya Kuruvilla — Mon, 18 May 2026 12:30:46 +0000

For this week’s blog post, we invited the DuBois Area Robotics team to share their journey and how they used MATLAB and Simulink for the 2025 BEST Robotics Championship. MathWorks is immensely proud of their achievements, and we hope you also find their insights useful! With that, I’ll hand it over to them.

Who We Are: DuBois Area Robotics

We are DuBois Area Robotics, a public high school robotics club based in western-central Pennsylvania. We have been competing in BEST Robotics since 2011 and VEX Robotics since 2019.

For BEST Robotics, we often include a few students from neighboring districts. One of the aspects of BEST that keeps us returning is its company-style structure, which requires us to integrate marketing, engineering, and design into a unified team effort. We also enjoy the challenge of building a competitive robot using only common materials that can be found in a typical hardware store.

Kneeling (L to R): Aubree Evans (CEO, Lead Driver), Aiden Via (Marketing Head)
Standing (L to R, both rows): Ken Evans (coach), Marissa Gilga (Lead Exhibit), Mason Keller, Nic Evans, Derrick Weber (Lead Builder), Bela Keller (Lead Programmer), Peyton Walker (Lead Notebook), Paul McCloskey, Jen Keith (coach), Jack Stringer
Not Pictured: Molly Sensor, Nolen Murray

Our Robot: [DB-15]

This year’s game, Factoids, was built around the concept of training an AI system. The major tasks were to connect a neural network and then train it with valid information, “true factoids”. Towards this end, we designed DB-15 to quickly connect the network and passively collect a large amount of factoids, autonomously sorting the true and false factoids.

DB-15 measures 23” × 23.5” × 23.75” and weighs 24.00 lbs, and is built around five main subsystems that operate under both autonomous and driver control. Its wide wheelbase and large wheels were chosen to improve stability when climbing the ramp and navigating the field.

Factoid Collection & Transport

The robot collects factoids through an intake on the back.
Simply driving over factoids funnels them into the intake and then to the Archimedes screw in the center of the robot.
The Archimedes screw transports both true and false factoids up into the sorting mechanism.

Sorting Mechanism

An infrared sensor and a limit switch are used to differentiate between the factoids.
The IR sensor first detects if there is a factoid in the sorting system.
The limit switch acts as a pressure plate (the true factoids are heavier and will trigger the switch).
True factoids are stored in a magazine until the driver is ready to score.
False factoids are dropped into a storage box (“fake news” box) to prevent recollecting factoids that have already been sorted.
At the end of the match, the arm can open the fake news box.

Arm & Scoring System

The arm was geared for torque to control a heavy tray that can carry all five neural network tiles at once.
The tray is hinged in the middle so it can fold to remain size compliant.
The tray is connected to the arm using 3D-printed team custom parts that serve as a latch, end effector, and release trigger for an arm extension.
Two neodymium magnets on the underside of the arm allow passive collection of true “Wall Street” factoids while actively retrieving a “Library of Content” factoid.

Our Design Process

We began by breaking down the game rules and fully understanding the scoring system. From there, we evaluated the difficulty of each task to develop a realistic strategy, focusing on areas where technical and programming solutions could provide an advantage. Once our strategy was defined, we created a list of core robot systems and their required functions and attributes.

Normally, we divide systems among small groups for parallel brainstorming, but due to our smaller team size, the entire design team worked through each system sequentially. Individual members then took ownership of specific ideas. Competing designs were evaluated collaboratively and integrated into the final robot design. Throughout the process, we consistently looked for opportunities where software could improve or simplify mechanical solutions.

We chose to use Simulink for several reasons:

Simulation was valuable given our 8-week build season, where most of our time is spent constructing the robot and there is limited time for on-robot testing.
It allowed us to develop and test control logic before hardware assembly, reducing the need for extensive debugging later.
We could simulate controller inputs and observe system behavior, giving us feedback on signal flow and control response.
The block-based environment made it more intuitive for modeling control systems and state logic than traditional text-based programming.
Many of the systems on our robot are natural matches for Stateflow charts, and when they are not, we still have the option of using custom functions for text coding or manipulating them with other Simulink blocks.

Our team has been using Simulink since 2016 and prioritizes training at least one new member each year to support knowledge transfer. However, each season remains a learning experience, as most new members have limited prior exposure. While online courses and webinars are available, one of our coaches is pretty good with Simulink, and if we forget something, he can help with the basics or suggest an alternative approach.We also do a lot of online searches and look over Simulink videos from other years to learn about other approaches.

Last year, we were fortunate to have a former lead programmer mentor the team. Our current lead programmer is a junior with one year remaining, and we are actively training a younger member to take over in the future. He began in 6th grade, and Simulink’s visual programming environment made it significantly easier for him to learn core concepts early on.

Our Code Implementation

This year, we faced an additional challenge as BEST transitioned from the VEX Cortex to the VEX V5 control system. It was a late change, and we had to transition from the existing Simulink VEX Cortex support to the VEX V5 support package in Simulink, which required some adaptation. The main issue was the new motor controller (MC55) and missing input ports on the controller block (for simulation). As recommended, we used the V5 Smart Motor Write block to control the MC55, and after some testing, we were able to achieve consistent and expected motor behavior.

The V5 remote control blocks also did not initially support simulation inputs in our workflow. To enable full system simulation, we temporarily integrated Cortex-based blocks during early testing. While this added an extra step, it pushed us to explore Simulink’s signal routing tools more deeply. We discovered the variant source block, which was exactly what we needed. We had already been using signal buses to route some control signals, but the variant source block would solve our problem if we put all control signals into the same bus. From there, we addressed all signal routing and also used a bus for output signals. This made our code more manageable and even made adding new systems easier.

Our drivetrain has become standardized for our team. We typically use a tank-drive configuration with a speed cut controlled by a button latch. We also implement deadbands and a custom MATLAB function to improve low-speed precision by mapping joystick inputs to motor outputs using a non-linear function. This also compensates for signal loss introduced by the deadband block while preserving full output when needed.

Every other system on our robot is controlled using Stateflow charts. We define operating modes that the motors and servos need (such as on, off, forward, reverse), then create states and transitions accordingly. Visually seeing each state activate (or not) during simulation is a great troubleshooting tool. We try to locate tunable parameters outside of Stateflow charts as inputs to make them easier to understand and adjust. Our outputs are usually just control signals. If there are other values that need to be passed to other parts of the code, we tend to write them to memory.

There were a few design issues this year that were either solved or improved through our code. While we developed a low-tech factoid sorter, we found more consistent results with our sensor-based system. Instead of using physical limit switches on the arm, we added a potentiometer and used it to both limit motion and move to predetermined locations. We had also considered using it for PID control, but the arm performed well without it.

One problem inherent to our intake and Archimedes’ screw system was occasional jamming. While we addressed this mechanically, it wasn’t enough. Drivers could reverse the intake manually, but this took focus away from other tasks and reduced the advantage of passive collection. In previous years, addressing this in code would have been difficult, as the older control system provided no motor feedback, and the MC55 motor controllers do not either. Fortunately, we found and used advanced smart motor read/write blocks in Simulink and added them to our V5 library. They allowed us to monitor current drawn from the V5 brain by the MC55s. Using Simulink’s monitor and tune, we found the threshold that was crossed whenever the motor stalled. With this, the robot could detect jams in real time and automatically clear them without driver input.

Code structure overview

We included a controller map and port diagram for reference. We also experimented with dashboard displays once we found the solution to them not working with larger Windows displays.

Variant source and subsystem architecture showing our control and sensor inputs, enabling seamless simulation and hardware deployment.

This subsystem combines the outputs from the gamepad simulator and our simulated sensor values (linked to the dashboard controls) into a single bus. We descriptively named each channel to make using the bus more intuitive. To avoid errors, we used the same signal names as our V5 control signal bus.

Here you can see the advanced smart motor read block. Only the first 2 values are actually output when using the MC55. Our signals are pulled from the control bus. This really cleaned up our code and process.

This is the Stateflow for the intake and Archimedes’ screw. To constantly monitor the system for jamming, we used a parallel Stateflow structure. (Parallel structure essentially allows multitasking.)

The arm performed numerous tasks, both autonomously and with driver input. Thus, it required quite a few inputs and parameters. The custom function only sends a true value after a very specific combination of joystick movements is held for a predetermined time.

This section controls the position of our factoid dispenser ramp. Adjustable values are clearly noted outside of the Stateflow where they can be adjusted. The Stateflow chart automatically moves the ramp from the starting position to the lower scoring position as soon as the intake is started. This prevents driver error as the two positions are hard to discern from across the field

Here is our submission to the Simulink Design Award:

Highlights from the Denver BEST Regional Championship

DuBois Area High School competes at the local Grove City Competition each year. This event qualifies teams for the Regional Championship. We did quite well this year, winning a number of awards and securing our place at regionals.

Our regional competition is the Denver BEST Regional, which was held in Wichita, Kansas, this year. There, we faced the top teams from seven other regionals. Our team’s work was recognized with several awards, including 2nd place in the Overall BEST award and winning the Simulink Design Award. We are especially proud of these achievements, as we are one of the few public high schools competing at both our local and regional events. Additionally, our 2025 team was our smallest ever, and each member worked hard to help overcome that challenge.

Simulating a Hybrid PVT-Chiller System for Maximum COP in Jordan’s Hot Summers

Tanya Kuruvilla — Mon, 04 May 2026 13:06:55 +0000

For today’s blog, we’re joined by Dr. Heba Al Zaben, Eng. Adham Yacoub, Eng. Waleed Mohamadieh, Eng. Omar Faire, and Eng. Khaled Al Halab from AlHussein Technical University, whose project earned second place for Best Use of MATLAB & Simulink at the Twelfth National Parade for Technology Competition. They share how they modeled and optimized a hybrid PVT-chiller system to improve cooling efficiency in Jordan’s extreme summer climate – over to you.

Introduction

The subject of this study is the development and analysis of an air-cooled chiller integrated with photovoltaic-thermal (PVT) system, as Jordan experiences very hot summer climate conditions (with mean daytime temperatures around 30–35 °C and peak temperatures often exceeding 40 °C) and has a demand for sustainable energy solutions. The goal of this study was to improve overall energy efficiency by utilizing both electrical and thermal output of the PVT panels to satisfy the high cooling demand of the summer climate. To simulate the entire system, a detailed MATLAB/Simulink model was developed by implementing real-time climatology data for Jordan. This research further explored the system configuration parameters by focusing on the parameters that have the greatest affect on hybrid system performance. Drawing on past research studies and technical studies, the study discussed the effects of PVT panel’s tilt angle; cross-sectional area of mist nozzles used for surface cooling; mass flow rate of cooling mist; and mass flow rate of air over the PVT surface. The theoretical study then presented the effects of each of the variables to understand the distinct and combined effects on electrical efficiency, thermal efficiency, and cooling performance through expanded simulations.The goal of the analyses was to optimize the configuration of the system in order to achieve maximum energy output performance.

Figure 1: Simulink model of the proposed hybrid PVT system integrated with air-cooled chiller, pre-mist system, and heat exchanger.

Figure 2: Mechanical outlines of the existing PV system with air-cooled chiller (Case 1) and the proposed PVT system integrated

with air-cooled chiller, pre-mist system, and heat exchanger (Case 2).

How was the project developed?

The administrative building of the Special Communications Commission in the capital Amman was chosen as a case study where local climate and energy data specific to the selected location was analyzed.Our approach included the following:

Designing a detailed Simulink model available via MATLAB Online of the hybrid proposed system
Modeling each subsystem; PV panel, thermal collector, mist cooling, and air-cooled chiller
Integrating real-time weather and solar irradiance data into the system from Nasa Power data website.
Utilizing the CoolProp library for an accurate calculation of fluid thermodynamic properties, which enhance the precision of thermal and cooling subsystem simulations.
Each subsystem was initially analyzed independently, after which all subsystems were integrated to form the complete representation of the proposed hybrid system.

The Role of MATLAB/ Simulink

MATLAB and Simulink were essential at every stage in this project, as the dynamic behavior of energy flow, cooling demand, and thermal output was modelled in real time using Simulink. The precise geographic coordinates of the chosen case study building were synchronized with real-time temperature and solar radiation data obtained from NASA POWER data website, as this method made sure that the effects of climate change on the PVT system’s and the air-cooled chiller’s performance were accurately represented, also the graphical results made it easier to analyze system behavior under variable climate conditions and performance improvements were calculated using a variety of statistical tools, and graphs of electrical and thermal efficiency were displayed. We were able to create a dependable and scalable hybrid energy model by seamlessly integrating electrical, thermal, and mechanical subsystems using Simulink’s modular block approach.

Building on this technical foundation, the project’s robust simulation and analysis capabilities were recognized on a broader stage. Our team had the privilege of showcasing this hybrid PVT system at the 12th National Technology Parade in Jordan, an event that brings together innovative engineering solutions from across the kingdom. By leveraging MATLAB’s advanced documentation and specialized toolboxes, we could validate our findings against industry standards, ensuring that our model remains a viable reference for future sustainable energy research. For more highlights and updates from the competition, you can visit the official National Technology Parade Facebook page.

Results:

Figure 3: Temporal variation of PV panel cell temperature.

Figure 4: Temporal variation of thermal efficiency.

Figure 5: The COP variation for the baseline (without mist) and hybrid case (with mist and air-cooled chiller).

As shown in Figure 5, the coefficient of performance (COP) improves between hours 9 and 15 due to the operation of the pre-mist system, with an increase of about 12.32% compared to the baseline case. Additionally, the COP in the ‘after’ case remains non-zero for an extra hour due to the effect of the pre-mist cooling, which maintains lower operating temperatures and allows the system to continue operating efficiently for a longer duration.This result is close to findings in similar studies, which reported a 14.54% improvement. The slight difference is due to the selection of parameters to balance electrical efficiency, thermal efficiency, COP, and water consumption. Furthermore, Figure 3 shows that the PV panel temperature decreases by 29.3% in Case 2, leading to an increase in electrical efficiency of 9.48% as illustrated in Figure 4.

Conclusion

The hybrid PVT-chiller system is a promising integration of renewable energy and cooling technologies, especially in hot climates such as Jordan’s. Through MATLAB and Simulink, we were able to model, simulate, and optimize a hybrid PVT system that can significantly reduce cooling costs while boosting solar efficiency. The following results were obtained throughout the course of our work:

The coefficient of performance (COP) improved by 14.32%.
The temperature of the solar PV panels decreased by 29.3%.
Electrical efficiency improved by 12.1%.
The thermal efficiency of the proposed hybrid system reached 40.3%.
The CO2 reduction was approximately 5.85 TN/Year.

The most relevant limitation of this system is the water consumption rate of 235 liters/day. Especially in a climate as dry as Jordan’s, this is not sustainable. Our project demonstrates the potential of simulation tools to translate engineering concepts into practical and sustainable solutions. We are sharing this work and look forward to contributing to further innovations in hybrid PVT systems worldwide.

Looking Ahead

Our next objective is to move from simulation to practical implementation, building on the modelling stage. In order to accurately depict energy demands and cooling requirements, the system was designed using data from a real commercial building in Amman, Jordan, which included real climate and load conditions.

The high water consumption of the mist cooling system integrated with the PVT unit was one of the main constraints we faced during the analysis. In Jordan’s water-scarce environment, the current model’s estimated daily water usage of 235 liters is unsustainable for large-scale or long-term operations. One of the main objectives for future development is to lower this consumption by using smart control algorithms, intermittent misting, or other passive cooling techniques. In the next phase of our work, we plan to:

To improve system reliability and lessen dependency on the grid during peak hours, incorporate battery storage into the load shifting model.
Create and test AI-based control algorithms to forecast cooling demand, optimize energy flows, and dynamically modify chiller and misting operations in response to current environmental conditions.
Work with regional academic and industrial partners to advance experimental prototyping with the goal of validating the model in real-world settings.
Look into opportunities for technology transfer and commercialization, particularly through collaborations with Jordanian energy efficiency and sustainability programs.
Examine the system’s payback period and long-term environmental benefits, as well as its economic viability with lower water consumption.

Figure 6: Our team was awarded second place for Best Use of MATLAB & Simulink by MathWorks at the Twelfth National Parade for Technology Competition.

How Team Endurance Racing Engineered a Winning Electric BAJA Powertrain Model in Simscape

Tanya Kuruvilla — Mon, 20 Apr 2026 15:48:52 +0000

In today’s blog, we are joined by Team Endurance Racing from Vishwakarma Institute of Technology, Pune, who placed 1st in the BAJA SAEINDIA: MathWorks Electric Powertrain Simulation Challenge 2026.

Who We Are and What We Achieved

We are Team Endurance Racing from Vishwakarma Institute of Technology, Pune, a student motorsports team focused on electric mobility and system-level vehicle engineering. At eBAJA SAEINDIA 2026, we secured an Overall 5th Rank and achieved 1st Rank in the BAJA SAEINDIA: MathWorks Electric Powertrain Simulation Challenge 2026. This blog presents our approach to the simulation challenge, covering our modeling assumptions, battery pack development, powertrain subsystem implementation, simulation scenarios, and the key engineering insights we gained.

Team Endurance Racing with the Winning Car

Understanding the Problem Statement

The BAJA SAEINDIA: MathWorks Electric Powertrain Simulation Challenge 2026 required teams to simulate and analyze an electric powertrain for an all-terrain vehicle (eBAJA) using MATLAB and Simulink. A reference Simscape model of a generic electric ATV was provided as the starting point, and teams were expected to adapt it to align with their own competition vehicle concepts.

Figure 1: Reference electric BAJA model

The reference model simulated a basic electric ATV with a battery, single-motor rear-wheel drive, and a set drive cycle for performance testing. However, it lacked the actual architecture, battery setup, and specific performance details of a real BAJA electric vehicle.

The main gaps between the template model and a real eBAJA vehicle were:

– The battery was modeled as a simplified source rather than a structured pack with series-parallel cells and realistic voltage/current behavior.

– The powertrain architecture and parameters were generic and not tuned to any specific team vehicle.

– Model fidelity was limited for tasks such as realistic range estimation, transient response analysis, and component sizing.

The engineering intent of the challenge was to encourage teams to improve model fidelity by implementing a realistic battery configuration, refining the powertrain to match their design intent, and achieving accurate tracking of the prescribed drive cycle. Simulation accuracy directly affects real vehicle design because it allows teams to evaluate energy usage, thermal and electrical loading, and performance trade-offs before making hardware decisions.

Vehicle & Powertrain Assumptions

The simulated vehicle represents an electric BAJA all-terrain vehicle (eBAJA ATV) intended for off-road endurance and dynamic events. To keep the model generally applicable while still realistic, we used generic but representative parameter values within realistic bounds.

Key assumptions used in the model include:

Conceptually, the fixed gear ratio and transfer case are chosen such that the motor can operate in an efficient speed range near its rated speed when the vehicle is around the 60 km/h target, while still providing adequate wheel torque at lower speeds for launch and off‑road operation in both RWD and 4WD modes.

Battery Pack Modelling Approach

The default battery block in the reference model acted as a simplified equivalent source and did not represent the internal structure, voltage behaviour, or realistic current limits of an eBAJA battery pack. This limited the ability to study cell‑level effects, voltage sag under load, and SOC evolution during transient events such as acceleration and hill climbs.

To address this, we used the Battery Builder app to create Simscape battery models with a nominal voltage of about 72 V and a usable capacity of 80 Ah, representative of an eBAJA‑level system. Voltage and capacity values were selected to support endurance‑style operation while maintaining reasonable weight and packaging for an off‑road ATV. The pack was based on cylindrical lithium‑ion cells with the following representative specification:

Key parameters emphasized in the battery model included:

State of Charge (SOC) estimation using current integration (coulomb counting).
Current limits to capture behaviour during peak load conditions.
SOC‑dependent internal resistance to model voltage drop (sag) at higher currents.
Monitoring of terminal voltage at pack or module level to ensure it remained within safe operating limits.

By incorporating SOC‑dependent open‑circuit voltage and internal resistance behaviour, the battery model produced realistic voltage responses during high‑demand segments, which directly influenced available motor torque and overall vehicle response.

Figure 2: Battery pack

Motor Parameter Updates

The design retained the single-motor architecture but updated several key motor-related parameters to accurately represent a typical eBAJA-class traction motor. The model included the following specifications:

A fixed gear ratio of 5, selected to provide a suitable reduction for off-road operation.
Maximum torque set at approximately 65 N·m.
Maximum power specified around 9 kW.
An overall efficiency estimated at 95%.
An efficient operating point defined at 5500 rpm with a torque output of 18 N·m.

These calibrated parameters allowed the generic motor to emulate the behavior of a realistic eBAJA traction unit while maintaining compatibility with the DC bus voltage and the overall template architecture.

Controller Tuning and Strategy

After updating the motor parameters, the control strategy was refined to ensure stable torque delivery and precise tracking of the drive cycle. Tuning efforts were concentrated on achieving smooth acceleration without oscillations, maintaining stable velocity tracking across varying load conditions, limiting peak current during periods of high demand, and preventing abrupt torque transitions that might result in unrealistic acceleration spikes.

Subsystem Interaction and Simulation Flow

The simulation established a clear chain of subsystem interaction: the battery supplied DC power to the motor drive; the drive commanded motor torque in response to torque inputs; the motor transferred this torque through the fixed gear reduction and driveline to the wheels; and the resulting vehicle speed and acceleration were fed back to the controller for closed-loop regulation.

Figure 3: Powertrain model

Simulation Scenarios & Results

The model was tested using a drive cycle with acceleration, cruising, hill-climb, and braking segments to assess system response under varying loads and speeds. Scenarios included initial acceleration, steady cruising, and increased resistance. Analyses focused on vehicle speed vs. time, battery SOC, current, and power flow.

Figure 4: Simulation results

Simulated vehicle velocity closely followed the reference cycle, with only minor deviations in rapid transitions, demonstrating effective speed control. Battery SOC declined gradually, showing adequate capacity for the load. Peak current and power appeared during acceleration and resistance phases; cruising used less current, indicating efficient power use. Battery voltage stayed within safe limits, with expected minor dips during high-current events. Overall, the results confirmed stable operation and suitability for further analysis.

Key Design Insights & Learnings

The simulation revealed key design trade-offs: gearing impacts both top speed and low-speed torque; battery resistance and state-of-charge affect voltage and motor torque, so realistic modeling is crucial for accurate performance estimates; controller settings heavily influence tracking quality and current spikes. Validating assumptions proved essential—optimistic battery models and loose control gains led to misleading results, but iterative refinement improved accuracy and understanding. These insights show that even moderately detailed models can help student teams make more informed design choices than relying on heuristics or trial-and-error.

How Simulation Helped Us Think Like Engineers

________________________________________________________________________________________________________________________________________

“MATLAB and Simulink fostered a systems-thinking approach to powertrain design, where the battery, motor, controller, and driveline were treated as interconnected subsystems influencing overall vehicle performance. This approach helped us structure our models into well-defined subsystems with clear interfaces, validate model behavior against expected trends and reference drive cycles, and iteratively refine key design parameters such as battery capacity, gear ratio choices, and control gains based on simulation evidence rather than assumptions.”

________________________________________________________________________________________________________________________________________

What’s Next for the Team

Our eBAJA vehicle on track

We aim to test more drive cycles, including endurance and high-speed scenarios, while improving loss and thermal modeling for better efficiency analysis. Matching simulation results with real vehicle data is a priority, so we’re refining assumptions to minimize discrepancies. We’re incorporating Kalman-filter-based estimators, advanced controllers, and additional input signals to enhance SOC and range predictions. Precise PMSM motor modeling and HPPC battery tests will help align simulated and physical performance. This foundation will enable future team members to explore new powertrain layouts, control strategies, and battery options through ongoing simulation-based development.

From Real Roads to Real Simulations: How Team TwinX Won Smart India Hackathon 2025

Tanya Kuruvilla — Mon, 06 Apr 2026 04:23:09 +0000

The Smart India Hackathon (SIH) is a nationwide initiative aimed at engaging students in addressing some of the most pressing challenges of everyday life. Established to promote a culture of innovation and practical problem-solving, SIH serves as a dynamic platform for students to develop and showcase their creative solutions to real-world issues. Since 2019, MathWorks has partnered with SIH, guiding students through problem statements, webinars, and mentorship as they develop real world solutions.

Driving on Indian roads often demands constant alertness, what appears smooth and open can suddenly turn into a mix of potholes, unexpected barricades, roadside parking, and vehicles weaving in from every direction. Many traffic simulation tools, however, are built around orderly lanes and consistent driving patterns. Addressing the gap between these assumptions and real road conditions became the focus of Team TwinX’s work and shaped the solution that led to their win.

In this post, we are excited to feature Team TwinX from K.K Wagh Institute Of Engineering Education and Research, Nashik, the winners of the Smart India Hackathon (SIH) 2025 MathWorks problem statement. They share their journey, what they learned through the process, and how they approached the challenge.

Team TwinX: Aakanksha Sutrave, Anurag Mohod, Abhishek Ahirrao, Vaishnavi Pawar, Sagar Sahu, Chanchal Mahalpure, Prof.Dr.Vilas Patil (Mentor).

The Challenge That Inspired Us

During the problem statement selection phase, we explored multiple options across domains. Instead of choosing something that sounded easy or familiar, we focused on problems that reflected real, visible challenges. When we came across the statement related to accelerating road network modelling for Indian traffic simulations, it immediately stood out because it aligned with everyday experiences and had strong real-world relevance. We chose this problem because it addressed a gap we could clearly observe. Indian roads are complex, dynamic, and unpredictable, yet most simulation tools are designed for ideal conditions. The problem allowed us to work at the intersection of technology, infrastructure, and real societal impact. More importantly, it offered room to innovate rather than simply implement a known solution.

Breaking down the Problem by ‘Design Thinking’ Approach

At first, the expectations felt high and the problem space broad, so our early discussions explored multiple directions before we identified what truly mattered. Once we broke the challenge into smaller components and defined the core problem, our ideas aligned and the solution began to take a clear, systematic form.

Empathize: We observed that most traffic simulation tools are built for ideal roads, while Indian roads involve potholes, temporary barricades, mixed traffic, and unpredictable movement, making realistic modelling difficult for planners and researchers.
Define: We identified that the core problem is not the lack of tools, but the heavy manual effort and absence of Indian-context awareness in existing road network modelling workflows.
Ideate: We explored how real maps, simple text inputs, and automation could be combined to reduce effort while improving realism.
Prototype & Test: We built and refined small functional modules, continuously checking whether the output truly reflected Indian road conditions and reduced user workload.

Preparation from Internal Hackathon to Winning the Grand Finale

August – September: The Beginning

From August to September, our journey started with the Team formation and internal rounds of the Smart India Hackathon on campus. This phase was less about having a perfect solution and more about forming the team having right learning mindset along with understanding the problem, exploring ideas, and most importantly, understanding each other as a team. We focused on building trust, identifying strengths, and seeing whether we could work together effectively when the solution itself was still unclear. The best thing we decided as a team was “Identifying and then playing on strength of each member”.

October: Finding the Right Direction

October marked a turning point when our idea was officially submitted on the SIH portal. The MathWorks problem statement pushed us to think beyond assumptions and focus on real Indian road conditions. This phase involved a lot of trial and error some ideas worked, others didn’t. But we keep working day and night on finding the right solution. All the late-night meetings pushed us to more clarity and practicality which mattered more than complexity. And by the end of the month, our solution had taken a clear and meaningful shape.

November: Validation and Refinement

Being selected as SIH 2025 grand finalists in November gave us confidence and a sense of responsibility. An expert working in same field was provided to us as a mentor for ‘mentoring session’ from ‘MathWorks’ as per SIH guidelines. This mentoring session help us to understand whether our approach was on the right track or not, while also pushing us to prepare for deeper scrutiny. This month was spent refining the concept, improving usability, and balancing technical depth. Every discussion helped us simplify and strengthen the solution.

December: The Grand Finale

The grand finale on December 8-9 was intense and unforgettable. We followed a simple rule in each judging round “get feedback from judges in mentoring round and modify the solution till upcoming evaluation round”. Over 36 hours, despite exhaustion and pressure, we stayed focused and motivated to complete every task given by the judges. We worked for 34-35 hours in the 36 hours of hackathon. The pressure was high, but the environment pushed us to think clearly and communicate effectively. The journey from confusion to clarity felt complete at this stage. When we were announced as winners, it wasn’t just joy it was relief, gratitude, and pride in the months of learning, teamwork, and belief that brought us there.

Our Solution

Our solution is a software-based workflow that converts real-world Indian road data into complete, simulation-ready traffic scenarios with minimal manual effort. We start by importing real maps using OpenStreetMap or simple coordinate-based searches, which form the base of the road network.

On top of this, we automatically place vehicles and other pedestrians, assign realistic Indian driving behaviors, and allow users to modify distances and speeds through an easy-to-use interface. Scenarios can also be generated using plain text inputs, where AI-assisted logic helps create MATLAB-compatible scripts for traffic simulations.

To improve realism, we integrate Indian-specific road assets such as potholes, barricades, road damage, and construction elements. We also support creating 3D assets from 2D images and maintaining a reusable asset library for repeated use.

Weather conditions are added based on geographic location, allowing simulations to reflect real environmental conditions. Finally, the entire scenario can be exported directly to Driving Scenario Designer, RoadRunner, and Simulink for further editing, sensor integration, and high-fidelity 3D simulation.

Our approach significantly reduces manual modelling time while ensuring simulations reflect the actual complexity of Indian roads.

Why MATLAB Became the Backbone

MATLAB was the backbone because it allowed us to build an end-to-end workflow on a single platform. Using MATLAB, we processed real map data, generated traffic scenarios, assigned driving behaviors, and directly connected the output to Driving Scenario Designer, RoadRunner, and Simulink.

Instead of switching between multiple tools, we automated the entire pipeline from OSM import and scenario logic to 3D simulation and weather integration within the MathWorks ecosystem. This made our solution technically consistent, easier to scale, and practical for real users such as traffic planners, researchers, and simulation engineers.

Lessons Learned During This Journey

A week before the SIH Grand Finale, We the Team TwinX sketched a handmade trophy and winning cheque not to predict the outcome, but to keep ourselves motivated and focused on taking one step at a time. As first-time participants, that belief, along with teamwork and consistency, turned SIH into more than a competition it became a lesson in clarity, coordination, and trusting the process.

Winning, for us, was never the starting goal, it naturally followed the lessons we gathered along the way. We learned that pivoting our ideas when needed, while staying committed to the larger objective, often leads to better outcomes. More than individual talent, it was collaboration that carried us forward. We also realized that steady, consistent effort sustains success far better than short bursts of intensity. In the end, the award marked a milestone, but it was the journey itself that truly shaped who we are as engineers.

RoboSub Simulation Environment

Tanya Kuruvilla — Mon, 23 Mar 2026 16:45:39 +0000

In today’s blog, Abhishek Shankar from the Student Programs team at MathWorks introduces a newly released underwater RoboSub simulation environment built with Simulink, Simulink 3D Animation, and Unreal Engine that enables teams to test algorithms and accelerate development. Over to you, Abhishek…

Underwater robotics has been on the rise over the past few years, which reflects the rise in robotics in general. While it might appear to be a niche area, there are several areas in science and engineering that benefit from autonomous underwater vehicles (AUV) such as marine biology (collecting samples, tagging endangered animals, etc.), ship inspection and maintenance, deep sea exploration, military, etc. Seeing the potential impact of AUV is such areas, there have been several competitions to push the development of AUV’s. One such competition is RoboSub – an underwater robotics competition held by RoboNation. The competition pushes the participants to develop vision, navigation and control systems to perform several challenging tasks such as object avoidance, object detection, station keeping, localization and so on. The challenges come in various forms when underwater – lack of GPS is a main factor since the AUV must now use only on board sensors to localize itself, no help from satellites. Vision can also be tricky underwater due to distortions and reduced visibility the deeper the AUV dives. Further, the cost of development and testing increases quickly with the need of water proof bodies, underwater thrusters, expensive sensors such as DVL’s (Doppler Velocity Logger) and access to a pool or a lake for testing. Weather also plays a role as teams in the northern hemisphere have to deal with frozen lakes during winter, which reduces testing time by up to 4 months. To address some of these issues, we have now released a virtual environment to simulate the tasks at RoboSub. Simulation helps identify issues early, reduce development time, cost, and risk in the model-based design workflow. The environment is built in MATLAB 2025b and uses Simulink 3D Animation for photorealistic visualization while the physics are simulated in Simulink. The virtual environment can be cloned from this repository, and will be used for a virtual RoboSub competition in 2026.

Model Overview

The virtual environment has two main components. The Simulink model that takes in the AUV parameters and simulates the physics (left part of the above image) and a Unreal Engine based visualization environment for visualizing the AUV (right part of the image above).

Simulink Model

The Simulink model is at the heart of the virtual environment. The AUV block, which is a masked subsystem, takes in the properties of the AUV such as its mass, inertia, volume, thruster positions, sensor positions and actuators to simulate the physics of the body. The model calculates the AUV dynamics based on hydrostatic and hydrodynamic forces and computes the forces and moments from the thrusters. These are then fed into a 6-DOF block that computes the vehicle states (position, velocity, orientation, angular velocity) at each time step. The model breakdown is shown in the image below.

The sensor block takes in the robot state and simulates the reading of common underwater sensors such as IMU, DVL and camera. More sensors can be modeled as and when required by the user. The sensor readings are then the outputs from the AUV block. The noise profiles of these sensors can be edited to match the sensor the user is using to make the simulation more realistic and potentially reduce the sim-to-real gap. The actuator subsystem simulates the two main actuators used in RoboSub – torpedoes and marker dropper. These subsystems are shown below. The model simulates the physics of these objects by sampling the position of the AUV at the time of firing and appending the position based on the physics of the object.

The visualization block ties it all together by visualizing the AUV’s pose and states in a photorealistic environment built using Simulink 3D Animation which uses Unreal Engine in the background. The virtual environment is set to an Olympic sized swimming pool to reflect the competition environment but users can design their own environment based on their needs. In the next section, I will talk more about the photorealistic 3D environment.

Visualization

Simulink 3D Animation provides the user with the option to build their custom scene using Unreal Engine (UE). In this virtual environment, the visualization environment is an Olympic sized swimming pool. The features on the pool are modified using UE actors. The water is modeled using the experimental water plugin and the lighting is adjusted through custom shaders to make the underwater view realistic. Below, you can see a gif of the environment and how it interacts with the AUV’s with a positive buoyant force.

The environment also consists of other artifacts that relate to the competition such as navigation gates, torpedo target boards, marker target and octagon. These will further be modified to reflect the changes for the 2026 competition.

More information on the model and the blocks within it can be found in this detailed document in the GitHub repository.

Simulation

Now that we have an overview of the simulation environment, I can show how a simulation in this environment looks like. For this, I’ll take the task of navigating through a gate and firing a torpedo at the target board. For this example, I am assuming that the location of the gate and the board are known but for the competition, navigation will be based on vision. For the tasks, there is a Stateflow chart managing the AUV’s high level execution and individual PID’s to control the AUV and keep it close to the planned path. The Stateflow and control system is shown in the image below.

The gif below shows the AUV navigating and firing a torpedo at the board – a common task at RoboSub. Further, it is easy to connect this environment to ROS using our ROS toolbox, which allows the user to publish sensor messages through the ROS publisher block and subscribe to thruster inputs and torpedo or marker commands. This lets the user easily connect to an external navigation or control algorithms and visualize the simulation in Simulink. More information on the simulation interface and it’s ROS interface can be found in this video with RoboNation.

Conclusion

This blog goes over the newly released virtual environment for RoboSub using Simulink 3D Animation. The model simulates the physics of the user’s AUV closely based on the inputs such as mass, inertia and coefficients of drag. It also provides rich sensor data from various sensors used in underwater navigation. Two actuating systems are simulated – torpedoes and marker dropper which would help teams test these tasks out in simulation before deploying in the competition. MathWorks also offers a range of other products to help design autonomous behaviors. For example, Stateflow makes it easy to design state machines (a common decision making architecture), navigation and path planning capabilities using our Navigation toolbox, etc. These products are included in the competition license that is complimentary to all RoboSub participants! And finally, MathWorks will be launching a Virtual RoboSub Challenge to encourage more teams to test and validate in simulation and give them a chance to win up to $1000. So if you have registered for RoboSub, try to participate in the virtual challenge to test your algorithms in simulation and to stand a chance to win the prize money. Good Luck!

MathWorks Research Internship Experience: Divyamaan Sahoo

Tanya Kuruvilla — Mon, 09 Mar 2026 11:53:07 +0000

Today we’re talking to Divyamaan Sahoo, who participated in the Development Collaborative Research Grant program at MathWorks, which supports academic research aligned with development priorities for MATLAB and Simulink. Through the program, he contributed to the development of the Acoustic Library for Simscape, helping advance tools for modeling acoustic systems and transducers while supporting research and education in physical acoustics.

Meet Divyamaan Sahoo

My name is Divyamaan Sahoo and I am a puppeteer, sound artist, mathematician, and electroacoustic engineer. I am from Calcutta, West Bengal, India. I am currently pursuing my Ph.D. in Acoustics at The Pennsylvania State University in State College, PA. My area of study is physical acoustics, transducers and signal processing. I am interested in sound, acoustics and pure mathematics (number theory, geometry, and topology).

What’s your research about?

I am part of a team that is developing, testing, and documenting the Acoustic Library for Simscape, a foundational project that enables modeling acoustic phenomena using “lumped” elements. In broad terms, it is a method to break down a complex physical phenomenon into separate domains—electrical, mechanical, thermal, etc.—and describe the phenomenon in each domain using three elementary relationships: x is proportional to y, OR x is proportional to the derivative of y, OR x is proportional to the integral of y. The constants of proportionality here are denoted “R”, “L”, and “C” and x and y are defined such that their product x times y equals power. In the electrical domain, this describes the ubiquitous RLC circuit, where x is voltage and y is current. The fundamental idea here is that it is possible (and often beneficial) to define “R” “L” “C” elements in other physical domains. The reason is, instead of solving systems of (coupled) differential equations, one can draw analogous “R” “L” “C” circuits and evaluate the musing circuit analysis techniques. This is what Simscape achieves at its core.

Acoustic “R” “L” “C” circuits have been around for many decades and their inclusion in Simscape has been especially advantageous for studying and prototyping transducers .Dr. Stephen Thompson (my mentor and advisor) has been using these components to teach advanced transducer courses at Penn State with great success.

A simple example of how this is useful in a real-world application is the modeling of loudspeakers to determine the design and dimensions of their enclosures. Currently, the library highlights microphones, loudspeakers, and examples such as the multidomain modeling of earbud headphones inserted in a human ear. However, any physical acoustics problem using lumped elements can be modeled using this library. I anticipate that such a tool will have a tremendous impact on both industrial and educational contexts worldwide.

For someone who remains deeply curious about the art and science of transducers, it has been an especially rewarding experience to contribute to the Simscape Acoustic Library and have MathWorks support its development through the Development Collaborative Research Grant (DCRG) program. The library we see today is the result of Dr. Thompson’s research (and his advisor’s!) and is made possible thanks to cohorts of acoustics graduate students and faculty members at Penn State who have been using and refining these blocks over the years.

The Research Internship Experience

The primary goal of my internship has been to collaborate with Signal Processing & Communications (Audio Toolbox team) and Control Design Automation to build a support package for the Acoustic Library for Simscape by creating documentation for all components, maintaining equivalent analogous circuits of all blocks, conducting preliminary unit testing, developing Simscape code to specified conventions, and devising a unique set of icons for the library.

So far I have established a solid theoretical foundation for the library and internal design documentation for each component, redesigned icons for all components, maintained an exhaustive list of all equivalent circuits for each block in the library, and delivered a series of three in-depth lectures providing an overview and background to the Acoustic Library, distilling the concepts necessary to model acoustic systems using Simscape. I also conducted preliminary unit tests, identified bugs, and maintained a faithful record of meetings with various team members and stakeholders to ensure a smooth development workflow.

The result has been an in-depth and comprehensive literature review of all canonical acoustics references, including numerous critical papers and unpublished texts on transducers to ensure that the underlying physics of each component and their analogous circuit representations are accurate. This internship has been instrumental in strengthening the foundation of my Ph.D. research project on the R&D of novel transducers and signal processing algorithms for hearing aids.

What’s next?

Thanks to the encouragement of my team, I recently submitted an abstract to present our research at the upcoming Acoustical Society of America/ Acoustical Society of Japan conference this December, for the special session “Acoustics in Multiphysics Measurements: Modeling and Applications,” hosted by the Physical Acoustics Technical Committee. We hope that this abstract will be accepted!

I hope to continue working on the DCRG research project as part of my Ph.D. dissertation research in the Fall and contribute toward the success of the Acoustic Library release. It would be a dream to pursue a full-time role at MathWorks, focusing on R&D and technical writing for acoustics/audio.

MathWorks Research Internship Experience: Tingkai Li

Tanya Kuruvilla — Mon, 23 Feb 2026 13:26:19 +0000

Today we’re talking to Tingkai Li, who participated in the Development Collaborative Research Grant program at MathWorks, which supports academic research aligned with development priorities for MATLAB and Simulink. Through the program, he advanced battery health estimation and degradation forecasting while helping translate research into practical industry tools.

Meet Tingkai Li

My name is Tingkai Li, born and grew up in Quanzhou, China. I hold my BS in mechanical engineering from Iowa State University, and I’m currently a 4th year PhD student in mechanical engineering at University of Connecticut. I’ve interned at MathWorks for summer 2024 and summer 2025, both times at the Apple Hill campus.

What’s your research about?

My research falls under the general topic of prognostics and health management (PHM) for lithium-ion batteries, in which I specialize in lifetime prediction, capacity fade forecasting, state of health (SOH) estimation, and degradation diagnostics.

Lithium-ion batteries have been widely used all over the place in our daily lives. Similar to other engineered systems and even human beings, lithium-ion batteries age gradually over time, both naturally and by usage. Research in PHM for lithium-ion batteries focuses on delivering a better understanding and a more accurate representation of the battery’s internal state, as well as a forecast of future degradation. All these advancements help with a better prediction of the performance of both batteries themselves and the systems relying on them for power supply by identifying potential failures that may cause chaotic accidents and by optimizing the maintenance scheduling for the systems.

The Development Collaborative Research Grant (DCRG)project I’m part of focuses on developing more accurate, robust, and trustworthy approaches to estimate the state of health (SOH) and forecast future degradation under varying usage conditions for batteries. My role in this project includes designing and running battery aging tests, eventually developing better approaches for SOH estimation and degradation forecasting.

The Research Internship Experience

For my internship I was located in the Apple Hill campus, working closely with the Predictive Maintenance Toolbox team to explore and develop some functionality for extracting features from battery usage data( e.g., charge/discharge measurements, electrochemical impedance spectra, etc.)for various data-driven battery modelling workflows (e.g., state of health estimation, remaining useful life prediction).These projects align very well with what I’ve learned and developed in my research, allowing me to bring my knowledge to customers by providing such features in MathWorks’ ecosystem.

So far, I have developed several prototype and examples during my two internships, some of which are expected to be shipping out in the future releases. One of my projects during my internship in Summer 2024 has been available in R2025a as an example (Automatic Data Segmentation and Feature Extraction for Reference Performance Test in Lab-Measured Battery Aging Data – MATLAB & Simulink).

What’s next?

I’ll go back to school and continue working on both the DCRG project and my other projects. With an expected graduation on Spring 2026, I am considering positions in the industry where I can leverage my domain knowledge in battery modelling and a broader context of AI application in engineering.

How Future Engineers Use MATLAB and Simulink at World Robot Olympiad

Tanya Kuruvilla — Mon, 09 Feb 2026 15:27:30 +0000

MathWorks began partnering with the World Robot Olympiad (WRO) last season (2025) to support student teams using modeling and simulation as part of their robotics workflows. As part of this partnership, we introduced the MathWorks Modeling Award, which recognizes teams that demonstrate creativity and technical skill using MATLAB and Simulink in their project designs 

The Pythons, winners of the MathWorks Modeling Award in the Future Engineers category, used MATLAB and Simulink to support their autonomous driving solution. The Future Engineers category is designed for older students (ages 14–22), with a challenge that changes every 3–4 years and currently focuses on building a robot with a steering drive that can navigate a track autonomously. 

For today’s blog, we’re joined by The Pythons, who will share their robot design and describe how MATLAB and Simulink supported their development process. Over to you… 

Introduction

We are The Pythons, an Egyptian robotics team founded by Innova STEM Education Co. in 2016 and based in Alexandria, Egypt. This was our first time participating in the World Robot Olympiad (WRO), and over the years we have also taken part in several local and international robotics competitions, including RoboCup Junior. Our goal as a team is to contribute to the robotics field and explore how robotics can be used to improve people’s lives through hands-on engineering challenges.

Meet our Robot

To tackle the autonomous driving challenge, we designed a robot centered around the Raspberry Pi 5, which handles all major processing tasks. Our system is responsible for:

Calculating deviation from center position using a sensor fusion algorithm that combines data from ultrasonic sensor and heading information calculated from MPU6050 sensor.
Issuing commands to motors to move according to data.
Detecting blocks and orange and blue lines using a custom trained YOLOv8 model running on a Google Coral Edge TPU.

Discovering the MathWorks Modeling Award

We had heard of MATLAB and Simulink, however we never had the opportunity to learn it but all that changed when we heard about the MathWorks Modeling Award from our national organiser.

After exploring the learning resources provided by MathWorks for WRO, including their official WRO webinars, along with the MATLAB and Simulink Onramp courses, getting started became much easier than we expected. These resources helped us understand how to use modeling and simulation tools effectively and showed us how they could take our robot design to the next level.

Simulate, Test, Improve: Our Implementation Approach

Using MATLAB, Simulink and Simscape saved us so much time and played a major role in our development process

MATLAB was useful for writing our mapping and control logic. Its clear syntax made it easy to implement and modify algorithms quickly
Simulink was by far the best tool we used! We were able to tune algorithms and filters without needing any hardware, we can just tune it with the click of a button! The modular structure made it easy to identify where issues were occurring, and the built-in visualization tools helped us understand the robot’s behavior and diagnose logical problems that might otherwise have taken days to uncover.
Simscape Electrical was used to simulate our electrical system. By modeling current draw and stall current, we identified issues with our original battery choice since we kept having power issues. Fixing this early through simulation prevented a mistake that could have cost us the competition, and it’s a tool we plan to continue using in future robotics projects.

Models and graphs

Our main control model takes input from two different sources that both estimate deviation from the center of the lane. These signals are passed through a complementary filter, which produces an estimated deviation value. This output is then sent to a PID controller, mapped to a servo range, and finally sent to the steering servo

We intentionally kept this algorithm as simple as possible while maintaining reliable performance. This simplicity made tuning faster and troubleshooting more straightforward once the system was deployed.

When simulating we encountered a problem as there was no way to simulate camera readings, so as a work-around, we got readings from our test-runs and inputted it as a step function to know the output as shown in this graph

The output starts at 90, representing no deviation
It then moves to 60, commanding the servo to steer right

This approach allowed us to validate our control logic even without a fully simulated vision pipeline

As for the complementary filter sub-system. We used a simple complementary filter to fuse the sensor readings and calculate estimated deviation from the centre of the lane using the following equation:

 
θt =α(θt-1+ωtΔt)+θ acc,t(1-α)

where

θt = Estimated angle at time t

θt-1 = Angle estimate from the previous time step

ωt = Angular velocity from the gyroscope at time t

Δt = Sampling time interval

θacc,t = Angle estimated from the accelerometer at time t

α = Complementary filter coefficient (0 < α < 1)

Using Simscape Electrical

We developed a Simscape model of the robot’s electrical subsystem to perform system-level analysis which was not that difficult thanks to the detailed documentation on each block used in addition to the tutorial on the official MATLAB YouTube channel, we did come across a problem which was how to simulate microcontrollers so we used the Simscape power consumption block and calculated the maximum power consumption of the microcontrollers and used it as a parameter in the Simscape power consumption block

From the simulation results:

Maximum current usage was approximately 7 A
Required operating voltage was around 11.1 V

These results directly informed our battery selection and improved system reliability during competition runs.

Results and Key Takeaways

Using MATLAB, Simulink, and Simscape allowed us to model, simulate, and test our robot’s systems before deploying them on hardware. This helped us identify issues early, refine control strategies, and improve overall performance, ultimately contributing to our team winning the MathWorks Modeling Award.

The project taught us the importance of system-level thinking, simulation-based verification, and careful integration of hardware and software.

Looking ahead, we plan to enhance our models with more detailed sensor dynamics, environmental variability, and figure out a way to fully simulate our system including motion camera readings and implementing advanced mechanical steering.

Why Students Should Learn Model-Based Design: Insights from Industry Leaders at MATLAB EXPO

Tanya Kuruvilla — Mon, 26 Jan 2026 13:21:04 +0000

Introduction: Why These Skills Matter

Engineering today is a dynamic, fast-moving field. Whether you’re designing autonomous vehicles, aerospace systems, or renewable energy solutions, one truth remains: success depends on mastering both cutting-edge tools and foundational skills.

At MATLAB EXPO, Paul Shears, Chief Engineer at BAE Systems, talked with Ronald van Loon and shared insights that resonate deeply with students and early-career engineers. His message was clear:

Model-Based Design (MBD) is transforming how complex systems are developed.
Curiosity and hands-on learning are the keys to thriving in this evolving landscape.

After watching Paul’s interview we’ll explain why MBD matters, how you can start learning it today, and what core skills will set you apart in your engineering journey.

Why Model-Based Design Matters

Imagine you’re tasked with designing a flight control system for a fast jet aircraft; a system where safety is non-negotiable and precision is everything. Traditionally, such projects required 12 months and a team of 30 engineers. But at BAE Systems, using Model-Based Design (MBD) with tools like Simulink and Simscape, the same task was completed in under three months by just six engineers; and delivered with zero defects.

So, what makes MBD so powerful?

Instead of writing thousands of lines of code upfront, engineers create graphical models that represent system behavior. These models can be simulated early in the design process, allowing teams to verify performance before hardware is built. Once validated, the models can automatically generate production-quality code for embedded systems.

Paul explained how this approach transformed their workflow:

“We use a very multi-domain model based approach which covers the entire V life cycle of a product development life cycle. I think one of the examples where we’re quite proud is in the development of a full authority digital flight control computer. So we used great technologies from MathWorks like Simulink to design that software and then use that to autocode the software. Now as you can imagine that’s a very large complex piece of software. Very safety critical indeed. We’re able to autocode that. So shaving lots of time and money off the development cost and actually deliver it to the customer with uh with defects.” 

Another example involved hydraulic actuator control systems for fast jets. Using Simulink and Simscape, the team modeled the physical system, tested control logic, and auto-generated code for FPGA hardware. When integrated into real hardware, it worked first time; a testament to the reliability of simulation-driven design.

Why It Matters for Students

Industry Standard: Model-Based Design is widely adopted in aerospace, automotive, robotics, and beyond.
Efficiency: It reduces development time and cost while improving reliability.
Career Advantage: Employers value engineers who understand simulation-driven workflows and can bridge theory with practice.

Getting Started with Model-Based Design

You don’t need a defence lab to learn MBD. You can start right now with tools and resources available to students:

Begin with MATLAB and Simulink basics. These platforms are the foundation of MBD and are widely used across industries. Explore free tutorials on the MathWorks MATLAB and Simulink Resources for Students webpage, which offers step-by-step guides for beginners.

Next, simulate simple systems. For example, model a DC motor or a PID controller in Simulink. Experiment with parameters and observe how changes affect performance. This hands-on approach helps you understand the cause-and-effect relationships in system design.

Once you’re comfortable, dive into Simscape for physical modeling. Simscape lets you represent multidomain domain systems in a unified environment—perfect for multidisciplinary projects.

Pro Tip: Use MATLAB Live Scripts to combine code, equations, and visualizations in one interactive document. This makes your work easy to share and present, whether for coursework or competitions.

Core Skills for Early-Career Engineers

Technical tools are essential, but they’re not enough. Paul’s advice? “Be a tinkerer.”The most successful engineers are creators who love experimenting and learning by doing.

Start by writing simple scripts in MATLAB or Python. These languages form the backbone of modern engineering workflows. Solve problems on coding challenge platforms to sharpen your logic and algorithmic thinking.

Then, take it a step further: build prototypes. Use Arduino boards, sensors, and servos to create small systems. This hands-on approach teaches you how software interacts with hardware—a skill that’s invaluable in embedded systems, robotics, and IoT.

And don’t do it alone. Collaboration is key. Join a student club, participate in a competition hackathon, or work on team projects. Engineering is a team sport, and employers look for candidates who can communicate effectively and adapt to different roles.

Soft Skills to Cultivate:

Problem-Solving: Break down complex challenges into manageable steps.
Creativity: Think beyond the obvious—innovation often comes from unconventional ideas.
Continuous Learning: Technology evolves fast; stay curious and keep upskilling.

Paul summed it up perfectly:

“For a successful career in engineering and I’ve been one for 25 years, I think it’s always about challenging yourself and learning new things and that that passion to learn and grow, rather than just sitting on a static piece of knowledge.”

Building a Career Mindset

In industries like aerospace and defense, projects can span decades. That means continuous learning isn’t optional—it’s essential. Knowledge retention and adaptability are key to staying relevant.

Paul highlighted a unique challenge:

“A lot of our products we have support contracts that extend out like 40 or 60 years and we have to support things in the field. So as you can imagine knowledge retention and business continuity is a big problem. At the same time you know someone doesn’t want to work on one thing all their career right so you need an organization where people can move around rotate so they can continuously learn and grow and upskill themselves.” 

One enabler of this flexibility is Model-Based Engineering, which provides a common language and toolset across product groups. For students, this means learning tools like MATLAB and Simulinkisn’tjust about oneproject—it’sabout building a foundation that applies across domains.

How to Stay Ahead:

Rotate through different areas—controls, AI, embedded systems—to broaden your perspective.
Learn emerging technologies like AI and machine learning, but understand their ethical and safety implications.
Build networks: Join student clubs, attend hackathons, and participate in events like MATLAB EXPO to connect with peers and industry experts.

These experiences often lead to internships, research opportunities, and full-time roles. More importantly, they help you develop the adaptability that modern engineering careers demand.

Conclusion: Your Journey Starts Now

Engineering is about solving interconnected problems—and the tools and methods will keep evolving. Combine technical mastery (MATLAB, Simulink, AI) with curiosity and collaboration, andyou’llbe ready for the challenges—and opportunities—of modern engineering.

Start today:

Explore MathWorks tutorials and learning paths.
Build your first simulation.
Share your projects with the community.

The future of engineering needs problem-solvers like you. Be inspired, be creative, and keep learning.

Watch the full video here.

Click here to find MATLAB and Simulink resources for students.

UK Expo 2025