@NamanS

Devlog #5
I moved from fixed-duration legs to distance-based dynamic timing, replacing the flat 5-second-per-leg assumption from Devlog #4 with per-leg durations computed from waypoint spacing and a target cruise speed.

I added a speed constant (2 m/s) and used it to compute t_segment as an array instead of a scalar. Each leg’s duration is now distance / speed between its start and end waypoints, so longer legs take proportionally longer instead of every leg getting the same fixed window.
I also updated the interior-waypoint velocity estimate to divide by the sum of the adjacent leg durations (t_segment(i-1) + t_segment(i)) instead of 2 * t_segment, since that shortcut only made sense when every leg was the same length.
I dropped mass to 0.5 kg to better match a real small-quadrotor class, and lowered Kp/Kd as a starting point since neither the old gains nor the old fixed timing apply anymore.

Bugs
I didn’t hit any major bugs during this section.

Where it stands now
Leg duration now reflects actual waypoint spacing instead of an arbitrary constant, which should reduce the unnatural sameness of a drone crawling across a short hop and sprinting across a long one in the same 5 seconds.

Next up
Re-tune Kp/Kd/Kr/Kw against the new mass and dynamic timing before drawing conclusions from the plots. I will also look into MATLAB’s UAV Toolbox with a built-in quadrotor animation/scene viewer that can consume my state trajectory directly.

Devlog #4
I moved from simple point-to-point waypoint chasing to smooth polynomial trajectory generation between waypoints, replacing the threshold-based switching from Devlog #3 with time-based tracking of a continuously moving target.

New machinery
I built cubicTrajectory.m, which solves a 4x4 system of equations for the coefficients of a cubic polynomial connecting a start point to an end point over a fixed duration, with velocity constrained to zero at both ends of each leg.
I also built evalCubic.m, which evaluates that polynomial’s position and velocity at any given time.
I tested both standalone before touching the main dynamics. I stored all the coefficients in one array, coeffs_all, indexed by [coefficient, axis, leg], and built a loop that chains legs together so each leg starts exactly where the previous one ended.

Bugs

1. The very first version of the leg/local-time lookup accidentally dropped global time from the local-time calculation entirely, leaving the “current time within this leg” frozen at a constant for the whole leg instead of counting up. This meant the drone’s target wasn’t moving during a leg at all, it only jumped once per leg, which produced a single sharp overshoot spike instead of a tracked path.
2. The simulation’s total time span hadn’t been updated to match the total trajectory duration, cutting the run short by a full leg.

Where it stands now
With both fixed, the drone tracks a moving position and velocity target through all four waypoints instead of chasing a static point. Spin rate and attitude plots show a clean repeating pattern, a spike at each leg transition that damps out before the next one, rather than instability or runaway spiraling.

Next up
Because every leg currently forces velocity to zero at both ends, the drone still fully stops at every intermediate waypoint before accelerating into the next leg, which is what’s producing the repeating spikes rather than a truly smooth flight. Next is allowing interior waypoints to have nonzero passthrough velocity (estimated from neighboring waypoints), plus adding acceleration feedforward into the force calculation so the controller anticipates the trajectory instead of only reacting to error. After that, the plan is still to move toward true minimum-snap trajectories.

Devlog #3
I replaced the attitude lag from Devlog #2 with real rotational dynamics such as torque, inertia, and actual angular acceleration. Previously, I was assuming that attitude eventually catches up.

New states and new physics
The state vector went from 9 to 12: added p, q, r, the drone’s spin rate around its own x, y, and z axes. These are the rotational equivalent of vx, vy, vz, just measuring how fast orientation is changing instead of how fast position is changing.
I added an inertia matrix, a diagonal 3x3 of made-up placeholder numbers representing how hard it is to spin the drone around each axis, similar to mass.
The output is torque instead of thrust, and it feeds into torque divided by inertia to produce angular acceleration.

Bugs

