Student Lounge

Learn MATLAB – A Student’s Guide

Tanya Kuruvilla — Mon, 24 Aug 2026 17:49:36 +0000

In today’s blog, we have Ben Pasquariello from the Student Programs team at MathWorks. He’ll walk us through some helpful MATLAB resources and tips for getting started.Over to you, Ben…

Hi everyone! I’m Ben,I manage our MATLAB Student Ambassador program, which is a community of 100+ students at universities around the world. One thing I hear from them again and again is that when students first install or use MATLAB, they don’t know where to start or which resources are the most helpful. There’s a lot out there, and it’s not always obvious what’s useful when you’re brand new.

So whether you’ve just been assigned MATLAB for the first time, or you’ve been using it for a while and want to get more out of it, this blog is for you. MATLAB is used by over 5 million people across engineering, science, and beyond, so whatever field you end up in, there’s a good chance you’ll use it again after university. The good news is it gets a lot easier once you know where to start.

I’ve put together a companion YouTube video too (see below), if you’d rather watch than read. Otherwise, here’s everything I’d tell a student sitting down with MATLAB for the first time.

Table of Contents
Step 1: Getting familiar with the MATLAB interface

Step 2: Learn the Fundamentals

Step 3: Know Where to Get Support

1. Built-in help commands, Search bar, and Help Button

2. MATLAB Copilot

3. Student Resource Hubs

4. MATLAB Answers

5. Cheat sheets

Let’s Recap Your First Week: A Day-by-Day Plan

Step 4: Build Habits That Keep You Improving

Step 5: Go Further — Competitions, Projects, and Toolboxes

Student Programs:

Challenge Projects:

Toolboxes:

Explore MATLAB in Your Field:

Step 1: Get Access

First thing: check whether your university has a Campus-Wide offering of MATLAB. A lot of students miss this, but many schools give you full access to MATLAB, Simulink, and 100+ toolboxes for free. Just check your eligibility and sign up with your university email address. If your university does not have a license, you can purchase a discounted student license on this page as well (see MATLAB and Simulink Student Suite). 

Once you’re in, you can install MATLAB Desktop or use MATLAB Online right in your browser. If you want a good starting example once you have MATLAB open, I recommend downloading this sample Live Script. Try following the instructions in the script to get comfortable with how to use live scripts. 

Live Scripts let you mix code, outputs, and formatted text in one place, which is handy for assignments and lab reports. Fun fact: this blog was actually made with a MATLAB live script!

 Want to code on the go? Download MATLAB Mobile for iOS and Android.

Getting familiar with the MATLAB interface

When you open MATLAB for the first time it can feel like a lot. Here’s a quick map of the key areas (see numbered image below for visual reference):

Note: Your layout might look slightly different depending on your MATLAB release or settings. You can always adjust or configure the Desktop to change what you see using the Home Tab > Environment section > Layout. You can also adjust your code output using the View tab in the MATLAB toolstrip (my output is set to be on the right below).

Command Window (1): the panel at the bottom where you type and run commands directly. A good place to test things out quickly. Think of it like a scratchpad. 

Editor/Live Editor (2): where you write and save your code. Regular scripts (.m files) are plain code, while Live Scripts (.mlx) let you combine code, results, and formatted text in one document, which is handy for assignments and lab reports. Anything longer than a few lines should go here. 

Workspace (3): shows all the variables currently in memory. If you’re wondering where a variable went, check here first.

Files/Current Folder panel (4): on the left, shows your current folder and files. Make sure you’re working in the right folder or MATLAB won’t find your scripts.

Toolstrip (5): the ribbon across the top with tabs like Home, Plots, and Apps. Most things you need are in here.

MATLAB Copilot (6): an AI assistant built into MATLAB that can help you write code, explain errors, and answer MATLAB questions (if your license includes it). We’ll cover this more in Step 3.

 Quick tip: Try personalizing your MATLAB desktop early so it feels natural to you. You can rearrange, dock, or undock panels like the Command Window, Editor, and Workspace to suit how you work. And if you prefer dark mode, go to Home > Settings > MATLAB > Appearance and pick a theme from the Desktop Theme list.

Step 2: Learn the Fundamentals

My favorite getting started tip for new students is Onramps. Onramps are short, interactive courses designed to help you get started with a tool or topic quickly, even if you’re completely new. They focus on hands-on learning, immediate feedback, and practical skills you can use right away. They’re all free and most can be completed in under two hours.

For brand new users, start with MATLAB Onramp, a free, beginner-friendly course that teaches the basics of MATLAB from scratch. It is fully online, takes about two hours, and gives you instant feedback as you go. It covers variables, vectors, matrices, plotting, and functions. Everything you need to get started.

You also get a certificate at the end, which is worth adding to LinkedIn. MathWorks has 20+ additional Onramp courses on topics such as signal processing, image processing, machine learning, and Simulink. All free, all self-paced. Onramps are my personal favorite resource for learning MATLAB and I highly recommend them to students. 

 You can launch an Onramp directly from inside MATLAB: Toolstrip → Home Tab → Resources → Learn MATLAB.

If your university has a Campus-Wide offering of MATLAB, you also have free access to Online Training Suite, which goes deeper than Onramps do with full learning paths in data analysis, visualization, machine learning, software development and much more. Each learning path has short courses that can be completed in 1-2 hours. Completing a learning path also earns you a digital credential. Just make sure you’re signed in with your university email.

Step 3: Know Where to Get Support

Getting stuck is a normal part of learning any new language, and MATLAB is no different. The good news is that knowing where to look makes all the difference, and there’s a lot of help available once you know where to find it. One thing I always tell students early on: when MATLAB shows you an error, read the message carefully before searching. It usually tells you exactly which line has the problem and why. Here are five places I recommend:

1. Built-in help commands, Search bar, and Help Button

Commands: Two commands worth knowing from day one inside of MATLAB: help and doc.

For example:

help plot % Quick syntax summary, right in the Command Window

doc linspace % Full documentation with examples and related functions

