The full set of objectives is given in the first part of this series, but we thought of the following steps (and goals) for the first prototype -

1. Find and evaluate a suitable MCU: The MCU need not be the most advanced, or posess some esoteric features (such as AI, image-processing etc.) for now. It must be sufficient to drive the other components and run the control system in real-time.
2. Find and evaluate a suitable IMU: We wanted to use a high-performance IMU for our flight controller, moving away from the hobbyist category. In contrast the MCU, we could directly opt for a state-of-the-art IMU, because the IMU is what truly determines the flight controller's performance.
3. Repeat the previous step for a barometer.
4. Repeat the previous step for a magnetometer.
5. Combine the components into a single Flight Controller Board.

In each step, we would pick as few unknown variables to test as possible. For example, in the case of the IMU, we would test the evaluation board with a ready-made Arduino Library, ensuring that a failure could only be caused by the IMU itself, not the testing infrastructure. Next, we would write a custom driver to verify the correctness of the algorithms and register-accesses on the Arduino. Finally, we would move the custom driver to our custom MCU board. In each step, there is exactly one unknown variable being tested, making failure detection and debugging faster. The following sections explain each of the above steps in greater detail.

For the MCU, we mainly needed a compact package and low-power consumption. Compute was not a major concern as modern MCUs are already well-equipped for real-time control.

A BGA package would be ideal, but we were conservative in estimating our design, and our supplier's fabrication capabilities, thus opting for an LQPF package for the first iteration. A BGA chip would require fine-routing, via-placement and be risky to assemble.

We ended up choosing the STM32F417VGT7 microcontroller. The F4 series from STMicroelectronics is a popular, well-documented core with fairly high performance.The processor we chose has 1MB of Flash, 192KB of SRAM, an ARM Cortex M4F core @168MHz and other peripherals such as CRC, Hashing etc. The PCB was a 4-layer design, which we found to be suitable for our needs.

A detailed description of our evaluation board for the STM32F4 can be found in the second part of the series. Primarily, it includes the following -

• Dual USB-C (one dedicated for USB-UART functionality through a CP2102 chip).
• 3.3V 1.3A regulator.
• Power selection jumpers (multiple power modes including USB, 5-6V external, 3.3V external and SWD).
• STM32F417VGT7 chip.
• 24MHz external RC oscillator.
• Micro SD Card slot (push-push for extra convenience).
• Dedicated Boot and Reset buttons.
• Dual-row, female GPIO connectors on each side.
• Power indication and user-controllable LEDs.

For the flight controller prototype, we have also included 2 additional indicator LEDs, which make it easy to show the state of the firmware and display debug information.

By the time we reached the sensors, we had already evaluated a number of related components (such as voltage regulators) and were quite confident in the design and fabrication.

Consequently, we decided to opt for the ICM-45686 IMU, as it was the latest (at the time) 6-axis IMU from TDK, a reputed manufacturer for such products. Going with IMUs such as the MPU-9250 and MPU-9255 from Invensense would provide no benefit, while consuming the time and cost of an entire iteration.

For the the final flight controller, we wanted to use dual IMUs in a redundant configuration. The reason was explained in detail in the first part of the series, but to summarize -

• For a drone to remain stable and controllable, data from several sensors to be combined. Whil the barometer and magnetometer enhance flight stability, they are not critical for flight control.
• A baro failure can cause inaccuracy in altitude-estimation, and mag failure can cause slight heading-drift, but an IMU failure leads to a crash right away.

Once a single IMU was evaluated, it would be no more effort to another to the PCB. Being such a critical sensor and requiring no additional effort, we decided to add two to the first prototype itself.

A detailed description of our evaluation board for the ICM-45686 IMU can be found in the third part of the series. Primarily, it consists of the IMU itself, a voltage regulator, an indicator LED along, I2C address-selection jumper and SPI, I2C pins on the sides (including pull-up resistors on SDA, SCL and CS lines).