1. The desired-attitude error vector and the spin-rate vector were stacked in different orders (theta/phi/psi vs. p/q/r, which is roll/pitch/yaw), so the controller was correcting the wrong axis against the wrong spin rate.
2. The drone would approach a waypoint and then spiral into a slowly tightening orbit around it instead of settling, and in one attempt, diverged outward entirely. It reproduced the same spiral with a single fixed target and no waypoint switching at all. I found that the actual fix wasn’t more damping. Increasing the damping gain alone made it worse, not better. The real issue was that the attitude loop needed to react faster overall to keep pace with how aggressively the position loop was demanding tilt changes. Increasing the correction gain substantially fixed it for now.

Where it stands now
With gains rebalanced, the drone flies a full waypoint sequence with real torque-driven attitude dynamics. Spin rates spike on each maneuver and cleanly damp back to zero. One nice side effect of finally having real dynamics is that the path through a waypoint now visibly curves rather than shooting straight there, because aggressive tilting to accelerate sideways steals from the vertical thrust component.

Next up
Everything from here is trajectory generation such as replacing simple point-to-point waypoint chasing with differential-flatness-based polynomial paths. The journey has been difficult so far, especially as this is my first time interacting with vectors and matrices (3b1b’s linear algebra series is the only thing helping me out). Nevertheless, I am persevered to get a finished project.

Devlog #2

I added real orientation states (φ, θ, ψ) and made thrust act along a single body axis instead of the free-vector cheat I’d been using. This is the point where the sim actually starts being a quadrotor.

Building the rotation matrix
Before touching the dynamics at all, I built a rotation matrix that converts “straight up, from the drone’s own perspective” into “which way that is, in world coordinates.” A quadrotor only ever pushes along its own up-direction, so the only way it moves sideways is by tilting, which redirects that one push.

I built the matrix as three separate small rotations (yaw, roll, pitch) multiplied together, one for each axis, in a fixed order. I tested it with a small function, bodyZAxis(phi, theta, psi), against three hand-checks:

Level (phi=theta=psi=0) → straight up, unchanged.
Small roll → a small tilt in y, x untouched.
Small pitch → a small tilt in x, y untouched.

All three passed, which confirmed the rotation math was doing what it was supposed to before wiring it into anything else.

Wiring it into droneDynamics

The state vector went from 6 to 9: position, velocity, and now phi/theta/psi. The control loop has split into:
Outer loop (same PID idea as before) computes a desired force vector, F_des, from position/velocity error plus a gravity feedforward term.

That desired force gets converted into a desired tilt angle, using a small-angle approximation (the sideways component of a tilted thrust vector is roughly thrust * angle, solved backwards for angle given how much sideways force we want). Clamped to ±0.5 rad so a big position error can’t force a nonsensical tilt.

The actual attitude states lag toward that desired tilt with a simple first-order lag (same idea as the motor lag in my old Python project, just applied to orientation instead of thrust).

Actual thrust direction is computed from the real (possibly still-lagging) attitude, not the desired one.

Bugs, in the order I found them

1. Sign error on the gravity feedforward in F_des, which had gravity pulling the “cancel gravity” term the wrong way.

2. Sign error on the final acceleration line, where I used the wrong sign on gravity there too, which sent the drone climbing to hundreds of meters instead of hovering.

3. A big position error was asking for tilts of multiple radians (past 90°), which is physically meaningless and was part of what caused the runaway climb. Fixed with the clamp mentioned above.

Where it stands now
With the signs fixed and the tilt clamped, the drone tracks through the same waypoint list as before, but now via real (if simplified) attitude dynamics. I can see roll and pitch spike up during each leg of the trip and settle back down as it arrives at a waypoint, instead of the instant, direction-agnostic thrust from the old model.

Next up
This 9-state model is still leaning on a simplified attitude lag instead of real rotational physics, with no torques, no moment of inertia, no angular velocity states. The next real step is adding those (a 12-state model), replacing the lag with actual torque-driven rotation. After that, there is differential flatness and real trajectory generation, which is the actual point of this whole project