Type either one (help or doc) before any function name and MATLAB will bring you to the specific documentation page or give you help in the command window. The doc command opens the full docs page with examples and related functions. You can also browse everything on the MathWorks Documentation site.

Search Bar: You can also use the search bar in the top right-hand corner of MATLAB to find resources like toolstrip actions, examples, videos, and community answers. 

Help Button in the Toolstrip: Go to the MATLAB Toolstrip, under the Home tab, select the Help drop down button in the resources section. You will find links to the documentation mentioned above, examples, and community support on MATLAB Central. 

See the Keyboard Shortcuts link in the help menu. Shortcuts like Ctrl+R in the Editor or Live Editor comment out selected lines of code. 

2. MATLAB Copilot

If your campus has access to MATLAB Copilot, use it as a learning tool rather than a shortcut. MATLAB Copilot is an AI assistant built directly into MATLAB that helps explain code, clarify error messages, and generate small examples using MathWorks documentation. The more specific your prompt, the better the answer.

Here are a few prompts that I recommend to get you started:

Learning a function: “Explain what the fft() function does and show me a simple example using a sine wave”

Understanding an error: “I’m getting this error: [paste error message here]. What does it mean and how do I fix it?”

Exploring a toolbox: “What can I do with the Signal Processing Toolbox to filter noisy sensor data? Show me a simple example”

Getting unstuck on a concept: “I don’t understand the difference between a for loop and a while loop in MATLAB. Can you explain it with an engineering example?”

Generating starter code: “Show me how to import experimental data from a CSV file and plot voltage against time in MATLAB”

Working with equations: “How do I numerically solve a differential equation in MATLAB? Show me an example”

Just make sure you understand the code it suggests before submitting your work. To learn more, check out the official MATLAB Copilot documentation on MathWorks.com. 

Look for the  symbol in the toolstrip or command window which indicates ways that you can interact with MATLAB Copilot.

If your campus doesn’t have access to MATLAB Copilot, the MATLAB AI Chat Playground is a free alternative on MATLAB Central. It can generate and run MATLAB code, explain functions, and help you work through problems. 

3. Student Resource Hubs

There are two pages I recommend bookmarking, and they serve slightly different purposes.

The MATLAB & Simulink Resources for Students page is the official MathWorks webpage, a clean, curated site linking to the core resources I mention in this post. It’s a great first stop.

Awesome MATLAB Students is a more comprehensive collection on GitHub, also maintained by MathWorks but shaped by conversations with students and faculty. It goes broader, with cheat sheets, fun examples, student club material, competitions, and more. Use it when you want to explore beyond the core set. Star it now and you can keep coming back to it all semester.

4. MATLAB Answers

MATLAB Answers is where I send students when they’re stuck on something specific. There are thousands of answered questions, and someone has almost always hit your exact error before. And if no one has, you can post your own question. The community is genuinely helpful and quick to respond.

5. Cheat sheets

Keep a cheat sheet open while you work. Forgetting syntax is normal, and a quick glance at a cheat sheet is faster than hunting through docs. There are sheets for Simulink, data import, machine learning, and more. One of my favorites for new students is the MATLAB Basic Functions Cheat Sheet.

Some cheat sheets are available in multiple languages. 

Let’s Recap Your First Week: A Day-by-Day Plan

Using the resources above, if you’ve just been assigned MATLAB, here’s a simple plan for your first week that I recommend following. I suggest focusing on learning one thing per day. The goal is to build your confidence one small win at a time.

Day 1 — Get access: Check if your university has a Campus-Wide offering and sign up with your university email. Once you’re in, open MATLAB Online and get familiar with the UI, toolstrip, command window, and files section. 

Day 2 — Do an Onramp: Start MATLAB Onramp. Give it 1–2 hours and just work through it. This is my favorite MATLAB resource. 

Day 3 — Finish Onramp and earn your certificate: Add it to LinkedIn. Then have a quick look at the other free Onramp courses. There’s almost certainly one for your field.

Day 4 — Get your cheat sheet: Review the Basic Functions Cheat Sheet and keep it open while you work. Most of it will look familiar from MATLAB Onramp, but having it all in one place is useful.

Day 5 — Write something real: Take one concept from your class and recreate it in MATLAB. Not sure where to start? Try pasting this into MATLAB Online and running it:

x = 0:0.1:2*pi;

y = sin(x);

plot(x, y)

title(‘My first MATLAB plot’)

xlabel(‘x’)

ylabel(‘sin(x)’)

Then try changing sin to cos, or the range to 0:0.1:4*pi. When you get stuck, try the doc command first, then MATLAB Answers or Copilot if you need more help.

Day 6 — Explore real code: Sharpen your skills by practicing with hundreds of coding problems on Cody, and browse MATLAB Central File Exchange for real-world code in your field. Open the files and study them. You’ll learn more from actual code than any tutorial.

Day 7 — Set yourself up for the semester: Subscribe to this blog, follow @matlab_students on Instagram, and star the Awesome MATLAB Students repo. That’s your support system for the semester. Below are more ways to grow your skills and explore project-based learning.

Step 4: Build Habits That Keep You Improving

In my experience, the students who get really good at MATLAB are the ones who stay in contact with it between assignments. It doesn’t take much. Here are a few easy ways to do that:

Subscribe to this blog. The Student Lounge goes up at least once a month with student stories, new resources, and tips. The subscribe button is in the top-left corner.

 I’d also recommend checking out the other MathWorks blog channels on MATLAB Central — there are blogs covering everything from deep learning to student projects, and I find myself recommending them to students regularly.

Follow @matlab_students on Instagram. @matlab_students posts a few times a week: quick tips, competition callouts, student community highlights. A good way to pick up tips and see what’s happening in the MATLAB student community.

Watch short how-to videos. The MATLAB How-To Playlist on YouTube shares short tutorials every month, each focused on one specific concept. It’s worth subscribing to that playlist, along with the main MATLAB YouTube channel.

Try Cody. Cody is a fun coding challenge game site on MATLAB Central where you solve MATLAB problems and earn points. Good for finding gaps in what you know. Try a problem group, even for ten minutes a week. 