The barometer (pressure sensor) was the next piece of the puzzle, and we decided to use the BMP-580 from Bosch. During our research, we found other common barometers such as the BMP-280 to be NRND, while the BMP-390 was somewhat inferior to the BMP-580.

Also in tune with the IMU, we decided to add two barometers to the first prototype to achieve redundancy, as it would be no more difficult than using a single one.

A detailed description of our evaluation board for the BMP-580 can be found in the fourth part of the series. Primarily, it consists of the Barometer itself, a voltage regulator, an indicator LED along, I2C address-selection jumper and SPI, I2C pins on the sides (including pull-up resistors on SDA, SCL and CS lines).

The final part of the sensor evaluation was the magnetometer, which proved to be the most problematic. During the design process, we realized that many of the widely-used, performant magnetometers were NRND, and the newer ones were outside our comfort zone in the design and fabrication. At last, we decided to go with the IST-8310 from Isentek. It was pricey, but was the most suitable option otherwise.

The design process was quite straightforward, but we were behind schedule because of the aforesaid research. This was when we found out that the IST-8310 had an unusually high lead-time and waiting for it would delay the rest of the project further. Consequently, we decided to postpone the magnetometer to the next prototype. It helped that the Gyroscope on the ICM-45686 had excellent noise-rejection and very low-bias, making the magnetometer truly optional.

A detailed description of our evaluation board can be found in the second part of the series about our Mahymah flight controller. Similar to the other sensors, it consists of the magnetometer itself, a voltage regulator, an indicator LED along, I2C address-selection jumper and I2C pins.

All our breakout boards were designed to be breadboard friendly, re-usable and easy-to-work with for multiple platforms, making the testing and evaluation quite easy.

For the flight controller, we wanted 8-12 output channels, each capable of Servo PWM Signals (1ms-2ms), OneShot (125us-250us), DShot150, Dshot300, Dshot600, as well as connectors for GPS, Telemetry and IBUS.

For the first prototype, we decided that 8 channels (with atleast 4 supporting upto DShot600) would be sufficient. Dedicated peripheral connectors would be compact but restricting - having unspecialized UART connectors (2.54mm pitch) would be better for initial testing and debugging.

The first prototype includes 4 UARTs, 1 I2C, 1 CAN connector as well as 8 GPIO pins (all include ADCs to connect analog sensors). This gives us some headroom for testing various payloads.

Apart from the above, there is an SWD connector for flashing the chip and 2 USB-C connectors. The USB-C connectors provide a modern solution for connecting the flight controller to a PC. One of the USB ports is connected to the USB peripheral of the STM32F4 MCU, while the other is connected to a UART port on the MCU via the CP2102 chip. The idea behind the USB-UART port was to provide a simple and reliable way to print messages, without messing with USB timing and state. Connecting this to the PC shows a COM port on Windows (and Serial port on Linux/MacOS), allowing us to use existing Serial Monitoring tools for viewing messages.

Finally, the flight controller board includes a microSD Card slot for high capacity storage of flight logs (blackbox logs). The slot is a push-push type, i.e. push to insert and push to eject, which makes frequent access convenient.

All the ports possess the appropriate noise-rejection circuitry, such as TVS diodes and decoupling capacitors, to ensure that signals are smooth and sudden noise (like static discharges) does not damage any component.

By the time we got to the flight controller prototype, we had already gained experience with 2 and 4-layer stack ups through the evaluation boards. To keep the design relatively compact and manage noise, heat and allow smooth power-delivery, we decided to go with a 4-layer stackup.

To fit all the components on the board, double-sided assembly was chosen over single-sided assembly, even if it was a little pricier.

The outer top and bottom layer consist of the primary routing, while the inner layers consist of ground planes with some power-supply traces. To keep the cost low, no blind/buried vias were used, without compromising on performance or size.

The objective of the software was to simply enable the capabilities that were already present in the hardware, and create a a stable, controllable drone. Consequnetly, the steps for software development would always follow the steps in the hardware development -