Devlog #1

I’ve built a drone sim before, such as a Python project with Plotly animations, PD control, motor lag, drag, the works. It looked good, but it had a problem where the “drone” was really just a point that could apply force in any direction, instantly. Real quadrotors can’t do that, because they only push one way (straight up from their own frame) and have to physically rotate to redirect that push.

I’m now pushing myself to build a research-style quadrotor simulator in MATLAB.

The plan:
Start with a 9-state model: position, velocity, and orientation (roll/pitch/yaw).
Verify a hover with a basic PID controller first.
Later, move to trajectory planning using differential flatness (generating smooth polynomial paths and computing the forces needed to fly them)
Eventually stress-test trajectories by speeding them up / slowing them down and watching what that does to the required forces.

In this devlog, I covered:
Milestone 1: 1D hover
Before touching 3D, I built the simplest possible version, a single point that can only move up and down, controlled by:
thrust = massgravity + Kperror - Kd*velocity

Using MATLAB’s ode45 to integrate [z; vz] forward in time. I learned what an ODE solver does.

Milestone 2: 3D
Next step: extend to a full 3D position [x,y,z,vx,vy,vz], but still letting the controller output force in any direction. This is the same “free vector” simplification my old Python sim used, kept on purpose this time as an isolated stepping stone. The goal was to prove the PID math generalizes to 3D before adding the complexity of real attitude dynamics on top.

In my first test, the drone was pointed at a single fixed target. It gave a perfectly straight line, and it took me a second to realize that wasn’t a bug: since x, y, and z all use identical gains and start at rest, they move in lockstep, always in the same ratio to the target.

Milestone 3: chasing waypoints
I added a list of waypoints instead of one static target, with the controller switching to the next point once it gets within a 0.5 m of the current one. This needed a persistent variable inside the dynamics function to track which waypoint index it’s on, since ode45 calls that function many times per step and nothing about waypoint progress lives in the physical state vector itself.

This gave path that actually bends at each waypoint instead of a straight shot. The corners are sharp however, instead of being smooth.

Next up
I’m going to be adding adding real orientation states (φ, θ, ψ) and constraining thrust to act along a single body axis, the way an actual quadrotor works. That’s the point where this stops being a point-mass simulation and starts being a quadrotor simulation.

Devlog #9 (Hopefully the last one)

I spent this session pulling everything together for shipping. I sorted out the actual folder structure needed for submission: a top-level project folder containing CAD, PCB, and Firmware source folders, plus a separate production folder with the manufacturing-ready files. I copied the firmware source files (keyboard.json, keymap.c, rules.mk) over from the WSL environment into the Windows-side project folder to get everything in one place ready to push to GitHub. I also wrote the README covering the CAD assembly, schematic, PCB, case, and firmware.

Challenges:
I didn’t face many challenges during this step. Most questions were answered by searching on Google.

Next Steps:
All I need to do now post in #hackpad-ships and fill out the submission form! Wish me luck!

I continued working on the CSS for the website. I fixed a few bugs in my code, like a typo where I had a space inside var() which was breaking my background grid. I also styled the nav bar, the hero section, and the small uppercase labels above each section. Additionally, I added a grid pattern in the background to give it a math notebook style to it. I also went through my HTML and remove any unnecessary CSS classes that I had added before.

I have started to implement the basics of the website. I created the basic layout of the website and where I plan to add each element of the website. For example, I laided out the full HTML skeleton with the header then About, Projects, and Contact sections below. I also started the CSS by setting up custom properties (:root variables) for my color palette and fonts so I’m not repeating hex codes everywhere. I also added a background color and font color and style.

Devlog #8
I wrote and compiled the updated firmware.

I got the QMK firmware finished for the final 7-key layout plus the rotary encoder and OLED. I updated keyboard.json to match my actual pinout, then ran into a string of small compile errors working through keymap.c: wrong argument count for LAYOUT() since my key count changed, a stray trailing comma, and using MATRIX_LAYERS which isn’t actually a valid macro in this QMK version, just needed a “1” for a single layer.