Step 5: Go Further — Competitions, Projects, and Toolboxes

Once you’ve got the basics down, building something real is the fastest way to improve. Here are four ways to take it further.

Student Programs:

MathWorks Student Programs run competitions across engineering and science, from drone challenges to the annual Simulink Student Challenge with cash prizes. These are great for your CV, and you’ll often meet people from industry or research along the way.

Check out the full list of contests, competitions, and hackathons here. MathWorks provides complimentary software and self-paced online training for its competitions. If your team is participating and needs software, fill out the software request form on the corresponding competition page.

If there’s a MATLAB student club at your university, get involved. The Awesome MATLAB Students repo has material you can use to run a workshop.

Challenge Projects:

For capstone, thesis, or independent study ideas, browse the MathWorks Challenge Projects list. Once you have a project in mind, the File Exchange on MATLAB Central is a great place to find starting points, with thousands of open-source files across engineering and science that you can download and learn from.

Toolboxes:

As you start working on bigger projects, you’ll eventually hit problems that are specific to your field, like filtering a noisy signal or training a machine learning model. This is where toolboxes come in, and it’s worth understanding what they are now so you know what’s available to you.

A toolbox is a packaged collection of functions, apps, example code, and documentation built for a specific area like signal processing, image processing, machine learning, control systems, and so on. MathWorks has over 100 of them, so whatever your field is, there’s almost certainly a toolbox for it. They give you ready-made, tested algorithms for your field so you’re not building everything from scratch. If your university license includes them, they’re already available to you and work exactly like any other MATLAB function.

If you installed MATLAB Desktop, make sure you selected your toolboxes during installation. It’s easy to click through the installer without realizing they’re there. If you missed any, go to Home > Add-Ons > Explore Add-Ons to install them. To check what’s currently installed, type ver in the Command Window.

Some toolboxes also come with interactive apps, like Image Segmenter in the Image Processing Toolbox, that you can launch from the Apps tab to do common tasks without writing any code at all.

Here’s a quick example using the Image Processing Toolbox:

img = imread(‘peppers.png’); % load a sample image (built into MATLAB)

gray = rgb2gray(img); % Image Processing Toolbox – convert to grayscale

% (edge detection works on grayscale, not color)

edges = edge(gray, ‘Canny’); % Image Processing Toolbox – find the edges in the image

% ‘Canny’ is the algorithm used – one of the best for clean results

imshow(edges); % display the result – you’ll see a black image with white outlines

Before: After:

peppers.png is built into MATLAB so you can run this right now without needing your own image. In a few lines you’ve gone from a color photo to a clean edge-detected version, and that’s what a toolbox gets you. The best place to get started with any toolbox is its documentation page on MathWorks Documentation. Each one has a getting started section and worked examples to walk you through the basics. 

On the Documentation page, select Product List from the filter in the top left to see every available toolbox and find the one that matches your field.

Explore MATLAB in Your Field:

My final recommendation is to start applying MATLAB to problems in your own discipline. This will be the glue that helps you understand how MATLAB can support your schoolwork, research, projects, or career.

Here are some academic areas where MATLAB is widely used and a resource page for each discipline:

Biological Sciences – model, simulate, and analyze biological systems
Chemical Engineering – enhance learning in process modeling, simulation, and labs
Chemistry – analyze, visualize, and build predictive models for chemical data
Electrical & Computer Engineering – explore signals, systems, and embedded design
Geoscience – analyze and understand complex environmental and geological data
Mathematics – explore numerical methods, modeling, and applied math concepts
Mechanical Engineering – design, simulate, and analyze physical systems
Neuroscience – process data, run experiments, and model brain activity

Not sure where to start? Browse all application areas.

Pick one area, try an example, and if you want to see where these skills can lead, check out MathWorks customer stories to see how engineers and scientists have applied MATLAB in industry to solve real-world problems.

Happy Coding — you’ve got this!

MATLAB gets easier the more you use it. Start with Day 1, do one thing at a time, and don’t stress about knowing everything up front. Nobody does!

Key links from this post:

Simulink-Based CAN Control and Validation on STM32F4 for a Dual-Motor EV Platform

Tanya Kuruvilla — Wed, 12 Aug 2026 14:08:55 +0000

In today’s blog, we are joined by Team I.C.C. from Inha University, South Korea. They share how they used MATLAB and Simulink to develop and validate a CAN-based embedded motor control workflow for their dual-motor EV platform. Over to you…

Introduction

I.C.C. (Inha Car & Computer) is a student club at Inha University (South Korea) dedicated to automotive research, design, and hands-on electric race car production. Through activities such as developing electric racing vehicles, building embedded control systems, and preparing for engineering competitions, I.C.C. provides students with opportunities to gain practical experience in electric racing car development, teamwork, and problem-solving within the field of future mobility. In this project, the team focused on building and validating a Simulink-based CAN control workflow on STM32F4 for a dual-motor EV platform. Rather than presenting the work only as a dual-motor hardware project, this blog highlights how model-based design made CAN implementation, deployment, and real-time validation much easier to manage in practice.

Figure 1. I.C.C. club members at a racing competition with the electric racing car (Inha University, South Korea)

Motivation

For our EV racing car, we needed more than a basic motor test. The real challenge was to establish a practical workflow for CAN-based control and validation on STM32F4 so that motor commands could be generated from live input, transmitted reliably, and checked against real hardware feedback during operation. While this workflow was developed for a rear-driven dual-motor platform and can later support torque vectoring, the immediate goal of the project was to make CAN-based control easier to implement, deploy, and verify.

To make that possible, the workflow had to go beyond fixed CAN message tests and support a complete embedded control loop with:

variable driver input,
independent motor command generation,
reliable CAN communication, and
real-time feedback monitoring.

