Gathering Filght Data under Extreme Conditions
Cost-effective flight data collection and real-time telemetry system for real-world rocket testing.
Client
Mil-Tech rocketry startup
Services
Hardware Engineering
Embedded Development
Design Engineering
Industries
Mil-Tech
Rocketry
Date
Jan 2024
Project Overview
As an Embedded & Design Engineer, I've provided technological support for rocket flight tests, including a flight data collection system.
About Product
Self-guided anti-aircraft missile.
Self-guided anti-aircraft missile.
About Client
Unnamed Mil-Tech rocketry startup.
Unnamed Mil-Tech rocketry startup.
Problems & Goals
Problem Statement
The business needed to design for rocket aerodynamics but lacked the technical infrastructure to test and measure the iterations in the field correctly.
Project Goal
Build and test reliable POC-state system to measure flight characteristics of the rocket and post-test unit analysis.
Solution should be cheap in terms of time and cost, as well as easy to reproduce, if needed.
Measurement system should withstand up to 15-20G overload.
Solution
Cost-effective, reliable, and extensively tested on-board computer setup built around widely available FPV drone components. Powered by INAV firmware, it collects comprehensive flight data and is designed for future expansions like controllable surfaces or parachutes.
The system also offers real-time GPS tracking and an on-board camera feed, supporting post-flight analysis and facilitating unit recovery.
My approach
I began with an exploration phase, arranging a series of meetings with the research team to gather detailed information about the test subjects, identify the necessary data, and refine the methodology — ultimately clarifying the solution’s requirements.
After gathering all the necessary information, I began shaping the solution architecture. I identified the following requirements:
On-board data capture: Collect as much flight data as possible, ideally with the potential for future manual control of certain systems during flight;
Live data streaming: Preferably stream real-time data from the rocket to a ground station;
Recovery support: Provide a way to recover the unit after flight, given that the rocket lacks a parachute and may travel up to 7 km horizontally.
Key Challenges & Design Decisions
Cost-Effective On-Board Systems
To meet the business requirement for a quick, budget-friendly proof of concept, I focused on delivering the simplest viable solution without unnecessary complexity.
After researching various options, I chose to use cost-effective, hobby-grade UAV electronics and firmware. These solutions come with a wealth of ready-to-use features, a well-developed ecosystem of compatible components, and a robust community—making them ideal for easy maintenance and future scalability. This approach also proved more efficient than developing custom hardware and software from scratch.
Hardware for Extreme Speeds
To select hardware components that were sufficiently reliable, I consulted with the rocket team to identify potential electronics-related challenges. It turned out that the main issue was high speed and acceleration, which some gyroscopes, accelerometers, and GPS modules could not support.
Before finalizing my purchases, I researched various flight controller options and found that the Flywoo GOKU F722 Pro V2, equipped with an ICM42688 gyroscope, can endure high G-overloads.
Unfortunately, this flight controller is difficult to source in Ukraine and is relatively expensive. Therefore, I began looking for alternative flight controllers featuring the ICM42688 or similarly capable gyroscopes.
Surprisingly, the popular SpeedyBee F405 flight controller—with its BMI270 gyro—boasts similar G-force tolerance and is well-supported by INAV, making it a strong alternative.
We rely on GPS to determine the rocket’s speed. Although a Pitot tube would be ideal for more precise measurements, GPS is more practical for a proof-of-concept and can be upgraded later if needed. Thanks to the UAV-hobby community’s extensive work, we can integrate almost any equipment we require into our existing software and hardware ecosystem.
However, the GPS module also had specific requirements. Since the rocket can reach speeds exceeding 200 m/s, I needed a module rated for higher velocity. I chose the M10-generation Foxeer M10Q-120 with a QMC5883 compass, which supports speeds up to 500 m/s and offers a precision of 0.05 m/s. The M10 chipset also enables faster satellite lock and higher data rates—benefits that prove valuable during testing.
Appropriate Software for Inappropriate Use
To meet the business need for a simple, cost-effective, easily reproducible, and scalable solution — at least for the MVP stage — I chose to use existing, readily available firmware rather than building a custom solution. This prompted a detailed comparison of Betaflight, INAV, and Ardupilot to determine the best fit.
While Ardupilot and Betaflight each have their strengths, I chose INAV for its ideal balance of essential features and straightforward integration.
INAV’s chief advantage lies in its native support for real-time telemetry overlays and comprehensive data logging. This setup allowed continuous monitoring of altitude, battery voltage, and GPS coordinates throughout the flight, while automatically recording sensor data for post-flight analysis. In contrast, Betaflight primarily targets quadcopter racing, and although Ardupilot is highly capable, it typically demands more complex hardware and configurations to achieve similar integration.
I also found it much simpler to configure the rocket with INAV than with Ardupilot. While Ardupilot is undeniably powerful, it typically requires more expensive hardware and a steeper learning curve — unnecessary for our current focus on data measurement rather than autonomous flight control.
Another advantage is INAV’s ability to easily program complex switch-based logic, including global variables and time-triggered events—handy for advanced recovery scenarios. While Betaflight excels at freestyle and racing drones, it lacks certain features needed for rocket flights. Ardupilot offers extensive functionality but can be more complex to set up, requiring additional time and hardware resources.
Overcoming High Temperature Enclosed VTX
Because the video transmitter (VTX) generates significant heat during flight, the rocket faced a risk of dangerously high internal temperatures. Unlike quadcopters—where airflow helps cool the electronics—the rocket’s VTX is housed in a confined space. This raises the likelihood of overheating, potential VTX shutdown, and even deformation of the PLA fuselage or battery damage.
To resolve these thermal challenges, we collaborated closely with an engineer to revise the rocket’s design. Through multiple rounds of 3D printing, assembly, and testing, we evaluated the VTX’s behavior under varying thermal conditions and durations. Simultaneously, we assessed how PLA plastic withstood elevated temperatures, identified necessary reinforcements for the fuselage, and optimized heat dissipation. We also refined the electronics layout to ensure consistent performance in high-heat environments and minimize EMI interference. After these tests, we finalized the design to achieve the desired reliability.
To protect the system during pre-launch procedures, I introduced specialized VTX control logic in iNav. While final checks (such as satellite lock and diagnostics) are performed, the VTX operates at minimal power to avoid overheating. Just before liftoff, it automatically switches to maximum output for strong video transmission. If link quality (LQ) suddenly drops, the VTX reverts to minimal power; however, the operator can regain full control once the connection recovers. This approach maintains stable video, safeguards the fuselage and battery, and provides fail-safes for unforeseen situations.
Assisting for Recovery
To ensure a reliable connection between the radio transmitter and receiver, I upgraded the outdated OpenTX firmware to EdgeTX. Among EdgeTX’s advantages are regular updates, compatibility with modern hardware features, expanded interface customization, and more flexible settings and telemetry options. This translates to more efficient control during all flight stages and greatly simplifies device configuration.
For the receiver, I selected the Matek ELRS 2.4GHz R24-TD True Diversity Receiver, which improves signal reception regardless of the rocket’s orientation. I also updated the ELRS firmware on both devices (transmitter and receiver) and performed binding to ensure synchronized operation.
For stable video transmission via the VTX, I used a diversity receiver featuring a directional Maple 5.8G antenna (11 dBi) and an omnidirectional Pagoda 2 antenna (2 dBi). A short (5 cm) version of the Pagoda 2 antenna is installed on the rocket fuselage to minimize aerodynamic drag while preventing the antenna from bending at high speeds.
To make operation easier for an operator who has no piloting experience, the core functions (VTX control, locator beacon, Blackbox, and the PreArm/Arm/Disarm stages) were automated and designed to provide simple access to all settings. Additionally, active functions and switch positions are displayed on the OSD, reducing interface complexity and enabling quick orientation during flight preparation and execution.
To simplify rocket recovery after landing or signal loss, I integrated a GPS module and a locator beacon with dedicated firmware logic. Current GPS coordinates are displayed on the OSD, greatly facilitating rocket location. The locator beacon automatically activates if the operator loses control or if the battery is disconnected after impact; however, the operator can manually enable or disable this function if the link is restored.
Data Collection & Pre-flight Testing
Because the rocket’s internal layout differs from standard configurations, I addressed orientation challenges by virtually rotating certain components in software. This ensures accurate sensor alignment and proper data logging for INAV’s Blackbox. After researching requirements for reliable logging, I purchased, formatted, and tested a suitable SD card to store flight data.
To safeguard critical information—especially if the rocket cannot be recovered or if the SD card is damaged—I set up multiple backup channels. Based on information I previously obtained from the team, key telemetry metrics are displayed on the OSD, transmitted via the radio link, and recorded at the ground station. This redundancy ensures that the most important data remains accessible for post-flight analysis under any circumstances.
GPS Debugging
While integrating the GPS module, I encountered an issue where it failed to achieve any satellite lock. After inspecting all connections and verifying the configuration, I suspected a bug in the current INAV firmware version on my flight controller. Upgrading to INAV 8 offered a slight improvement, but the GPS signal remained unreliable.
To isolate the problem, I tested the GPS module with the U‑Center application. I discovered it was configured to a higher update rate than INAV supported—likely a remnant from previous use with Ardupilot. Reverting the module to its default settings resolved the compatibility issues.
To confirm proper functionality, I conducted a field test by walking with the unit, recording data via Blackbox, converting that data to GPX format, and reviewing the tracked route on a map. The results were accurate, confirming that the GPS module was once again working as intended.
Summary Outcome
Results
The final system delivered a robust, low-cost flight data platform, providing live telemetry for real-time decisions and detailed logs for post-flight analysis. Early bench tests confirmed its reliability, and full-scale trials will further refine the rocket’s design.
Learnings
Double-check component specifications to avoid hardware/software mismatches;
Implement multiple backups to protect critical flight data (maybe Git for version control);
Prototype early and iteratively to catch and solve hardware-software issues.
Gathering Filght Data under Extreme Conditions
Cost-effective flight data collection and real-time telemetry system for real-world rocket testing.
Client
Mil-Tech rocketry startup
Services
Hardware Engineering
Embedded Development
Design Engineering
Industries
Mil-Tech
Rocketry
Date
Jan 2024
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Project Overview
As an Embedded & Design Engineer, I've provided technological support for rocket flight tests, including a flight data collection system.
About Product
Self-guided anti-aircraft missile.
Self-guided anti-aircraft missile.
About Client
Unnamed Mil-Tech rocketry startup.
Unnamed Mil-Tech rocketry startup.
Problems & Goals
Problem Statement
The business needed to design for rocket aerodynamics but lacked the technical infrastructure to test and measure the iterations in the field correctly.
Project Goal
Build and test reliable POC-state system to measure flight characteristics of the rocket and post-test unit analysis.
Solution should be cheap in terms of time and cost, as well as easy to reproduce, if needed.
Measurement system should withstand up to 15-20G overload.
Solution
Cost-effective, reliable, and extensively tested on-board computer setup built around widely available FPV drone components. Powered by INAV firmware, it collects comprehensive flight data and is designed for future expansions like controllable surfaces or parachutes.
The system also offers real-time GPS tracking and an on-board camera feed, supporting post-flight analysis and facilitating unit recovery.
My approach
I began with an exploration phase, arranging a series of meetings with the research team to gather detailed information about the test subjects, identify the necessary data, and refine the methodology — ultimately clarifying the solution’s requirements.
On-board data capture: Collect as much flight data as possible, ideally with the potential for future manual control of certain systems during flight;
Live data streaming: Preferably stream real-time data from the rocket to a ground station;
Recovery support: Provide a way to recover the unit after flight, given that the rocket lacks a parachute and may travel up to 7 km horizontally.
Key Challenges & Design Decisions
Cost-Effective On-Board Systems
To meet the business requirement for a quick, budget-friendly proof of concept, I focused on delivering the simplest viable solution without unnecessary complexity.
After researching various options, I chose to use cost-effective, hobby-grade UAV electronics and firmware. These solutions come with a wealth of ready-to-use features, a well-developed ecosystem of compatible components, and a robust community—making them ideal for easy maintenance and future scalability. This approach also proved more efficient than developing custom hardware and software from scratch.
Hardware for Extreme Speeds
To select hardware components that were sufficiently reliable, I consulted with the rocket team to identify potential electronics-related challenges. It turned out that the main issue was high speed and acceleration, which some gyroscopes, accelerometers, and GPS modules could not support.
Before finalizing my purchases, I researched various flight controller options and found that the Flywoo GOKU F722 Pro V2, equipped with an ICM42688 gyroscope, can endure high G-overloads.
Unfortunately, this flight controller is difficult to source in Ukraine and is relatively expensive. Therefore, I began looking for alternative flight controllers featuring the ICM42688 or similarly capable gyroscopes.
Surprisingly, the popular SpeedyBee F405 flight controller—with its BMI270 gyro—boasts similar G-force tolerance and is well-supported by INAV, making it a strong alternative.
Appropriate Software for Inappropriate Use
To meet the business need for a simple, cost-effective, easily reproducible, and scalable solution — at least for the MVP stage — I chose to use existing, readily available firmware rather than building a custom solution. This prompted a detailed comparison of Betaflight, INAV, and Ardupilot to determine the best fit.
While Ardupilot and Betaflight each have their strengths, I chose INAV for its ideal balance of essential features and straightforward integration.
We rely on GPS to determine the rocket’s speed. Although a Pitot tube would be ideal for more precise measurements, GPS is more practical for a proof-of-concept and can be upgraded later if needed. Thanks to the UAV-hobby community’s extensive work, we can integrate almost any equipment we require into our existing software and hardware ecosystem.
However, the GPS module also had specific requirements. Since the rocket can reach speeds exceeding 200 m/s, I needed a module rated for higher velocity. I chose the M10-generation Foxeer M10Q-120 with a QMC5883 compass, which supports speeds up to 500 m/s and offers a precision of 0.05 m/s. The M10 chipset also enables faster satellite lock and higher data rates—benefits that prove valuable during testing.
INAV’s chief advantage lies in its native support for real-time telemetry overlays and comprehensive data logging. This setup allowed continuous monitoring of altitude, battery voltage, and GPS coordinates throughout the flight, while automatically recording sensor data for post-flight analysis. In contrast, Betaflight primarily targets quadcopter racing, and although Ardupilot is highly capable, it typically demands more complex hardware and configurations to achieve similar integration.
I also found it much simpler to configure the rocket with INAV than with Ardupilot. While Ardupilot is undeniably powerful, it typically requires more expensive hardware and a steeper learning curve — unnecessary for our current focus on data measurement rather than autonomous flight control.
Another advantage is INAV’s ability to easily program complex switch-based logic, including global variables and time-triggered events—handy for advanced recovery scenarios. While Betaflight excels at freestyle and racing drones, it lacks certain features needed for rocket flights. Ardupilot offers extensive functionality but can be more complex to set up, requiring additional time and hardware resources.
Overcoming High Temperature Enclosed VTX
Because the video transmitter (VTX) generates significant heat during flight, the rocket faced a risk of dangerously high internal temperatures. Unlike quadcopters—where airflow helps cool the electronics—the rocket’s VTX is housed in a confined space. This raises the likelihood of overheating, potential VTX shutdown, and even deformation of the PLA fuselage or battery damage.
Assisting for Recovery
To ensure a reliable connection between the radio transmitter and receiver, I upgraded the outdated OpenTX firmware to EdgeTX. Among EdgeTX’s advantages are regular updates, compatibility with modern hardware features, expanded interface customization, and more flexible settings and telemetry options. This translates to more efficient control during all flight stages and greatly simplifies device configuration.
To resolve these thermal challenges, we collaborated closely with an engineer to revise the rocket’s design. Through multiple rounds of 3D printing, assembly, and testing, we evaluated the VTX’s behavior under varying thermal conditions and durations. Simultaneously, we assessed how PLA plastic withstood elevated temperatures, identified necessary reinforcements for the fuselage, and optimized heat dissipation. We also refined the electronics layout to ensure consistent performance in high-heat environments and minimize EMI interference. After these tests, we finalized the design to achieve the desired reliability.
To protect the system during pre-launch procedures, I introduced specialized VTX control logic in iNav. While final checks (such as satellite lock and diagnostics) are performed, the VTX operates at minimal power to avoid overheating. Just before liftoff, it automatically switches to maximum output for strong video transmission. If link quality (LQ) suddenly drops, the VTX reverts to minimal power; however, the operator can regain full control once the connection recovers. This approach maintains stable video, safeguards the fuselage and battery, and provides fail-safes for unforeseen situations.
For the receiver, I selected the Matek ELRS 2.4GHz R24-TD True Diversity Receiver, which improves signal reception regardless of the rocket’s orientation. I also updated the ELRS firmware on both devices (transmitter and receiver) and performed binding to ensure synchronized operation.
Data Collection & Pre-flight Testing
Because the rocket’s internal layout differs from standard configurations, I addressed orientation challenges by virtually rotating certain components in software. This ensures accurate sensor alignment and proper data logging for INAV’s Blackbox. After researching requirements for reliable logging, I purchased, formatted, and tested a suitable SD card to store flight data.
For stable video transmission via the VTX, I used a diversity receiver featuring a directional Maple 5.8G antenna (11 dBi) and an omnidirectional Pagoda 2 antenna (2 dBi). A short (5 cm) version of the Pagoda 2 antenna is installed on the rocket fuselage to minimize aerodynamic drag while preventing the antenna from bending at high speeds.
To safeguard critical information—especially if the rocket cannot be recovered or if the SD card is damaged—I set up multiple backup channels. Based on information I previously obtained from the team, key telemetry metrics are displayed on the OSD, transmitted via the radio link, and recorded at the ground station. This redundancy ensures that the most important data remains accessible for post-flight analysis under any circumstances.
To make operation easier for an operator who has no piloting experience, the core functions (VTX control, locator beacon, Blackbox, and the PreArm/Arm/Disarm stages) were automated and designed to provide simple access to all settings. Additionally, active functions and switch positions are displayed on the OSD, reducing interface complexity and enabling quick orientation during flight preparation and execution.
GPS Debugging
While integrating the GPS module, I encountered an issue where it failed to achieve any satellite lock. After inspecting all connections and verifying the configuration, I suspected a bug in the current INAV firmware version on my flight controller. Upgrading to INAV 8 offered a slight improvement, but the GPS signal remained unreliable.
To isolate the problem, I tested the GPS module with the U‑Center application. I discovered it was configured to a higher update rate than INAV supported—likely a remnant from previous use with Ardupilot. Reverting the module to its default settings resolved the compatibility issues.
To confirm proper functionality, I conducted a field test by walking with the unit, recording data via Blackbox, converting that data to GPX format, and reviewing the tracked route on a map. The results were accurate, confirming that the GPS module was once again working as intended.
To simplify rocket recovery after landing or signal loss, I integrated a GPS module and a locator beacon with dedicated firmware logic. Current GPS coordinates are displayed on the OSD, greatly facilitating rocket location. The locator beacon automatically activates if the operator loses control or if the battery is disconnected after impact; however, the operator can manually enable or disable this function if the link is restored.
Summary Outcome
Results
The final system delivered a robust, low-cost flight data platform, providing live telemetry for real-time decisions and detailed logs for post-flight analysis. Early bench tests confirmed its reliability, and full-scale trials will further refine the rocket’s design.
Learnings
Double-check component specifications to avoid hardware/software mismatches;
Implement multiple backups to protect critical flight data (maybe Git for version control);
Prototype early and iteratively to catch and solve hardware-software issues.
Gathering Filght Data under Extreme Conditions
Cost-effective flight data collection and real-time telemetry system for real-world rocket testing.
Client
Mil-Tech rocketry startup
Services
Hardware Engineering
Embedded Development
Design Engineering
Industries
Mil-Tech
Rocketry
Date
Jan 2024
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Project Overview
As an Embedded & Design Engineer, I've provided technological support for rocket flight tests, including a flight data collection system.
About Product
Self-guided anti-aircraft missile.
Self-guided anti-aircraft missile.
About Client
Unnamed Mil-Tech rocketry startup.
Unnamed Mil-Tech rocketry startup.
Problems & Goals
Problem Statement
The business needed to design for rocket aerodynamics but lacked the technical infrastructure to test and measure the iterations in the field correctly.
Project Goal
Build and test reliable POC-state system to measure flight characteristics of the rocket and post-test unit analysis.
Solution should be cheap in terms of time and cost, as well as easy to reproduce, if needed.
Measurement system should withstand up to 15-20G overload.
The system also offers real-time GPS tracking and an on-board camera feed, supporting post-flight analysis and facilitating unit recovery.
Solution
Cost-effective, reliable, and extensively tested on-board computer setup built around widely available FPV drone components. Powered by INAV firmware, it collects comprehensive flight data and is designed for future expansions like controllable surfaces or parachutes.
My approach
I began with an exploration phase, arranging a series of meetings with the research team to gather detailed information about the test subjects, identify the necessary data, and refine the methodology — ultimately clarifying the solution’s requirements.
On-board data capture: Collect as much flight data as possible, ideally with the potential for future manual control of certain systems during flight;
Live data streaming: Preferably stream real-time data from the rocket to a ground station;
Recovery support: Provide a way to recover the unit after flight, given that the rocket lacks a parachute and may travel up to 7 km horizontally.
Key Challenges & Design Decisions
Cost-Effective On-Board Systems
To meet the business requirement for a quick, budget-friendly proof of concept, I focused on delivering the simplest viable solution without unnecessary complexity.
After researching various options, I chose to use cost-effective, hobby-grade UAV electronics and firmware. These solutions come with a wealth of ready-to-use features, a well-developed ecosystem of compatible components, and a robust community—making them ideal for easy maintenance and future scalability. This approach also proved more efficient than developing custom hardware and software from scratch.
Hardware for Extreme Speeds
To select hardware components that were sufficiently reliable, I consulted with the rocket team to identify potential electronics-related challenges. It turned out that the main issue was high speed and acceleration, which some gyroscopes, accelerometers, and GPS modules could not support.
Before finalizing my purchases, I researched various flight controller options and found that the Flywoo GOKU F722 Pro V2, equipped with an ICM42688 gyroscope, can endure high G-overloads.
We rely on GPS to determine the rocket’s speed. Although a Pitot tube would be ideal for more precise measurements, GPS is more practical for a proof-of-concept and can be upgraded later if needed. Thanks to the UAV-hobby community’s extensive work, we can integrate almost any equipment we require into our existing software and hardware ecosystem.
However, the GPS module also had specific requirements. Since the rocket can reach speeds exceeding 200 m/s, I needed a module rated for higher velocity. I chose the M10-generation Foxeer M10Q-120 with a QMC5883 compass, which supports speeds up to 500 m/s and offers a precision of 0.05 m/s. The M10 chipset also enables faster satellite lock and higher data rates—benefits that prove valuable during testing.
Unfortunately, this flight controller is difficult to source in Ukraine and is relatively expensive. Therefore, I began looking for alternative flight controllers featuring the ICM42688 or similarly capable gyroscopes.
Surprisingly, the popular SpeedyBee F405 flight controller—with its BMI270 gyro—boasts similar G-force tolerance and is well-supported by INAV, making it a strong alternative.
INAV’s chief advantage lies in its native support for real-time telemetry overlays and comprehensive data logging. This setup allowed continuous monitoring of altitude, battery voltage, and GPS coordinates throughout the flight, while automatically recording sensor data for post-flight analysis. In contrast, Betaflight primarily targets quadcopter racing, and although Ardupilot is highly capable, it typically demands more complex hardware and configurations to achieve similar integration.
I also found it much simpler to configure the rocket with INAV than with Ardupilot. While Ardupilot is undeniably powerful, it typically requires more expensive hardware and a steeper learning curve — unnecessary for our current focus on data measurement rather than autonomous flight control.
Another advantage is INAV’s ability to easily program complex switch-based logic, including global variables and time-triggered events—handy for advanced recovery scenarios. While Betaflight excels at freestyle and racing drones, it lacks certain features needed for rocket flights. Ardupilot offers extensive functionality but can be more complex to set up, requiring additional time and hardware resources.
Appropriate Software for Inappropriate Use
To meet the business need for a simple, cost-effective, easily reproducible, and scalable solution — at least for the MVP stage — I chose to use existing, readily available firmware rather than building a custom solution. This prompted a detailed comparison of Betaflight, INAV, and Ardupilot to determine the best fit.
While Ardupilot and Betaflight each have their strengths, I chose INAV for its ideal balance of essential features and straightforward integration.
Overcoming High Temperature Enclosed VTX
Because the video transmitter (VTX) generates significant heat during flight, the rocket faced a risk of dangerously high internal temperatures. Unlike quadcopters—where airflow helps cool the electronics—the rocket’s VTX is housed in a confined space. This raises the likelihood of overheating, potential VTX shutdown, and even deformation of the PLA fuselage or battery damage.
To resolve these thermal challenges, we collaborated closely with an engineer to revise the rocket’s design. Through multiple rounds of 3D printing, assembly, and testing, we evaluated the VTX’s behavior under varying thermal conditions and durations. Simultaneously, we assessed how PLA plastic withstood elevated temperatures, identified necessary reinforcements for the fuselage, and optimized heat dissipation. We also refined the electronics layout to ensure consistent performance in high-heat environments and minimize EMI interference. After these tests, we finalized the design to achieve the desired reliability.
To protect the system during pre-launch procedures, I introduced specialized VTX control logic in iNav. While final checks (such as satellite lock and diagnostics) are performed, the VTX operates at minimal power to avoid overheating. Just before liftoff, it automatically switches to maximum output for strong video transmission. If link quality (LQ) suddenly drops, the VTX reverts to minimal power; however, the operator can regain full control once the connection recovers. This approach maintains stable video, safeguards the fuselage and battery, and provides fail-safes for unforeseen situations.
For the receiver, I selected the Matek ELRS 2.4GHz R24-TD True Diversity Receiver, which improves signal reception regardless of the rocket’s orientation. I also updated the ELRS firmware on both devices (transmitter and receiver) and performed binding to ensure synchronized operation.
Data Collection & Pre-flight Testing
Because the rocket’s internal layout differs from standard configurations, I addressed orientation challenges by virtually rotating certain components in software. This ensures accurate sensor alignment and proper data logging for INAV’s Blackbox. After researching requirements for reliable logging, I purchased, formatted, and tested a suitable SD card to store flight data.
For stable video transmission via the VTX, I used a diversity receiver featuring a directional Maple 5.8G antenna (11 dBi) and an omnidirectional Pagoda 2 antenna (2 dBi). A short (5 cm) version of the Pagoda 2 antenna is installed on the rocket fuselage to minimize aerodynamic drag while preventing the antenna from bending at high speeds.
To make operation easier for an operator who has no piloting experience, the core functions (VTX control, locator beacon, Blackbox, and the PreArm/Arm/Disarm stages) were automated and designed to provide simple access to all settings. Additionally, active functions and switch positions are displayed on the OSD, reducing interface complexity and enabling quick orientation during flight preparation and execution.
To simplify rocket recovery after landing or signal loss, I integrated a GPS module and a locator beacon with dedicated firmware logic. Current GPS coordinates are displayed on the OSD, greatly facilitating rocket location. The locator beacon automatically activates if the operator loses control or if the battery is disconnected after impact; however, the operator can manually enable or disable this function if the link is restored.
To safeguard critical information—especially if the rocket cannot be recovered or if the SD card is damaged—I set up multiple backup channels. Based on information I previously obtained from the team, key telemetry metrics are displayed on the OSD, transmitted via the radio link, and recorded at the ground station. This redundancy ensures that the most important data remains accessible for post-flight analysis under any circumstances.
GPS Debugging
While integrating the GPS module, I encountered an issue where it failed to achieve any satellite lock. After inspecting all connections and verifying the configuration, I suspected a bug in the current INAV firmware version on my flight controller. Upgrading to INAV 8 offered a slight improvement, but the GPS signal remained unreliable.
To isolate the problem, I tested the GPS module with the U‑Center application. I discovered it was configured to a higher update rate than INAV supported—likely a remnant from previous use with Ardupilot. Reverting the module to its default settings resolved the compatibility issues.
To confirm proper functionality, I conducted a field test by walking with the unit, recording data via Blackbox, converting that data to GPX format, and reviewing the tracked route on a map. The results were accurate, confirming that the GPS module was once again working as intended.
Assisting for Recovery
To ensure a reliable connection between the radio transmitter and receiver, I upgraded the outdated OpenTX firmware to EdgeTX. Among EdgeTX’s advantages are regular updates, compatibility with modern hardware features, expanded interface customization, and more flexible settings and telemetry options. This translates to more efficient control during all flight stages and greatly simplifies device configuration.
Learnings
Double-check component specifications to avoid hardware/software mismatches;
Implement multiple backups to protect critical flight data (maybe Git for version control);
Prototype early and iteratively to catch and solve hardware-software issues.
Summary Outcome
Results
The final system delivered a robust, low-cost flight data platform, providing live telemetry for real-time decisions and detailed logs for post-flight analysis. Early bench tests confirmed its reliability, and full-scale trials will further refine the rocket’s design.