I ended up swapping Close Tab for Paste in the final key layout so Copy and Paste are usable together instead of just having Copy on its own. The final layout is New Tab, New Window, Undo, Redo, Refresh, Paste, Copy, with the encoder controlling volume and the OLED showing a static ready message for now.

Challenges:
Getting a clean compile didn’t actually mean the firmware did what I expected, since I realized later that I was still missing the rules.mk file.

Next Steps:
The firmware compiles clean and outputs a working .uf2 file. I’m going to package everything up for submission: Gerbers, case files, firmware, README, and BOM. I might also add some flair to the Tinkercad case to make it more personalized.

Devlog #7
I spent this session finishing the plate and case design.

For the switch plate, I used ai03’s plate generator, converting my actual switch coordinates from KiCad into KLE units to match my diagonal layout. The generator only handles switch cutouts though, so I had to add the encoder shaft and OLED window manually afterward.

For the OLED cutout specifically, I went back and forth on sizing. I initially calculated the exact active pixel area from the display’s diagonal and aspect ratio, landing on 22.4mm by 5.6mm, and later confirmed that matched published specs for this exact 0.91 inch 128x32 panel almost exactly. But once I found and applied an actual KiCad footprint for the specific SSD1306 module in my kit, it gave me a real, confirmed “OLED Panel” reference rectangle at 12 by 29.5mm, which I ended up using instead since it meant I had exact coordinates to work from rather than an estimate, and it also gives a cleaner look showing the whole black display bezel rather than a tightly cropped window.

I also reconsidered how the XIAO should sit in the case after seeing a reference build with the microcontroller mounted visibly on the front instead of hidden on the back. I decided I liked that look better and flipped my XIAO footprint back to the front layer, which meant deleting and rerouting all of its traces from scratch since flipping a footprint doesn’t automatically carry old routing over to the new pad positions.

I also seriously considered adding SK6812 addressable LEDs under the switches, since the kit includes them. Worked out a plan to free up a pin by moving the encoder’s click button into an open matrix slot instead of giving it a dedicated GPIO, but ultimately decided against it. My switches and keycaps are just standard opaque parts, not shine-through ones, so the LEDs likely wouldn’t have been very visible anyway, and it didn’t seem worth the rework for a feature that might not even show up.

Challenges:
The diagonal-stagger switch layout kept creating small complications throughout this whole case-building process, from margin offsets to plate generation to figuring out exact cutout positions. Also learned the hard way that flipping a footprint mirrors the pads but doesn’t move existing traces with it, so that was a full reroute rather than a quick fix. Overall, my time spent with Tinkercad was difficult, and if I had to restart the design I would’ve used OnShape for greater precision and its advanced features.

Next Steps:
The case and plate are both done. Now I’m moving on to firmware, starting with the keymap and getting the encoder and OLED working in QMK.

Devlog #6
I started rebuilding the case for the new PCB design.
After finishing the PCB layout with its diagonal-stagger switch arrangement, I moved into CAD to build a matching case, working through a much more complex shape than my first attempt since the board isn’t a plain rectangle anymore.

My first try at this was rough. I was eyeballing most placements, zooming in super close and manually nudging shapes by dragging until things looked roughly aligned. It kind of worked, but margins ended up inconsistent between edges, and rounding corners or offsetting the diagonal edge properly was nearly impossible to get right by eye. I ended up scrapping that entire first attempt once I learned Tinkercad actually has real alignment tools and exact coordinate input in the properties panel, instead of relying on visual snapping and guesswork. I threw away around 1.5 hours of work and redid the whole model from scratch using typed coordinates and the align tool wherever two edges needed to match exactly, which gave a cleaner result.

Also had to work out how to offset the diagonal edge specifically, since scaling a duplicate shape up distorts a diagonal edge into a taper instead of a consistent parallel margin, so I calculated the perpendicular offset separately from the straight edges to keep the margin even all the way around.