In the early hardware test stage, motor operation was checked mainly with predefined CAN commands in STM32CubeIDE before the pedal signal was connected through ADC. That approach was useful for basic validation, but it made it harder to iterate on continuously changing commands, integrate real input processing, and monitor the full control path in a structured way. To address this, we developed an embedded Simulink-based workflow on STM32F4 that combined throttle input processing, CAN-based command transmission, code generation and deployment, and feedback monitoring in one model. This shifted the project from isolated CAN testing toward a repeatable workflow for embedded control and validation, while still leaving room to expand into dual-motor coordination and future torque-vectoring logic.

As a result, we established a practical CAN-based embedded workflow that could read real throttle input, transmit motor commands, and monitor feedback in real time on STM32F4. The validated workflow was then extended to a dual-motor structure, providing a solid foundation for future vehicle-control features such as torque vectoring.

Breaking down the problem

To build a practical CAN-based motor control workflow on a rear-driven dual-motor EV platform, the problem had to be approached as a control, communication, and validation challenge rather than as a simple motor test. The embedded system needed to convert driver input into commands, transmit them reliably over CAN, receive meaningful feedback, and organize the structure in a way that could later scale to independent left-right control.

1. Converting Driver Input into Torque Commands

The first requirement was an input-to-command path that could convert variable driver input into torque commands suitable for vehicle control. Fixed test commands were not enough, because torque vectoring depends on continuously changing motor commands based on throttle input and, eventually, vehicle-state-based control logic.

2. Establishing Reliable CAN Communication

The second requirement was a reliable CAN communication structure for both transmission and reception. On the transmit side, the controller needed to send properly formatted torque commands to each motor controller. On the receive side, it needed to collect feedback signals such as battery voltage, torque, RPM, and motor voltage so that each motor’s response could be monitored and validated during operation.

3. Building a Scalable Dual-Motor Control Structure

The third requirement was support for independent dual-motor control as a foundation for future torque-vectoring algorithms. This meant extending the validated single-motor structure into a scalable architecture in which the left and right motor paths could be configured, tested, and monitored separately. The goal was not simply to make two motors rotate, but to establish a dual-motor embedded control platform that could later support higher-level vehicle dynamics control.

Figure 2. The overall structure of the dual-motor system

How did we implement it?

To implement this workflow, we developed the control structure in Simulink and deployed it on STM32F4 using the STM32 Microcontroller Blockset. The main objective was to bring CAN communication, throttle input processing, code generation, deployment, and feedback monitoring into a single model-based workflow that could be refined quickly during hardware testing. STM32F4 was a good fit because it offers built-in CAN interfaces, ADC inputs, and enough real-time performance for embedded motor control. We organized the model into functional subsystems for input processing, command generation, CAN transmission, CAN reception, and monitoring, which made the workflow easier to understand, debug, and extend from a single-motor test setup to a dual-motor platform.

We started by emulating pedal behavior in Simulink with a slider block, then later connected that same signal path to the actual ADC throttle input. This made it easy to move from simple bench testing to a more realistic dual-motor workflow driven by real input. On the transmit side, the throttle signal was translated into a motor command and packaged to match the motor controller protocol. Because the command changed continuously with the input, we were able to test dynamic motor actuation rather than relying only on fixed commands. By separating the CAN paths for each controller, we also created a structure that could support independent left and right motor control in future vehicle tests.

On the receive side, the focus was on checking whether the motor controllers were responding as expected during operation. Since the controllers returned several different status groups, we used a MATLAB Function block to parse the incoming CAN data more efficiently. This allowed us to monitor key feedback signals such as battery voltage, torque, RPM, and motor voltage in real time. As a result, we gained a much clearer picture of how each motor was behaving and could validate the dual-motor setup in a more systematic way.

Debugging was also much more manageable with CAN STATUS information, Monitor & Tune, and real-time monitoring in place. Instead of depending only on serial print messages, we could inspect internal signals directly and quickly tell whether an issue came from the model itself or from hardware conditions such as wiring and connections. We could also visualize the monitored signals as plots and export them as CSV files for later analysis, which made it much easier to review test results and compare behavior across hardware runs.

Figure 3. Real-Time hardware test with STM32F4, CAN communication, and dual motors with Simulink

Figure 4. A Simulink-based torque-vectoring control architecture built on top of the validated dual-motor workflow.

Results

The biggest outcome of this project was that we established a Simulink-based CAN control and validation workflow that could be deployed directly to the real vehicle platform through STM32F4. By connecting the real ADC throttle input and generating CAN-based motor commands from the model, we showed that driver input could flow through the complete embedded path—from pedal signal, to controller logic, to CAN transmission, to actual motor response and feedback validation on hardware. This made the project more than a bench-level motor test; it became a practical demonstration of model-based embedded control on a real EV platform.

Just as importantly, the Simulink-based workflow made implementation, deployment, and debugging much easier to manage than a conventional low-level approach centered on predefined CAN commands in STM32CubeIDE. Instead of repeatedly modifying C code for every small change, we could adjust signal scaling, data types, CAN formatting, and sample times directly in the model and then regenerate and redeploy the code more efficiently. Monitor & Tune, CAN STATUS information, and real-time monitoring also made validation much more systematic, because we could inspect internal signals directly and identify whether issues came from the model logic or from hardware conditions such as wiring and connections. The modular structure further made it easier to expand the validated workflow from a basic test case into a dual-motor architecture, giving us a scalable starting point for future vehicle functions such as torque vectoring.

Figure 5. The EV racing car is in test with torque vectoring implemented

Building Janus: How a FIRST Robotics Team Engineered a Championship Robot

Tanya Kuruvilla — Mon, 27 Jul 2026 14:12:35 +0000

For this week’s blog post, we’re featuring FRC Team 2040 from the FIRST Robotics Competition as they reflect on their 2026 season and share how they used Simulink and WPILib to coordinate their robot Janus’s shooter and help the team return to the FIRST World Championship. If you are interested in using MATLAB and Simulink for your team, please visit our FIRST Robotics page or contact us at roboticsarena@mathworks.com. We’re excited to highlight their journey and hope you enjoy their insights!

Meet FRC Team 2040

