Why Algorithm Analysis Belongs in Mechatronics

1The question a mechatronics student should ask

"Why am I analysing algorithms in a mechatronics department? I build robots and machines, not databases." It is a fair question, and it has a sharp answer.

In a spreadsheet or a website, a slow program is annoying. In a mechatronic system — a robot arm, a drone, an engine controller, a 3D printer — a slow program is a failed machine. The software is not sitting on a desk; it is bolted to something that moves, and that something will not wait for your code to catch up. A controller that computes its correction a few milliseconds too late does not return a late answer. It returns the wrong answer, because by then the arm has already moved.

That is why this course is not a detour from your degree. It is the part that decides whether the clever control law you derive in another course can actually run on the hardware in your hand.

2The deadline: turning a sample rate into a time budget

A digital controller runs in a loop: read the sensors, compute a correction, drive the motors, repeat. It repeats at a fixed sample rate. A common rate for a motor control loop is 1 kHz — one thousand times per second. That single number sets an unforgiving budget:

1000 loops per second  →  one loop every 1 millisecond  →  every read, compute and command must fit inside 1 ms.

Now recall the whole point of this course: how does the work grow with the size of the problem? Suppose your loop processes n data points — points from a lidar scan, pixels in a camera row, samples in a filter window. Here is how much room a 1 ms budget leaves you, assuming a modest microcontroller that manages about ten million simple operations per second:

Read the O(n²) row carefully, because it is the one that ends careers. It works perfectly on your desk with ten test points. It works in the demo with fifty. Then the real sensor delivers three hundred points, the loop takes longer than 1 ms, the next cycle starts late, the one after that starts later still — and the control loop, which assumed a steady 1 kHz, goes unstable. The robot shakes itself apart not because the maths was wrong but because the algorithm's growth was wrong.

3The tiny computer: why memory is a wall too

The laptop you wrote this course's code on has billions of bytes of memory. The microcontroller inside a mechatronic product — an STM32, an ESP32, an Arduino-class chip — has kilobytes. Not gigabytes. Kilobytes. It runs at tens or a few hundred megahertz, not gigahertz.

So the space side of complexity, which we mostly waved at in this course, becomes a hard ceiling. An algorithm that needs an n × n table (O(n²) space) to process an n-point scan may simply not fit in RAM, and the program will not run at all — no amount of patience helps. Choosing an O(n) algorithm over an O(n²) one can be the difference between "ships in the product" and "does not fit on the chip".

The space–time trade-off, made of copper and silicon

Remember the anagram counter in week 9: it spent a little memory (two tally arrays) to save a lot of time. Mechatronics does exactly this trick constantly, and gives it a name: the lookup table (LUT). Computing sin() on a small microcontroller is slow. So instead you compute the sine of every angle you will ever need once, store the answers in flash memory, and at run time just read the answer — turning a slow calculation into an O(1) array lookup.

import math, time

# build the table once (this happens before the robot runs)
STEPS = 3600                               # 0.1-degree resolution
sine_table = [math.sin(2 * math.pi * i / STEPS) for i in range(STEPS)]

def sin_computed(angle_deg):
    return math.sin(math.radians(angle_deg))          # the slow way, every call

def sin_lookup(angle_deg):
    return sine_table[int(angle_deg * 10) % STEPS]     # O(1) read

N = 1_000_000
start = time.perf_counter()
for i in range(N):
    sin_computed(i % 360)
t_calc = time.perf_counter() - start

start = time.perf_counter()
for i in range(N):
    sin_lookup(i % 360)
t_lut = time.perf_counter() - start

print(f"compute: {t_calc:.3f}s   lookup: {t_lut:.3f}s   {t_calc/t_lut:.1f}x faster")

On a laptop the gap is modest, because a laptop has hardware built for floating-point maths. On a microcontroller without that hardware, the same lookup can be tens to hundreds of times faster — and it costs you exactly one array of numbers in flash. That is the week-9 trade-off, now measured in bytes of memory against microseconds of deadline. Motor controllers use this for sine commutation; sensor code uses it for calibration curves; graphics uses it for everything.

4Where each week shows up in mechatronics

None of this course was abstract. Every idea has a direct home in the machines you will build. Here is the map.

5A worked mechatronics decision

A vibration sensor on a motor gives you a window of the last w readings, and you want the median each cycle to reject spikes. The obvious way sorts the whole window every time. Is that fast enough at 1 kHz?

import time, random

def median_of_window(window):
    ordered = sorted(window)          # O(w log w) every single cycle
    return ordered[len(ordered) // 2]

# simulate one second of a 1 kHz loop, window of w readings
for w in [16, 64, 256, 1024]:
    window = [random.random() for _ in range(w)]
    start = time.perf_counter()
    for _ in range(1000):             # 1000 cycles = one second at 1 kHz
        median_of_window(window)
    per_cycle_us = (time.perf_counter() - start) / 1000 * 1e6
    verdict = "fits 1 ms" if per_cycle_us < 1000 else "OVERRUN"
    print(f"w={w:>5}: {per_cycle_us:8.1f} us per cycle   {verdict}")

On a laptop the sort-every-cycle approach survives even a large window. But notice the trend — the per-cycle cost is climbing with w log w, and on a microcontroller a hundred times slower, the w = 256 row alone would blow the 1 ms budget. So the engineering answer depends on the numbers: for a small window, ship the simple version; for a large one, reach for a smarter structure (a running median, or a heap) exactly as this course taught you to. You measured, you found the crossover, you chose with evidence. That is the entire method, applied to a real machine.

6How this course connects to the rest of your degree

Algorithm analysis is a hub. It quietly sits underneath much of what comes later in a mechatronics programme:

So the honest answer to "why algorithm analysis in mechatronics?" is this: because you, unlike a web developer, cannot just buy a faster computer. The computer is bolted to the robot, chosen for cost and power and size, and it is not changing. Inside those fixed limits, the algorithm you choose is the difference between a machine that holds steady and one that lags, overshoots, or shakes itself apart. Choosing well is not computer science trivia. It is mechatronics engineering.

7One last exercise

8Where to go next