Overall, I got the base and outer walls built with a consistent 10mm margin, added 4 mounting holes using the guide’s direct-into-plastic method with 2.9mm holes, and rounded the four corners for a cleaner look.

I was also considering an LED backlighting idea, but decided to drop it since it would’ve needed a spare GPIO pin I don’t actually have on the XIAO.

Challenges:
I realized that I probably should have learned to use Tinkercad a bit more before jumping into the project, as I didn’t know how unreliable eyeballing was. Also I caught a mismatch between my schematic and PCB where a switch had been removed from the board but was still present in the schematic, which needed re-syncing.

Next Steps:
The case walls and base are done. I still need cutouts for the OLED window, encoder shaft, and USB-C port.

Devlog #5
I spent this session finishing the physical PCB layout, which ended up being a much longer process than I expected because I went through three fairly different approaches before landing on something that actually worked.
First off, I decided to give the left column of switches a diagonal stagger instead of a straight grid, inspired by a macropad by Froskeys in the Hackpad galley, that used a similar fanned-out layout. The idea is that a diagonal arrangement follows the natural arc your fingers make when your hand rests on the board, so reach feels more even across all the keys instead of some being awkward stretches.

My first attempt was just a plain grid of 8 switches with no real thought behind the physical arrangement. It technically worked, but it didn’t fit within the 100x100mm size limit the Hackpad program requires, coming in at 108mm vertically. I also tried to save space by placing the XIAO microcontroller underneath three of the switches. Even though the components were on opposite sides of the board, the actual drill holes for switch legs and XIAO pins still passed through the entire board thickness, and landed on top of each other. That was a good lesson that opposite layers doesn’t always mean that a collision won’t occur.

My second attempt scrapped the overlap idea entirely and instead focused on compressing spacing everywhere: tightening the switch pitch to exactly 19.05mm, pulling the encoder and XIAO in closer, and moving the OLED header and capacitor out of dead space. This got me under the limit, but the layout still felt a bit boxy and arbitrary.

For the final version, I took some advice from my brother who walked had walked into my room and immediately told me that the design would look better if it was entirely rotated. Initially, my diagonal edge was on the left, but instead rotating it to the bottom also provided a distinct asymmetric shape while keeping it’s ergonomic function.

Along the way I also had to fix a wave of Design Rules Checker errors and add mounting holes without letting their clearance rings collide with nearby components, which happened more than once. Finally, I designed the copper pathways to connect all the components and provide a finalized PCB.

Challenges:
The biggest recurring issue was learning that visual inspection alone isn’t reliable for catching real electrical problems. I found that several times a layout looked fine by eye but DRC caught actual shorts or courtyard violations I hadn’t noticed. I also learned the hard way that mounting hole footprints include a much larger keepout zone than just the drill hole itself, which caused an unexpected collision with the XIAO’s pins.

Next Steps:
The layout is finalized and DRC is clean. Next is fixing the case design I have in Tinkercad to update the new PCB layout, and eventually writing the firmware to match this final pinout.

Devlog #4
Finished assigning the footprints for the project and finally got a completely clean ERC with 0 errors.
Moved into the PCB editor after that and immediately hit the 100x100mm size constraint. My first layout came in at 108mm vertically, so I spent a while compressing the diagonal switch stagger, tightening spacing to exactly 19.05mm, and moving the OLED header and capacitor out of dead space.
Then I tried to reclaim even more space by tucking the XIAO underneath three of the switches instead of placing it separately, since it’s flipped to the back layer anyway for assembly. Ran DRC to check for collisions and it came back ugly, with actual solder mask bridges between XIAO pins and switch pins on completely different nets. Also had courtyard overlaps between a few diodes and switches, and hadn’t drawn the board outline yet so some checks couldn’t even run properly.

Challenges:
I’m still learning that even parts on opposite layers can collide, as the pins themselves are still physical holes drilled through the entire board. So a switch’s hole and the XIAO’s pad can still land on top of each other even though the components sit on opposite faces.