Hello everyone! My name is Anirudh Chalamkuri, and I am the programming lead and implement driver for DERT, FRC Team 2040, based in Dunlap, Illinois. I joined the team during my junior year, after watching them demo their 2024 robot at a school event.

Our team has competed in the FIRST Robotics Competition since 2007, and this year, after winning the Central Illinois Regional and being a finalist at the Greater Kansas City Regional, we qualified for and competed at the FIRST World Championship in Houston, Texas. This is a huge achievement and a very successful year for us, as we haven’t qualified for the World Championship since 2011.

Our Robot: Janus

For the 2026 season, our team designedJanus,named after the two-faced Roman God of Beginnings.

The game this year Rebuilt, although much more complex, boilsdown tocompeting for and collectingas manypiecesof fuel (15cm in diameter high-density foam balls) froma sharedcenterzoneand scoring them into your alliance’s hub for points.

Our goal was to build a robot capable of scoring game pieces quickly and consistently from close to mid-range positions around the hub. Because of that, our robot falls under the ‘dumper-style’ category of bots, an archetype that generally relies less on shooting from long distances, and more on fast and repeatable cycles.

If you would like more detailed breakdown of our robot’s mechanical design, check out this flyer I designed detailing Janus’ mechanical specifications:

For the purposes of this blog, I’ll give a quick overview of our shooting mechanism. Our shooter is divided into three separate segments, allowing the robot to launch up to three fuel pieces at the same time. Each segment has its own path through the mechanism, including transfer wheels that move fuel into position and a set of shooting flywheels that launch it toward the hub.

The transfer wheels are powered by a single Kraken X44 motor and move fuel from the indexer into the barrel of the shooter. Once the fuel is in position, the shooting flywheels launch it out of the robot. Unlike the transfer system, the shooter is divided into three independent shafts, each powered by a Kraken X60 motor and equipped with flywheels. The robot rotates to aim horizontally toward the hub, while a hood driven by two linear actuators adjusts the angle of the shot.

Even a single shot relies on many parts of the robot working together at exactly the right time. A large portion of our programming work throughout the season went into refining that coordination so the robot could score as consistently and reliably as possible.

Our Design Approach

At the beginning of the season, our team had a new and very successful kickoff plan, coordinated by our team lead William Anderson. If you would like to read more about it and consider implementing it for your own FRC team, I have linked a PDF he created detailing the procedure and the reasoning below.

After deciding on the type of robot we would create, the programming team then set out to design the control systems for the scoring mechanism on our robot, we broke down our process like this:

Although each mechanism has a specific role, the robot can score consistently only if all parts work together with great precision. This made the programming behind the shooter especially important and tricky. We needed to coordinate several motors, adjust the hood position, and control the robot’s direction while keeping the process as easy as possible for the drivers. This means most of this needed to be done automatically on the press of a button.

Why did we use Simulink?

Although our team had been using Simulink for three years prior, it paid off in a huge way this year.

Before joining the team, I had never used MATLAB or Simulink. I first learned how to use them during my junior year by watching Mr. Randy Anderson, our lead programming coach, teach us. During the following summer, the programming team gained more experience by working on several projects with a new programming mentor who joined our team. Those projects helped me learn the skills I needed before the start of the 2026 season.

Because I was already comfortable with hand-coding, Simulink did not feel that different to me. Once I understood how the blocks and signals worked, Simulink was just a more visual and intuitive way to write the same programming logic.

For newer programmers, however, Simulink was a game-changer. They did not need to memorize syntax before contributing to the robot. Instead, they could focus on the logic behind the program. Such as, what information the robot needed, what decisions it should make, and how each subsystem should respond. That made it easier for new members to get involved while still learning the core ideas behind programming. This was especially important because the majority of our programming team were rookies; in fact, my fellow programming co-lead, Melaina Humbles, and I were the only returning programming students for this season.

How We Integrated Simulink with WPILib

Integrating Simulink with WPILib, the open-source library used for FRC programming, was an exciting and technically challenging effort. The system was largely developed in 2023 by alumni/former team lead Janelyn Anderson, who also consistently returns to the team to update the codebase.

The basic idea is that once we create the control logic in Simulink, a build script uses Simulink Coder to generate C code from the model. That generated code is then integrated into our larger C++ and WPILib project.

The handwritten C++ code handles the connection between Simulink and the physical robot. It passes sensor data and driver inputs into the model, runs the generated control logic, and then sends the resulting commands back out to the motors and other hardware.

This cycle runs every 20 milliseconds during the robot’s periodic loop:

To make this easier to manage, our framework uses reusable C++ components. Each component handles a specific part of the robot and includes a pre-step function and a post-step function. The pre-step function collects information from the hardware and sends it into Simulink. The post-step function takes the output from Simulink and applies it to the robot. Setting up each of these components requires minimal programming and can be done quickly whenever required, so most of the attention and time can go towards the Simulink logic.

As you can see from the code snippet above, the amount of hand-code required is relatively minimal.

Janelyn also set up libraries that simplify the process of adding motors. Instead of rewriting a large amount of setup code each time a new motor is added, we can use wrappers to configure details such as the CAN ID, direction, and current limits in one place. Below is an example of two different categories of motors being created:

Another useful part of the framework is the ability to interact with certain values through Network Tables. These values can include PID constants, offsets, and other tunable parameters. We can adjust them through tools such as Glass or Advantage Scope while testing the robot, rather than rebuilding the entire program after every small change. The nature of this year’s game requires high precision, and being able to adjust parameters quickly on the fly during tuning saved a lot of time.

We can also use test points that display the values of important signals. This makes it easier to diagnose problems because we can see what the robot is measuring and what commands the model is producing in real time.

For example, while tuning the shooter, we could monitor values like:

Target flywheel RPM
Measured flywheel RPM
Flywheel motor output
Hood target position
Measured hood position
Whether the robot is aligned with the hub
Whether the shooter is ready to release fuel

Now that I’ve gone over, at a high level, how the framework for Simulink integration works. Let’s delve into the Simulink code.