1. Appropriately configure and test the MCU board. This step follows the first step of the hardware development.
2. Create sensor drivers for the IMU, Barometer and Magnetometer. The drivers would be incrementally built, to allow for easy testing and also be platform-agnostic, i.e. support different MCUs.
3. Find and integrate an RTOS into the flight control firmware. An RTOS is not needed for basic flight, but becomes necessary once blackbox logging, telemetry and cascaded control system stages come into the picture.
4. Design and implement the control system. We started with a P-PID controller for the angle and rate, but later moved to a full PID-PID with feedforward and throttle-attenuation as we worked towards greater stability and control.
5. Design and implement a blackbox logging system - this becomes important in the case of a crash, as reproducing exact conditions from a flight is nearly impossible.

The first step of the software development was the creation of software-drivers for each individual sensor. As with the hardware development, detailed explanations for each sensor are provided in their respective blogs. The drivers would all follow the same pattern -

• Platform-agnostic: Each sensor instance would accept a generic sensor interface, which would be implemented as a collection of function pointers that are populated with platform-specific implementations at run-time.
• Structure to aggregate sensor state: Each sensor instance would aggregate the state of the a single sensor (such as output-data rate, sleep-mode etc.) and maintain integrity when accessing the sensor (ensuring no invalid state transitions are attempted).
• Self-diagnosis and metrics: Each sensor would keep track of its own metrics (such as read-speed) and be able to diagnose common issues such as a disconnection.

The next step was to find an RTOS to build our flight control firmware around.

An RTOS would not be needed for basic flight, but becomes necessary almost immediately once blackbox logging, telemetry and cascaded control system stages come into the picture.

As we were using the STM32CubeMX framework to do our development, options like MBed OS and Zephyr OS were discarded right at the start. MBed OS had reached EOL anyways and our experience with Zephyr RTOS had not been pleasant till that point. FreeRTOS was the most lightweight, flexible and well-documented option and would easily work with our project structure.

The idea was to delegate each major task to its own thread (such as flight control, GCS communication, Blackbox Logging etc.) The threads would manage their own resources (such as sensors, timers etc.) and post Events to a centralized event queue.

The event queue would have a dedicated dispatch thread that would process the events. Communication would always be between a thread and the event queue. This would make the core responsibilities de-coupled, allowing us to easily add/remove features as we progresed.

After picking the RTOS, we moved on to designing the control system. Initially, we only wanted to fly in angle, rate and horizon modes.

To achieve this we used a 2 cascaded PID stages with a feedforward system. The outer stage handles the angle control, while the inner handles the rates. Initially, we used a P-PID controller, to keep the code as simple and easy-to-tune as possible, but we soon realized that the drone was not performing well in windy conditions. Furthermore, responses were not as crisp as we thought. Adding the I and D terms to the outer stages, as well as feedforward to both the stages solved these problems.

Choosing between the systems was performed through a switch on the transmitter, allowing us to switch between angle and rate modes.

Finally, we implemented a blackbox logging system. We had thought of postponing this to the next prototype, but soon realized that it could greatly assist us in tuning. Apart from this, there were also some bugs arising due to race-conditions during the initial development, which were hard to reproduce. Blackbox logging could fix both of these issues at the same time.

The design of the logger was quite straightforward - we already had a centralized event queue that would receive application data from each of the threads (such as raw, processed sensor values, RC values, etc.) and perform state transitions. The events (along with the state transitions) could be mapped directly to records that would be written to the SD Card.

To maximize speed for our specific use-case, we decided against using a filesystem and directly wrote the records to the SD Card. This added some extra work, as we had to create a separate tool to read and interpret these records from the SD card, but it was worth the effort. Our tool queries the SD Card to find the number of logs, then reads the records from the selected log and finally graphs the data for easy analysis.

Optionally, the data can also be exported to JSON and CSV formats for analsysis through third-party tools. Altogether, this system proved to be very useful for our development process.