Winter 2025 Course Journal: EECS 461

Course Title: Embedded Control Systems

Motivation

I enrolled in this course because of two reason:

  • I checked the list of upper-level courses I must pick one from and this is one of the only three options that don't mess up my schedule
  • Mark Brehob recommended it so it must be good

The other two courses are EECS 491 (distributed systems) and 483 (compilers). I have 491 in my backpack right now, but am thinking of dropping it because workload. It really hurts me to drop a course offered by one of my favorite professors. But compared to 461, it's less relevant to my career, so I need to let go if I have to. 483 is another matter. I doubt I have the math background.

The funny thing is, each of these courses teaches a different language:

  • 461: C
  • 491: Go
  • 483: Rust

I'm stuck with the worst of the worst, aren't I. floofmug

First lecture

The professor is Jeffrey Cook. He carries a suitcase, which ranks him at 2nd place on my "coolest thing to carry to lecture" leaderboard (1st place is Robert Dick with his Panasonic Toughbook).

The course involves a haptic wheel (motorized steel wheel, ~10 cm in diameter), some NXP ARM MCU, C, MATLAB, Simulink, and Stateflow.

Cook said in lecture that you can't declare variables in the middle of a block, only in the beginning. I was like, no way that's true, that must be an outdated version of C. I tried a counterexample on my gcc, and it worked all the way back to C99. He said, "well, at least it's like that on the lab compiler."

It turns out the rule dates back to C89. Which means? I'll be working with C89 for the rest of the semester.

mosfet_grub

First lab

I hate that the first lab is about MMIO and GPIO, which means I have to relive 373. It's like having to beat a tedious game level that you already passed one year ago with 28 tries. I went from MMIO to digitalWrite, and now the rock is rolling down the hill. floofmug

Giving up

Once a homework question asked me to derive some sort of transfer function, find the steady state response, plug in some values, and compare it with Matlab simulations. Somehow I couldn't manage to get them to agree. So I just put in "I have failed to replicate an answer consistent with 2(d)."

Haptic wheel

The centerpiece of our lab is the haptic wheel. In lab 4 and 6 we built the so-called "virtual worlds", which are just functions that, given the position of the wheel and optionally the velocity, returns the torque that should be applied. With them you can simulate all kinds of stuff like a spring, a wall, a damped spring, a wheel connected to a virtual wheel via a spring, and a control knob with detents. It's crazy how realistic it can be. Human interfaces are an interesting topic.

Midterm

Honestly did not do well. Excuse: I had a fever.

Project

The project, like the labs, is on training wheels. We were basically following the same template. If it doesn't work, well, we'll make it work by any means necessary. Since this is the last semester, I'm really thankful to our GSI for all the help.

The project is a simulated vehicle with automatic cruise control (ACC) and auto steering. The ACC makes the car go at a certain speed, or follow another car ahead of us. The auto steering makes the car stay at the center of the lane (or, in our case, the center of the road).

The project is done in three parts, one each week. The first is getting manual driving to work; the second is ACC; the third is steering. All this was done in Simulink, by dragging blocks around. Then, we would let Simulink generate the C code, flash it on the devkit, and open a simulator that somehow runs Unreal Engine within Simulink. The simulator would crash whenever our car hit the "wall" of the virtual world.

I know I shouldn't say this, but I have a feeling that you don't need to have taken 461 to do this. Most of the logic was already implemented in the library. All we had to do was just copy a diagram on the whiteboard, and implement certain subsystems that may or may not pertain to 461 knowledge at all. For example, for part 2 we had to write an S-function (Simulink block that's written in C) that outputs the speed and position of the "lead vehicle". It's just a for loop that looks for the closest car ahead of us. A first-year student can write this without a hiccup. And for part 3, the PD controllers we had to implement were just copied straight off the homework. All it took us was five minutes to solve for some parameters.

What I like about the project is the moderate workload and how our GSI literally nannied us all the way out. It doesn't really feel like a 400-level course.

What I dislike about the project is how hard it is to debug anything. It was impossible to see what the hardware was actually doing, like the ADC value, unless you map that to, for example, the LEDs. That was a major frustration in part 1 and 2.

In part 3 we were fairly confident that auto steering was gonna work, but the steering would always spin out of control. We knew there was a minus sign missing somewhere, because it's supposed to be a negative feedback loop. After three rounds of trial and error, we managed to fix it, and let our car just drive on its own at ~100 km/h.

End of course

With the project ending and no final, 461 has officially come to an end. But I have a feeling that I didn't "learn" anything. Of course, I learned to do homework questions and to finish labs, but I'm not fully convinced I internalized anything. Instead, all I've been doing was pattern matching the omegas and zetas, substituting values into equations, and trying stuff until it works. I did build intuition to a certain degree regarding damped oscillators and their relationship to second-order differential equations, but I did not build intuition for PID controllers at all.

Prof. Mark Brehob once had a chat with me. Mark said an engineering discipline is like a foreign language — second nature to fluent speakers, so much so that they think in that language, but newcomers will find themselves struggling to untangle the most trivial detail. It's quite true.

It is weird because I view myself as leaning more hardware than software, yet now that I think of it, I can't reason about hardware as much as software. If you show me a circuit with two or more opamps, I can't figure out what it is, but I can tell you about how virtual memory works. Maybe I should reassess that statement.

I'm fairly sure I will never do VLSI. I will probably not do mobile apps either. There's a niche window on the hard-soft spectrum that I'm interested in. It goes to PCB design at its hardest, and web development at its softest, and converging in embedded firmware. It does seem that CE was the right choice when I came to UM.