Above is a zoomed-out screenshot showing our primary Simulink Model for the robot’s controls. For today’s purposes, I will focus primarily on the “Rebuilt” section, more specifically the subsystem for shooting.

One of the main tools we used to control the shooter was PID control. A PID controller continuously compares a desired value, known as the setpoint, to the robot’s actual measured value. It then adjusts the motor output via various feedback loops(Proportional, Integral, and Derivative)to reduce the difference between the two. Instead of relying on a fixed motor output and assuming it will behave the same way every time, the controller constantly makes small corrections based on sensor feedback.

For our shooter, each of the three channels is powered by its own Kraken X60 motor. Before releasing fuel, the robot needs to bring each flywheel to its target speed. Rather than simply applying a fixed amount of power and assuming the wheels will spin at the correct rate, the program measures the actual RPM and adjusts the motor output as needed.

For example, if one flywheel is spinning below its target RPM, the controller increases its output. As the flywheel approaches the desired speed, the controller makes smaller corrections. This allows the shooter to respond to changes in the system, such as the brief drop in speed that can occur when fuel passes through the wheels.

Below is a Simulink Subsystem that adjusts the shooter motor PID gains and controls when the integral term is enabled.

This subsystem adjusts the shooter motor PID gains based on how close the shooter is to its target speed. It subtracts the measured shooter speed from the desired shooter speed to calculate the current error, then uses several comparisons and logic blocks to determine whether the integral term should be enabled or temporarily disabled. There is also logic in order to remember the previous state and prevent the integral control from rapidly switching on and off between updates. The proportional gain is passed through directly, with no logic controlling it; meanwhile, the integral gain is selected based on the aforementioned logic. Finally, the subsystem checks whether the gain has changed and sends a signal telling the motor controller to update its PID settings.

The previous subsystem adjusted the PID gains used by the shooter motors. Below is an example of how we used one of our custom PID library blocks to implement a complete PID control loop within a subsystem. The model compares the desired transfer motor speed with the measured speed and passes both values to the PID block with feedforward, which calculates the duty cycle required to achieve the target speed.

Shooting a fuel object requires several mechanisms to work together. The flywheels must reach the correct speed, the hood must move to the correct position, and the robot must rotate toward the hub before the transfer wheels release the fuel. All of these rely on processing vision input, doing calculations, and then transferring that accurately to motor commands.

The subsystem shown below combines several calculated outputs from other subsystems and uses logic gates to determine whether the robot is ready to shoot. It also decides whether the robot is prepared to unload or pass fuel, which are handled by separate functions.

It verifies that the robot is in the correct field zone, moving slowly enough, aimed at the target, and that the shooter wheels and hood are at their desired settings. These conditions are combined so the robot only transfers and shoots the fuel once the required systems are ready.

After the robot evaluates its shooter speed, hood angle, alignment, and field position, those readiness signals are passed into this Stateflow chart. The chart controls when fuel is allowed to move through the final stages of the shooting system, preventing transfer and feeder wheels from activating before the robot is ready.

This Stateflow chart also organizes the shooting sequence into clear states. When the robot is not shooting, the transfer and feeder motors are stopped. Once a spin-up, shoot, or manual-unload command is received, the robot enters the shooting sequence and waits in the Spinning_Upstate while the shooter, hood, and alignment systems prepare. After the robot reports that it is ready to score, pass, or unload, it enters the Transfer state, where the transfer wheels move fuel from the indexer toward the barrel. Once the transfer wheels reach the required speed, the feeder activates to push the fuel through the shooter. The system returns to the spin-up state when the command is released, the shooting time limit is reached, or the robot is no longer ready.

With this Stateflow chart, PID loops, and many other subsystems that I unfortunately do not have the time to share, the robot is able to successfully score fuel into the hub!

A lot of work went into the code behind the robot throughout the season. It took plenty of testing, small adjustments, and troubleshooting to get everything working together the way we wanted. I was only able to highlight one of the main parts of our robot’s code here, so I will link our GitHub repository for anyone who is interested in looking through the full codebase and learning more about how the robot works!
Reflecting on Our 2026 Season Making it to the FIRST Championship in Houston was a huge moment for our team. This is the best our team has ever done in its history. Making a deep playoff run at one regional is already an incredibly rare and exciting feat for us, but taking home the victory banner at one regional and then making it all the way to the finals at a second was something we never could have expected. After our unexpected win, our mentors and parent volunteers stepped up to raise the money and handle all of the logistics needed to get our team to Houston. We would not have been able to make the trip without their support.
At Houston, the robot performed well and helped us end our season with a 6-4 record in a competitive field filled with top-tier robots from across the world. It was so exciting to see Janus compete on that stage after months of designing, building, programming, testing, and fixing problems together as a team.
Although making it this far was something we were incredibly proud of, there are still areas we would have liked to continue working on and will likely work on throughout the offseason. With more time and a lot of adjustments to the code and vision system, we would have loved to implement accurate shooting-on-the-move on our robot. It would’ve helped combat some of the heavy defense that was played at Houston, and increase the amount of cycles our robotics able to perform each match.
Overall, making it to Houston was a fitting end to an incredible season. It gave us the chance to compete against some of the best teams in the world and see how far our robot had come since the beginning of the year. Although there were still areas we could have improved, the experience of reaching the Championship was something we will always be proud of, and we hope it marks the beginning of a new annual tradition for the team.

Automating the Unpredictable: Buckeye AutoDrive’s Random Obstacle Trajectory Generation

Tanya Kuruvilla — Mon, 13 Jul 2026 14:47:31 +0000

Today we are joined by students from The Ohio State University’s SAE AutoDrive II team – Buckeye AutoDrive.

Representing the Center for Automotive Research (CAR) and the Ohio State Department of Electrical and Computer Engineering (ECE), the Senior Design Capstone Program has partnered with Buckeye AutoDrive to bridge the gap between theory and practice. The Capstone Program serves as a vital proving ground where ECE students transition from the classroom to solving complex, real-world engineering challenges. As a student-led team competing in the AutoDrive Challenge II, Buckeye AutoDrive brings together a multidisciplinary cohort of undergraduate and graduate students. Through this partnership, these two programs are working to shape the future engineering workforce.

