Devlog #7
Subject: Upgrading the Sensor Suite & Advanced Vario Estimation
Date: 8/12

After starting to making the BOM and other details for the drone i diced to making an update of the hardware

I updated the PCB IMU to an industrial-grade Bosch BMI088 (with GYRO CS on PA4 and ACC CS on PA4) and swapped the barometer for an SPL06-001 (BARO CS on PA0, MAG CS on PA3).

This hardware revision allowed us to introduce major firmware variations:

• Firmware V003 (XDQ-001F_V003.ino): Direct hardware support and pinout re-routing for the new BMI088 (dual-die SPI mode 0/3) and SPL06-001 barometer drivers.
• Firmware V004 (XDQ-001F_V004.ino): Advanced sensor fusion algorithms including a 3rd-order Complementary Altitude & Vario Estimator (fusing SPL06 baro and BMI088 AccelZ at 1kHz for lag-free vertical speed estimation) and a PT2 (2nd-order) Low-Pass Notch Filter on the BMI088 gyro to suppress motor vibration noise before the PID loop.

🚀 XDQ-001 Devlog: Sensor Suite Overhaul & Vario Fusion

Here is a quick update on the latest hardware and firmware milestones for the XDQ-001 flight platform.

1. PCB Hardware Upgrade (August 12th)

We upgraded the onboard sensor suite to industrial-grade components. The FCB now houses a Bosch BMI088 IMU (separate gyro/accel dies for superior vibration resistance) and a Goertek SPL06-001 high-resolution barometer. The SPI CS routing was updated accordingly (GYRO CS & ACC CS on PA4, MAG CS on PA3, BARO CS on PA0).

2. Driver Integration & V003 Firmware (August 12th)

With new hardware comes updated firmware. We wrote dedicated drivers for the BMI088 (handling its dual SPI Mode 0 / Mode 3 requirements and ±24G / ±2000 dps scaling) and the SPL06-001 (decoding its 18-byte calibration array). All of this was packed into XDQ-001F_V003.ino, keeping V002 safe as a backup.

3. 3rd-Order Vario & Altitude Fusion (August 12th)

Why get better hardware if you aren’t going to push it? In XDQ-001F_V004.ino, we built a 3rd-order Complementary Altitude/Vario Estimator that runs inside the 1kHz ISR. It fuses earth-frame Z acceleration with barometric pressure to calculate instantaneous vertical velocity (climbRate_mps). Altitude lock during autonomous waypoint missions is now smoother than ever without any altitude lag.

4. PT2 Gyro Filtering & Tuning (August 12th)

To clean up motor noise before it hits the PID controllers and the SO(3) geometric attitude loop, we added a 2nd-order Low-Pass Filter (PT2) with a 90Hz cutoff directly on the BMI088 gyro channels. We also re-tuned Mahony’s Adaptive Accel Gating to leverage the ±24G dynamic range during aggressive maneuvers.

🚀 XDQ-001 Devlog: The Last Month

I know I disappeared for a month. Here is a quick, easy-to-read update on what I’ve recently been developing for the XDQ-001 drone.
I have focused on simulating, visualizing, and refining the control and navigation algorithms to ensure smooth flight and navigation, as well as robustness under extreme conditions.

1. Teaching the Drone to Balance (July 19th)

We kicked things off by focusing on the drone’s “attitude”—basically, how it balances and tilts in the air. We built the core logic (PID controllers) so the drone can stay stable even if we send it aggressive commands. To make sure everything was working right, we also set up some visual tools to watch the simulation data in real time.

2. Navigating and Visualizing the Path (July 26th)

Next up: Navigation! We connected our new balancing act with algorithms that tell the drone where to go. To actually see what the drone’s “brain” was planning, we built some cool Python scripts that render 3D flight paths.
We also made some nice flowcharts (using Mermaid) to keep our ideas organized.

3. Automated Virtual Flights (July 26th)

Nobody wants to test untested code on a real, expensive drone. So, we built a pipeline that automatically runs the drone through different virtual missions: Route (following waypoints), Orbit (flying in circles), and RTL (Return to Launch).
We also added tools that check how accurate the drone’s internal GPS and sensors are during these flights. Now, it can test itself before we ever take it outside!

4. Making the Drone Tougher (August 1st)

The real world is messy—there’s wind, vibrations, and sensor noise. To deal with this, we added something called Accel Gating. Basically, if the drone gets hit by a sudden gust of wind or a sensor throws a crazy number, the drone is now smart enough to say, “That data looks wrong, I’m ignoring it.”
We ran dozens of automated stress tests (adding fake wind and latency) to prove it works.

5. Ready for the Real World (August 1st)

Finally, we moved all this tested, simulated code over to the actual drone firmware (XDQ-001F_V002.ino). Everything compiled perfectly and is officially loaded onto the real hardware.

Devlog #5

Subject: Finishing the PCB

Date: 7/1
I finally finished re-routing the PCB; it was one of my most challenging tasks, as I had to manage various signal lines (SPI, UART, USB) while prioritizing noise control and isolation to prevent interference with the traces.
The board is essentially a flight controller (FCB) featuring an IMU, magnetometer, barometer, MCU, and flash memory, along with external connectors for the ESC, radio, GPS, etc. It measures 45x50mm—compact compared to commercial double-sided flight controllers—and is a 4-layer board.

Devlog #4

Subject: Rerouting the PCB
Date: 6/30
Today, I wanted to redo the PCB routing and component placement to reduce noise and the amount of copper and vias used.
I am trying to simplify the PCB placement and routing, aiming to use the fewest possible vias and clean connections.

Devlog #3

Subject: Start to making the firmware and nav algorithms

Date: 6/28
I have started developing the drone’s firmware—including PID control and navigation algorithms—by basing it on and modifying the firmware from my previous fixed-wing project to adapt it for a rotary-wing drone.
I also incorporated new filters and algorithms to leverage the STM32F4’s capabilities and optimize flash memory management.

Devlog #2

Subject: Finishing CAD & Adding Fasteners

Date: 6/22/2026
I was finalizing the CAD modeling; in this case, the only things I hadn’t done were drilling the holes for the countersunk screws, threading, rounding the chassis, and conducting motion studies to see how the drone behaves.

Devlog #1
Date: 6/16/2026
Subject: Making CAD Design
I decided to discard the original design I had created due to a reorganization of the FCB I’m going to use.
I redid the unfinished models, like the frame, and adjusted the size to minimize this. However, space management is a problem; accommodating the ESC, FCB, external GPS, and radio can become a hassle if I don’t carefully plan the placement of each component.
I’m starting to brainstorm ideas for my own navigation and management algorithm, primarily as an alternative to Betaflight and other similar software.