Next Steps:
I’m going to scrap the XIAO-under-switches idea. Going back to a layout where nothing overlaps, and instead squeezing space by tightening gaps between all components more aggressively across the whole board. Once placement is solid and collision-free, I can finally draw the board outline and start routing.

I’ve completed the lessons on STM32CubeIDE, Pin-Out Configuration, Crystal Circuitry, and USB. This was my first time using STM32CubeIDE, so there was a lot to learn beyond just the hardware design itself. I also learned why external crystals are used for accurate clock generation and how the USB circuitry is connected so the microcontroller can communicate with a computer. It’s been interesting seeing how all of these supporting circuits come together to make a functional STM32 board.

Challenges:
The biggest challenge was definitely getting STM32CubeIDE set up. I spent quite a while troubleshooting before realizing I had installed the wrong version. I originally downloaded version 2.2.0, but the course uses 1.9.0, so I had to uninstall it and install the older version before I could continue. Since all of this is completely new to me, it took some patience to understand both the software setup and the new hardware concepts.

Next Steps:
I’ll continue working through the schematic section of the course and keep building out the STM32 design. My goal is to finish the remaining schematic lessons before moving on to PCB layout and routing.

I’m starting to feel more comfortable with the STM32 hardware design workflow, and I’m looking forward to putting everything together into a complete board.

Devlog #3
I went back into the schematic after realizing I was only using 3 of the 16 switches from the kit. Expanded the design to 8 switches wired in a proper 4x2 diode matrix, added one of the rotary encoders, and wired in the 0.91” OLED screen. I spent most of the session debugging the Electrical Rules Checker, which kept flagging power pin errors I didn’t understand at first. I think it’s because I had multiple 3V3 symbols that weren’t actually connected to each other since power symbols only merge nets if they’re physically wired together, not just because they share a name. Fixed that by adding a PWR_FLAG.

Challenges:
Understanding how diodes and rotary encoders work helped me implement new ideas into my hackpad.

Next Steps:
Get the XIAO footprint sorted with the correct library, then finish assigning footprints to the diodes, header, and encoder. After that I can finally generate the PCB layout from the schematic and start routing traces for the full 8-switch matrix instead of just the 3 I had before.

I started working through the Learn KiCad V6 and STM32 Hardware Design course today. My goal with this project is to get more comfortable designing PCBs from scratch while learning the hardware design practices used with STM32 microcontrollers. Right now I’m working through the Schematic section, where I’ve completed the lessons on STM32 Microcontroller and Decoupling and STM32 Configuration Pins. I learned why decoupling capacitors are placed close to the microcontroller’s power pins to improve stability, as well as the purpose of configuration pins like NRST and BOOT0 and the supporting circuitry they require. It’s been interesting to see how much more goes into designing a reliable board than simply connecting components together.

Challenges:
Most of the concepts are new to me, so I’m taking my time to understand why each component is included rather than just copying the schematic. Reading reference circuits and understanding the purpose of supporting components has been the biggest learning curve so far.

Next Steps:
My next step is to download STM32CubeIDE and continue with the Pin-Out and STM32CubeIDE lesson. After that, I’ll keep working through the schematic section before moving on to PCB layout and routing.

I’m excited to keep building my hardware design skills and eventually design my own STM32-based boards from scratch!

Hello! I have decided that since I will be starting university in the next 2 months, I should make a workplace platform for organization. I chose to start making a Personal Dashboard, where I will list tasks, make notes, and add a habit tracker.

The fundamental layout of the website includes separating tabs in a navigation bar, with options such as Tasks, Notes, Habits, etc. So far, I have created a gradient, glass-style interface. This primarily focuses on HTML and CSS to improve visual design.

I plan to continue finishing the layout and starting the overview and tasks section. Some features include giving the user an option to create a personal task list. It has been a while since I last used any web development languages, making this a slight challenge since I’m learning a lot of new syntax.