In this post, we will highlight how the Buckeyes utilize both MATLAB and RoadRunner to support their goal of improving autonomous driving systems. Specifically, we will focus on how they automate random obstacle trajectory placements. This breakthrough bolsters software testing robustness and pinpoints critical “edge case” scenarios. Below, we will outline the motivation and methodology of this development. Enjoy and Go Bucks!

Figure 1. Buckeye AutoDrive Vehicle

Motivation

Simulation is the backbone of autonomous development, enabling rigorous software testing while eliminating the high costs and safety risks of physical trials. The Buckeye Simulation Team is dedicated to building an extensive collection of simulation tools that mirror the complexities of real-world driving. By prioritizing environmental diversity and data integrity, we empower the team to build safe, reliable software in a controlled, virtual environment.

The random obstacle trajectory generator was completed as part of the 2026 MathWorks Simulation Challenge for the SAE AutoDrive II Competition. While the challenge focused on complex scenarios, the team challenged themselves to think outside of the box and solve emerging testing struggles.

Designed with the demands of the autonomous vehicle industry in mind, this tool tackles the inherent unpredictability of the real world. By automating irregular obstacle placement, we allow developers to catch software “hiccups” in a safe, virtual space before the vehicle ever encounters them on the road.

Methodology

The team developed a streamlined workflow to bridge the gap between MATLAB and RoadRunner

Initializing and Software Feature Grouping

The first step in any RoadRunner project is establishing a seamless connection between the application and the project files. To streamline this, we developed an initialization Graphical User Interface (GUI) using the MATLAB App Designer application. Users declare the file paths for both the RoadRunner installation and the specific project folder. These selection tools can be seen in Figure 2 below.

Figure 2. Initial Graphical User Interface (GUI) Utilization

Efficiency is key. Once the connection is live, users can choose their testing path:

Predefined Feature Testing: Shortcuts based on specific software features (e.g., Sign Detection).
Manual Selection: Allows developers to hand-pick scenarios for custom testing.

In Figure 2 above, a sample of a Sign Detection software feature is selected. The user has a diverse set of options that are constantly being expanded by the team as new features are developed and new scenarios are created.

RoadRunner Handshake

Once selected, MATLAB script then executes a “handshake,” calibrating the environment to the selected scenarios automatically. This script uses predefined functions from the Automated Driving Toolbox. A flow chart of this process is seen below in Figure 3.

Figure 3. Software Feature

Using this handshake, the script will loop through every stored scenario selected earlier in the initialization GUI. During each run, the scene (e.g., Four Way Stop) will be loaded in RoadRunner. Into this environment, the scenario (e.g., Car Obstacle and Left Turn) will be loaded. After some parameter calibration in the script, the simulation will connect and compile the vehicle software using a .rrbehavior file connection. Examples of different simulations can be seen below in Figure 4.

Figure 4. RoadRunner Scenarios with Various Obstacles and Traffic Patterns

Repetition and Data Analysis

Robustness requires repeatability and analysis. Our framework includes a repetition feature, allowing the same scenario to run multiple times to ensure the simulation – and the vehicle’s response – remains consistent under identical conditions before we introduce randomness.

After simulation runs, data from a stored .csv file is analyzed. The file includes time stamped positions of each actor with velocity vectors. This.csv is synthesized using secondary MATLAB scripts to generate a variety of metric data. This data is computed across the simulation and compared to safety and comfort thresholds to determine if the simulations passed or failed. Examples of this data can be seen in Figure 5.

Figure 5. Examples of Data Metric Outputs with Pass/Fail Tolerance Thresholds

Random Obstacle Trajectory Generation

This is the core innovation. Rather than using static actor trajectories, the generator randomizes the starting point of obstacles (Actor 2). When this feature is active, the MATLAB script initializes a RoadRunner instance containing only the obstacle actors, excluding the Ego vehicle. The script then exports the scene into a structured code format, which is programmatically modified to assign new, randomized coordinates to the obstacles. Finally, this modified obstacle code is injected back into the primary simulation environment, overlaying the randomized actors onto the existing Ego vehicle scenario.

Figure 6. Random Obstacle Trajectory Generation Simulation Maps

As shown in Figure 6, the blue trajectory line for Actor 2 is an obstacle that starts at various points. This ensures:

Variable Timing: By shifting the start point, the obstacle crosses the ego vehicle’s path at different intervals.
Dynamic Response: This forces the software to detect and react to threats at unpredictable times, rather than relying on “pre-programmed” success at a specific waypoint.

By moving away from “predicted” obstacle points, our software can be tuned to detect and react at any moment. This level of thoroughness significantly increases the safety and reliability of our vehicle when it is eventually translated from the virtual world to the physical road.

Conclusion

By linking MATLAB and RoadRunner in a repeatable workflow, the Buckeye AutoDrive team generated randomized obstacle trajectories that added real-world unpredictability while exposing edge case scenarios that normal testing can miss, thereby strengthening safety and reliability before road testing.

MathWorks Minidrone Competition – Europe 2025: Model‑Based Design for Autonomous UAVs

Tanya Kuruvilla — Mon, 22 Jun 2026 11:44:42 +0000

The MathWorks Cambridge office hosted the Europe 2025 edition of the MathWorks Minidrone Competition, welcoming students from universities across Europe. The 2025 edition drew applications from over 40 student teams.

Following a structured simulation and evaluation phase, six top performing teams were selected to advance to the final In‑person deployment round at the MathWorks Cambridge office. For students who took part in the MathWorks Minidrone Competition – Europe 2025, the experience extended well beyond the final results. The competition accelerated learning, strengthened confidence, and challenged teams to apply classroom learnings in a real engineering setting.

For those less familiar with the Minidrone Competition, this blog takes a closer look at what the program offers, why it is relevant in an academic context, and what made the Europe 2025 edition a meaningful and memorable experience for participating students.

Student teams at the MathWorks Cambridge Office

What Is the MathWorks Minidrone Competition?

The MathWorks Minidrone Competition is a structured, academic program designed to help university students apply classroom theory to real-world autonomous systems using model-based design.

The competition challenges students to design, simulate, and deploy autonomous flight control algorithms for a real minidrone using Simulink, following the same workflow used by engineers in industry from system modelling and simulation to hardware deployment and validation.

By combining curriculum-aligned concepts with hands-on experimentation, the program enables students to move beyond theoretical understanding and gain practical experience with system modelling, control design, autonomous guidance and navigation using image processing and Stateflow.

The Simulation Round: Where Designs Took Shape

The Europe 2025 edition of the MathWorks Minidrone Competition challenged students to design an autonomous minidrone line follower using Simulink, beginning with a rigorous simulation round before progressing to deployment on a real Parrot Mambo minidrone.

Launched earlier in the year, the competition invited university teams across Europe to start their journey in simulation, where they developed and validated their algorithms using Simulink. Following a structured submission and evaluation process, top‑performing teams progressed to the final deployment round, where their models were tested on real hardware.

This simulation-first phase was not a preliminary exercise, but a deliberate engineering filter. Teams were evaluated on accuracy, robustness, level of tool usage, and solution optimization of their models, reinforcing the principle that strong simulation is a prerequisite for reliable hardware deployment. This journey mirrored industry workflows—model, test, refine, and deploy—giving students an authentic taste of modern engineering practice.

Simulation of autonomous minidrone flight

The competition culminated in live finals held in November 2025 at the MathWorks Cambridge Office, where shortlisted teams came together to deploy, test, and compete with their algorithms on physical minidrones.

At the MathWorks Cambridge Office: Deployment on Hardware

Live hardware flight tests as part of the final deployment round

The Minidrone Competition – Europe 2025 brought together over 40 student teams from across Europe, reflecting the broad academic engagement with model based‑design and autonomous systems. From this group, six finalist teams earned the opportunity to compete in person at the MathWorks Cambridge Office.

For finalist teams, the MathWorks Cambridge Office marked a decisive transition from validated simulation models to autonomous flight on real hardware. In November 2025, students arrived not to demonstrate concepts, but to test whether their designs could withstand the realities of a physical system.

Finalist teams represented a diverse set of institutions, including:

University of Oxford
ISAE‑SUPAERO
Warsaw University of Technology
A joint team from the Technical University of Denmark and Warsaw University of Technology

The Simulink models developed during the simulation phase were deployed onto Parrot Mambo minidrones, exposing students to constraints such as small embedded processor, physical dynamics and environmental variability. For many participants, this was their first experience collaborating and competing alongside peers from different countries. Working in a shared technical environment highlighted the collaborative nature of modern engineering.

The onsite agenda balanced focused technical work with opportunities for discussion and exchange, reinforcing that effective engineering practice depends not only on individual models, but also on communication, comparison of approaches, and collective problem solving.

What Students Took Away (Beyond Rankings)

While competition results provided a clear benchmark, the primary outcomes for students extended well beyond rankings.

Through the simulation and deployment workflow, participants gained:

Hands on experience with model‑based design workflows
Practical exposure to control systems and image processing
Experience deploying and validating algorithms on real hardware
Insight into how industry engineers structure, test, and iterate designs for engineered systems.
Opportunities to build peer connections across institutions and countries.

Campus walkthrough and discussion at the MathWorks Cambridge Office

Learning Beyond the Competition: Engineering in Context

As part of the Cambridge finals, finalists also participated in an exclusive technical session on Engineered Systems, delivered by Dr. Gavin Walker from the MathWorks CDA Team. The session provided additional context on how complex engineered systems are approached in professional settings, complementing the Hands-on deployment experience from the competition itself.

Expert led‑ session on engineered system

Together, the technical challenge, peer interaction, and exposure to industry perspectives offered students a broader view of how academic knowledge translates into engineering practice at scale.

Student Perspectives: The Competition Experience

Student Team from University of Oxford

Hearing directly from participants helps illustrate what the competition workflow meant in practice. Rather than focusing on outcomes or rankings, students consistently reflected on the engineering process itself, particularly the role of Simulation.

“Spending two days at the MathWorks Cambridge Office helped us clearly understand the gap between simulation and deployment. The first day focused on testing and refining our model, followed by live deployment during the competition” – Team Abstract Quadqopter, University of Oxford

Team Abstract Quadqopter

The Minidrone Competition helped us strengthen our MATLAB and Simulink skills beyond the learnings in coursework, particularly through hands‑on development and deployment. We look forward to the next edition of this event.” – Team KNR PW, Technology University of Denmark & Warsaw University of Technology

Team KNR PW

These reflections underscore a shared experience across teams: the value of seeing theoretical designs tested, challenged, and improved when exposed to a competitive, collaborative environment.

Why This Matters for Universities and Educators

For universities and educators across the globe, the MathWorks Minidrone Competition provides a structured way to reinforce core engineering concepts through applied learning, without requiring changes to existing curricula.

The competition aligns naturally with courses in perception, guidance, navigation, and control, as well as embedded applications in UAVs and robotics, enabling students to apply theoretical knowledge to real world applications through a model based design workflow.

The Europe 2025 edition further demonstrated how such programs can encourage collaboration across institutions, exposing students to peer learning. As a result, the Minidrone Competition acts as a practical extension of academic learning, strengthening the connection between theory, tools, and real world‑ implementation.

Looking Ahead

The Europe 2025 edition demonstrated how structured, simulation first challenges can extend classroom learning into real engineering practice. As future editions evolve, the Minidrone Competition will continue to provide students and educators with opportunities to connect theory, tools, and deployment in a meaningful and applied context.

If you are interested in participating, explore upcoming MathWorks Minidrone Competitions near you.

If you would like to host the MathWorks Minidrone Competition on your campus, club, or as part of a course, please reach out to us at minidronecompetition@mathworks.com.

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.