Disclaimer
Important Notice: Please Read Carefully
The information provided on this website, including the documentation of the Reaction Control System (RCS) design and manufacturing process, is for educational and informational purposes only. By accessing this information, you acknowledge and agree to the following terms:
The information provided on this website, including the documentation of the Reaction Control System (RCS) design and manufacturing process, is for educational and informational purposes only. By accessing this information, you acknowledge and agree to the following terms:
- Assumption of Risk: You understand and acknowledge that attempting to design, build, or operate an RCS system involves inherent risks, including but not limited to serious injury, death, and significant property damage. You agree that you are solely responsible for any actions you take based on the information provided on this website. You assume all risks associated with your use of this information.
- No Professional Advice: The content provided on this website is not a substitute for professional advice, safety training, or engineering consultation. The information is based on personal experience and is not guaranteed to be accurate, complete, or free from errors. You should seek appropriate professional guidance before attempting any project that involves high-pressure systems, propulsion, or other hazardous activities.
- Liability Waiver: To the fullest extent permitted by law, you agree to release, indemnify, and hold harmless the author(s) of this website, its affiliates, and any associated entities from any and all liability, claims, damages, or expenses (including legal fees) arising from your use of the information provided herein. This includes any direct, indirect, incidental, consequential, or punitive damages.
- High-Pressure System Warning: The RCS system described on this website utilizes high-pressure gas, which is inherently dangerous. Improper handling of high-pressure systems can result in catastrophic failure, causing injury or death. Without proper safety training and knowledge of high-pressure systems, you should not attempt this project. The author(s) of this website are not responsible for any consequences resulting from the use or misuse of the information provided.
- Cost and Resource Warning: This project involves the use of specialized components and tools, which may be expensive and difficult to obtain. The Bill of Materials (BOM) provided is for reference only and may vary over time. You are responsible for assessing the financial implications and resource requirements before beginning this project.
- No Guarantee of Success: The information provided is for general guidance only and does not guarantee the success of any project. Results may vary, and you are responsible for testing, validation, and ensuring the safety and reliability of any design or system you create.
- Intellectual Property: Any design files, concepts, or methodologies provided on this website are for personal, non-commercial use only. Redistribution or reproduction for commercial use without prior written consent is prohibited.
INTRODUCTION
What is an Reaction Control System?
A Reaction Control System (RCS) is a crucial component of rocket and spacecraft design, enabling precise control of orientation and stability during flight. They works by utilizing small thrusters strategically placed around the vehicle to generate torque and linear force, allowing the vehicle to adjust its pitch, yaw, and roll. RCS thrusters are essential for tasks such as attitude control, docking procedures, and stabilization during orbital operations, making them vital for both manned and unmanned missions.
Why RCS is rare in the Amateur Rocketry Field?
RCS systems are rare in the amateur rocketry field primarily due to the complexity, cost, and expertise required to design, build, and operate them effectively.
Complexity:
For many amateur rocketry enthusiasts, simpler methods of stabilization and control, such as passive fin-based systems, are sufficient to meet their goals, making the additional effort and resources required for an RCS system unnecessary. As a result, RCS systems remain a niche pursuit within the amateur rocketry community, typically explored by those with a deep interest in advancing their technical skills or undertaking ambitious projects.
Cost:
The cost of developing an RCS system can be prohibitive, as it involves not only the thrusters themselves but also the associated components like tanks, regulators, valves, and control electronics. The need for high precision in both design and manufacturing also means that specialized components must be sourced which come at a high cost.
Expertise:
Unlike basic rocket systems, which rely on fins or gyroscopes for stabilization, an RCS involves precise control over multiple small thrusters, often requiring sophisticated electronics, sensors, and control algorithms to function correctly. This level of complexity can be challenging for amateurs, who may lack access to the necessary resources or technical knowledge.
Complexity:
For many amateur rocketry enthusiasts, simpler methods of stabilization and control, such as passive fin-based systems, are sufficient to meet their goals, making the additional effort and resources required for an RCS system unnecessary. As a result, RCS systems remain a niche pursuit within the amateur rocketry community, typically explored by those with a deep interest in advancing their technical skills or undertaking ambitious projects.
Cost:
The cost of developing an RCS system can be prohibitive, as it involves not only the thrusters themselves but also the associated components like tanks, regulators, valves, and control electronics. The need for high precision in both design and manufacturing also means that specialized components must be sourced which come at a high cost.
Expertise:
Unlike basic rocket systems, which rely on fins or gyroscopes for stabilization, an RCS involves precise control over multiple small thrusters, often requiring sophisticated electronics, sensors, and control algorithms to function correctly. This level of complexity can be challenging for amateurs, who may lack access to the necessary resources or technical knowledge.
Why should an Amateur attempt to build an RCS?
While it is true that the suitability of implementing an RCS at the Amateur level is very niche (only possibly relevant to those involved in high power rocketry), the process of designing such a system can provide an opportunity to deepen one's understanding of advanced aerospace engineering concepts, particularly in the areas of control systems, propulsion, and dynamics. For anyone looking to pursue a career in aerospace or related fields, this hands-on experience is invaluable as it bridges the gap between theoretical knowledge and practical application.
Some of you may be apart of a high powered rocketry team or want to be apart of one. You will find that building such an RCS system will provide you with the problem solving skills that will allow you to push the boundaries of what’s possible in amateur rocketry, enabling more complex and ambitious projects. With an RCS, an amateur rocket can achieve greater precision in flight control, allowing for controlled maneuvers, stabilization in varying conditions, and even the potential for orbital or suborbital missions. This level of control can open up new avenues for experimentation and innovation.
Some of you may be apart of a high powered rocketry team or want to be apart of one. You will find that building such an RCS system will provide you with the problem solving skills that will allow you to push the boundaries of what’s possible in amateur rocketry, enabling more complex and ambitious projects. With an RCS, an amateur rocket can achieve greater precision in flight control, allowing for controlled maneuvers, stabilization in varying conditions, and even the potential for orbital or suborbital missions. This level of control can open up new avenues for experimentation and innovation.
Why I created this project
If you do a quick Google search for the design of RCS systems at the amateur rocketry level, you'll find limited resources. The most notable example is BPS.space's attempt to implement an RCS design, which was eventually abandoned due to technical challenges, resource constraints, and a shift in focus toward other projects. Although his design files are available behind a small paywall—understandable given the significant time investment—there's a noticeable gap in accessible, open-source resources for amateur enthusiasts.
Watching BPS.space's videos sparked my interest, particularly because the project was highly multidisciplinary and covered many areas where I had limited technical experience. Given my background and industry experience, I felt I was in a unique position to take on the challenge of designing such a system. My hope is that by documenting my findings, others can contribute to creating more open-source materials for similar designs, allowing us all to learn from our collective experiences.
What follows is my attempt at designing an RCS using primarily Commercial Off The Shelf (COTS) components and limited manufacturing capabilities, relying mostly on a 3D printer.
Watching BPS.space's videos sparked my interest, particularly because the project was highly multidisciplinary and covered many areas where I had limited technical experience. Given my background and industry experience, I felt I was in a unique position to take on the challenge of designing such a system. My hope is that by documenting my findings, others can contribute to creating more open-source materials for similar designs, allowing us all to learn from our collective experiences.
What follows is my attempt at designing an RCS using primarily Commercial Off The Shelf (COTS) components and limited manufacturing capabilities, relying mostly on a 3D printer.
DESIGN METHODOLOGY
Requirements
Normally I'd start off any project by defining a list of requirements that the project must satisfy which would steer the design decisions we make. However, the first attempt of an RCS system can make creating design requirements difficult because:
- Unknown System Mass: The mass of your rocket and RCS components is a critical factor in determining the thrust required for effective control. Without knowing the exact weight of the entire system, it’s difficult to establish how much thrust each RCS thruster needs to produce. This uncertainty makes it challenging to specify key design requirements, such as the size and power of the thrusters.
- Unpredictable Performance: Performance characteristics, such as how quickly the RCS can adjust the rocket's orientation, are influenced by factors like the rocket's moment of inertia and the effectiveness of the thrusters. Since this is your first attempt, you might not have accurate data on these parameters, making it difficult to predict how the system will perform under different conditions. This uncertainty hampers your ability to set specific performance goals or thresholds.
- Lack of Empirical Data: In engineering, design requirements are often informed by empirical data from previous projects or prototypes. As this is your first attempt, you don’t have prior data to reference. This absence of empirical benchmarks makes it harder to define requirements with confidence, as you’re essentially working from theoretical calculations and assumptions rather than proven performance metrics.
- Iterative Design Process: The design of an RCS often involves an iterative process where the system is tested, evaluated, and refined. On a first attempt, you’re likely to encounter unforeseen challenges or limitations that could require significant design changes. This uncertainty makes it difficult to lock down initial requirements, as they may need to be adjusted as you learn more about the system's actual performance.
- Interdependencies Between Components: The effectiveness of an RCS is dependent on how well its components work together, including thrusters, control algorithms, and sensors. Without knowing the final weight or how each component will interact, it’s challenging to establish clear requirements for each part of the system. The performance of one component may impact the design requirements for others, creating a complex web of interdependencies that are difficult to anticipate on a first attempt.
An Alternative Design Methodology
Given the numerous unknowns regarding system performance and the absence of a defined rocket to size our RCS around, we'll follow an alternative design methodology centered on iterative prototyping and empirical data collection.
Primary Goal: Our initial objective is not to achieve a fully optimized RCS from the start but to develop an initial prototype. This prototype will serve as a testbed for gathering essential empirical data on the system's performance, such as thrust output, response time, and overall stability.
Iterative Process: With this empirical data in hand, we will iteratively refine and optimize the design. Each iteration will aim to improve specific aspects of the system, such as thrust efficiency, control precision, and weight management, with the ultimate goal of achieving maximum system performance.
Flexibility in Design: This methodology allows for flexibility in the design process, enabling us to adapt to new findings and challenges as they arise. By focusing on developing a functional prototype first, we can address performance gaps more effectively, ensuring that the final system is both reliable and efficient.
This approach of learning through hands-on experimentation and continuous improvement, rather than attempting to predict and design for all variables upfront. This allows us to create a more robust and high-performing RCS as we move from prototype to final product.
Primary Goal: Our initial objective is not to achieve a fully optimized RCS from the start but to develop an initial prototype. This prototype will serve as a testbed for gathering essential empirical data on the system's performance, such as thrust output, response time, and overall stability.
Iterative Process: With this empirical data in hand, we will iteratively refine and optimize the design. Each iteration will aim to improve specific aspects of the system, such as thrust efficiency, control precision, and weight management, with the ultimate goal of achieving maximum system performance.
Flexibility in Design: This methodology allows for flexibility in the design process, enabling us to adapt to new findings and challenges as they arise. By focusing on developing a functional prototype first, we can address performance gaps more effectively, ensuring that the final system is both reliable and efficient.
This approach of learning through hands-on experimentation and continuous improvement, rather than attempting to predict and design for all variables upfront. This allows us to create a more robust and high-performing RCS as we move from prototype to final product.
Sub-System Breakdown
I will be splitting the projects into multiple sub-systems that will be focused in the specific order:
- Fluid System
- Feed System
- Valve Body
- Thruster Ports
- Test Equipment
- Thrust Test Stand
- Gimbal Test Stand
- Avionics
- Control Board
- IMU Board
- RF Comms. Board
- Battery System
- Ground Link Board
fluid system
Valve Body
The goal of this section is to design a unified valve body that, once equipped with plungers and actuation systems, will allow for the individual control of a single pressure source into six separate chambers. These chambers will then feed into corresponding nozzles, which serve to accelerate the gas and impart a higher torque on the vehicle.
Studying Legacy Designs
Given that this was my first attempt at designing a valve body, I decided to study the design of existing valves for guidance. All valves feature some form of control mechanism that regulates whether the input fluid can flow through to the output side of the valve body. The most common control mechanisms include:
Since remote control of these valves is required, a mechanical lever system is unsuitable. While a pressurized source could work, remotely controlling it would present a redundant challenge. This leaves us with two viable options: solenoid or motor-driven solutions.
Both solutions are technically feasible, but motor-driven systems pose a specific challenge: the restrictive portion of the valve must be coupled to the motor while maintaining a good seal between the two sides of the valve. This can add complexity and weight, particularly if we were to use six independent COTS manual valves and integrate them into a separate connection system to feed into six thrust chambers.
To address these challenges, I opted to design a single valve body that could be 3D Printed and relies on COTS solenoid plungers as the sealing and control mechanism. This approach offers a more compact and integrated solution, reducing weight and complexity.
I began by purchasing and reverse engineering a standard small form factor aluminum 1/4" NPT solenoid valve available on Amazon. The following diagram illustrates the various parts of the valve and how it functions:
Studying Legacy Designs
Given that this was my first attempt at designing a valve body, I decided to study the design of existing valves for guidance. All valves feature some form of control mechanism that regulates whether the input fluid can flow through to the output side of the valve body. The most common control mechanisms include:
- Mechanical: Typically involves a lever or pressurized source to actuate the valve.
- Electrical: Often uses solenoids or motor-driven systems to control the flow.
Since remote control of these valves is required, a mechanical lever system is unsuitable. While a pressurized source could work, remotely controlling it would present a redundant challenge. This leaves us with two viable options: solenoid or motor-driven solutions.
Both solutions are technically feasible, but motor-driven systems pose a specific challenge: the restrictive portion of the valve must be coupled to the motor while maintaining a good seal between the two sides of the valve. This can add complexity and weight, particularly if we were to use six independent COTS manual valves and integrate them into a separate connection system to feed into six thrust chambers.
To address these challenges, I opted to design a single valve body that could be 3D Printed and relies on COTS solenoid plungers as the sealing and control mechanism. This approach offers a more compact and integrated solution, reducing weight and complexity.
I began by purchasing and reverse engineering a standard small form factor aluminum 1/4" NPT solenoid valve available on Amazon. The following diagram illustrates the various parts of the valve and how it functions:
Fig 1.1: This is what the valve normally looks like, it has 1/4" NPT threads on both the input and output ports.
|
Fig 1.2: Cross sectional View of the whole valve, with labels on all the major parts of the valve.
|
Fig 1.3: Close up shot on valve in the open state. Energizing the solenoid pulls up on the plunger allowing gas to flow from input side to the output.
|
I Initially, I attempted to design my own solenoid and plunger system from scratch, but I quickly realized how challenging this task was—not only from a theoretical standpoint but also due to a lack of access to specialized materials and manufacturing equipment. This lack of access made the fabrication of an effective solenoid winding core and plunger nearly impossible. The creation of efficient electromagnets heavily depends on selecting materials with high magnetic permeability, which is a critical factor in their effectiveness. Consequently, I recognized that both the solenoid core (and preferably the winding) and the plungers would need to be sourced as COTS components.
Fortunately, the small form factor aluminum solenoid valve I acquired from Amazon is designed to be easily disassembled and reassembled without damage. This feature allows me to repurpose the plunger system and solenoid core for my own design, significantly simplifying the process of creating the valve body.
Addressing the Cv Limitation:
It's worth noting that BPS.space, in his attempt to create an RCS system, also used similar valves and encountered an issue with their low Cv (Flow Coefficient). The Cv of a valve is a measure of its capacity to allow fluid to flow through it. Specifically, it represents the number of gallons of water at 60°F (15.6°C) that can flow through the valve in one minute with a pressure drop of 1 psi across the valve body.
Key Points about Cv:
Fortunately, the small form factor aluminum solenoid valve I acquired from Amazon is designed to be easily disassembled and reassembled without damage. This feature allows me to repurpose the plunger system and solenoid core for my own design, significantly simplifying the process of creating the valve body.
Addressing the Cv Limitation:
It's worth noting that BPS.space, in his attempt to create an RCS system, also used similar valves and encountered an issue with their low Cv (Flow Coefficient). The Cv of a valve is a measure of its capacity to allow fluid to flow through it. Specifically, it represents the number of gallons of water at 60°F (15.6°C) that can flow through the valve in one minute with a pressure drop of 1 psi across the valve body.
Key Points about Cv:
- Flow Capaciy: A higher Cv value indicates a valve with a larger flow capacity, meaning it can pass more fluid with less resistance. Conversely, a lower Cv value indicates a smaller flow capacity.
- Pressure Drop: Cv is used to predict the flow rate through a valve based on the pressure differential across it, helping in designing and selecting the appropriate valve for a specific application.
- Application: Cv is commonly used in fluid control systems, ensuring that the valve can handle the required flow rates without causing excessive pressure loss or turbulence.
Building our First Valve Body
Given that this RCS will be interfacing with a tubular rocket, it makes sense to design the RCS in the shape of a hockey puck. In BPS.space's design, the RCS was integrated directly into the nose cone of the rocket. This approach likely served multiple purposes, such as eliminating the need to separately print and attach a nozzle or possibly providing space for storing avionics in the future. However, in our case, I intend to reserve the nose cone section for potential scientific payloads or antenna real estate, so I’ll be avoiding the inclusion of an integrated nose cone in our design.
I began by duplicating each of the valve body features found in our reference valve, arranging them in a circular pattern centered on our hockey puck design. The height of the puck was initially set to 17.25mm, which is a placeholder value determined by the anticipated size of our nozzle openings. Since I wasn't sure of the optimal nozzle size at this stage, I chose this height as a starting point.
My plan involved adding threads to the 17.25mm openings, allowing me to easily swap in and out different nozzle profiles during future thrust testing. This approach would enable us to experiment with various nozzle geometries without needing to reprint the entire valve body each time.
Here’s the first iteration of the design:
Given that this RCS will be interfacing with a tubular rocket, it makes sense to design the RCS in the shape of a hockey puck. In BPS.space's design, the RCS was integrated directly into the nose cone of the rocket. This approach likely served multiple purposes, such as eliminating the need to separately print and attach a nozzle or possibly providing space for storing avionics in the future. However, in our case, I intend to reserve the nose cone section for potential scientific payloads or antenna real estate, so I’ll be avoiding the inclusion of an integrated nose cone in our design.
I began by duplicating each of the valve body features found in our reference valve, arranging them in a circular pattern centered on our hockey puck design. The height of the puck was initially set to 17.25mm, which is a placeholder value determined by the anticipated size of our nozzle openings. Since I wasn't sure of the optimal nozzle size at this stage, I chose this height as a starting point.
My plan involved adding threads to the 17.25mm openings, allowing me to easily swap in and out different nozzle profiles during future thrust testing. This approach would enable us to experiment with various nozzle geometries without needing to reprint the entire valve body each time.
Here’s the first iteration of the design:
|
|
This was a good starting valve body which I attempted to 3D Print but ran into some issues with my part not sticking properly to my printer bed and had warping issues. I decided to go even smaller to not waste any filament in this testing process. I took apart the plunger mechanism from a COTS solenoid valve and printed a quarter section, did some pressure tests to verify isolation, then printed the whole body and assembled it:
|
|
|
A quad chamber system is a good starting point, allowing control over pitch and yaw. However, since the upcoming testing was going to be very through, it made sense to make the extra effort to made a hexa chamber system, allow additional control along the roll axis:
|
|
It is worth mentioning that due to the increased number of thruster ports (the roll axis thrusters actually need 2 thrust chambers that are diagonally opposed) we now have a total of 8 thrust chambers of which the diagonally opposing roll axis thrust chambers must tie back into the a single input chamber. Also due to space constraints I found it tricky to get the roll +/- ports to be exactly opposing one another. While the each +/- pair are diagonally mirrored, this is not the case between the pairs (this may cause some thrust imbalances, but likely to fall within the correction band of the software algorithm). This results a need for some complex internal channels within the valve body:
|
|
Feed System
Now that we have a valve body that can isolate flow between each of the 4 chambers (+/- Pitch/Yaw) we now need to design the feed system. This system will contain all of the components that will feed the source gas into our valve body.
Here is a P&ID (Piping and Instrumentation Diagram) of the feed system:
Here is a P&ID (Piping and Instrumentation Diagram) of the feed system:
Breakdown of Components
|
Tank (TK-A001)
Because of some initial worry of pre-mature loss of pressure as seen in BPS Space's Design using a 3000 psi 13ci HkArmy Tank I opted to go a bit over kill and use a 3000psi 48ci HkArmy Paintball CO2 Tank. It's worth mentioning that along with its overkill volume, it is quite heavy (~1.14kg) since it has a stainless steel construction. For the flight tank we will select a carbon fiber overwrap tank. 
|
Pressure Gage (PG-A002)
The purpose of this gage is to provide a physical means of visually inspecting the bottle pressure of TK-A001. When the bottle is fully pressurized this should provide a dial reading of ~3000psig 
|
|
Pressure Transducers (PT-XXXX)
These sensors will measure the pressure within various points in the line and convert the measurement to a voltage signal that we can feed into a data acquisition system. 
|
Burst Disks (BD-XXXX)
These are safety mechanisms that we will install at various segments in the line to ensure that an over-pressurization of the line will not rupture the tubing/valve body and result in a catastrophic failure. This is especially important to ensure we do not accidentally blow up our tank, lines, or valve body. At these pressures the system may act as a bomb under failure, so to prevent this, these disks will prematurely rupture at a certain pressure and relief the pressure in the system before it reaches catastrophic levels. 
|
|
HPA Regulator (REG-A005)
This device is critical for stepping down our bottle pressure from a high as 3000psig to a pressure that wont cause our 3D printed valve body to rupture. In our case, our regulator is an off the shelf component that will step the pressure down to 150psig. This may have CV limitations, but we will look into methods for improving its performance if it is an issue. 
|
Manual Ball Valve (MV-A008)
This is a critical safety component because the fitting used directly on the HPA regulator is holding the output pin of the HPA constantly open. This will cause a constant release of gas from the regulator. To provide an additional isolation point when physically handling the system after a pressurization test. 
|
|
Solenoids from Valve Body (SV-XXXX)
These is the solenoid valve system made in our valve body section. 
|
Load Cells (LC-XXXX)
This is a sensor purely used for testing purposes that will aid in us measuring the thrust produced by each of the thruster ports. 
|
Fully put together, this is what a cross sectional view of the feed system should look like:
Required Fittings
|
|
Regulator Reverse Engineering
Nozzle Design
In the preliminary portions of testing my system I knew that the area that would require the most iteration would be the nozzle portion of the thrusters, and because my nozzle section is directly linked with the valve body, it would be a nuisance to keep printing. Instead, I opted for creating a set of mounting holes at the outlet of each thruster port which would allow me to swap out nozzle sections during testing. These would also serve as the mounting point for connecting to load cells for measuring thrust.
|
|
|
Initial Calculations:
Throughout this project I made sure to use a precision scale to measure the weight of all the components, down to the washers and bolts I was using. This was a critical process since it allowed me to have as close to possible an accurate approximation of the Moment of Inertia Values as well as the Center of Mass (CoM) location.
Throughout this project I made sure to use a precision scale to measure the weight of all the components, down to the washers and bolts I was using. This was a critical process since it allowed me to have as close to possible an accurate approximation of the Moment of Inertia Values as well as the Center of Mass (CoM) location.
- Approximating Required Reaction Force:
- τ = F ⋅ d⊥
- F is the Magnitude of the Force Imparted on the object
- d⊥ is the shortest perpendicular distance measured from the center of mass to the line of action of the thrust force
- τ = I ⋅ α
- I is the Moment of Inertia about the CoM
- α is the Angular Acceleration of the object
- F ⋅ d⊥ = I ⋅ α
- F = (I ⋅ α) / d⊥
- τ = F ⋅ d⊥
d⊥x = d⊥y = 0.146796 m
|
d⊥z = .0421 m
|
Ixx, Iyy, Izz are the principal moments of inertia about the primary axes (x,y,z) through the center of mass. These will be used in our calculations. Keep in mind my y & z axes are swapped.
|
Knowns:
- d⊥x = d⊥y = 0.146796 [meters]
- d⊥z = 0.0421 [meters]
- Ixx = 1.827 x 10^-1 [kg⋅m^2]
- Iyy = 1.829 x 10^-1 [kg⋅m^2]
- Izz = 1.027 x 10^-2 [kg⋅m^2]
- α = 1.0 [rad/s^2] (This is fast enough for most amateur rocket applications without overshooting or inducing instability)
- Fx = (1.827 x 10^-1 [kg⋅m^2])(1 [rad/s^2]) / (0.146796 [m]) ~ 1.244 N
- Fy = (1.829 x 10^-1 [kg⋅m^2])(1 [rad/s^2]) / (0.146796 [m]) ~ 1.246 N
- Fz = (1.027 x 10^-2 [kg⋅m^2])(1 [rad/s^2]) / (0.0421 [m]) ~ 0.244 N
- Fx must produce 1.244 N or 0.127 kgf
- Fy must produce 1.246 N or 0.127 kgf
- Fz must produce 0.244 N or 0.025 kgf
- Approximating Initial Nozzle Geometries:
- Ve = sqrt((2⋅γ/γ-1)⋅R⋅Tc(1-(Pe/Pc)^((γ-1)/γ)))
- Ve is the velocity with which the gas it traveling at when exiting the nozzle [m/s]
- γ is the specific heat ratio of the specific gas
- R is the Gas Constant of the specific gas [J/kg⋅K]
- Tc is the temperature of the chamber [K]
- Pe is the pressure at the exit of the nozzle [Pa]
- Pc is the pressure at the chamber prior to the nozzle [Pa]
- γ ~ 1.4 (For Air)
- R = 287 [J/kg⋅K] (For Air)
- Tc = 294 [K] (Avg Ambient Temperature where I am @70F)
- Pe = 0 [psig] + 14.7 [psi] = 14.7 [psia] = 1.013x10^5 [Pa]
- Pc = 150 [psig] + 14.7 [psi] = 164.7 [psia] = 1.136×10^6 [Pa]
- Ve = sqrt((2⋅(1.4)/(1.4)-1)⋅(287)⋅(294)(1-((1.013x10^5)/(1.136×10^6))^(((1.4)-1)/(1.4)))) ~ 542.891 [m/s]
- ṁ = F / Ve
- ṁx = (1.244 [N]) / (542.891 [m/s]) = 0.00229 [kg/s]
- ṁy = (1.246 [N]) / (542.891 [m/s]) = 0.00230 [kg/s]
- ṁz = (0.244 [N]) / (542.891 [m/s]) = 0.00045 [kg/s]
- ṁtotal = (0.00229 [kg/s]) + (0.00230 [kg/s]) + (0.00045 [kg/s]) = 0.00504 [kg/s]
- At = (ṁ/(Pc⋅sqrt(γ/(R⋅Tc))⋅((γ+1)/2)^-((γ+1)/(2⋅(γ-1))))
- At is the cross sectional area of the throat opening of the nozzle
- At = (ṁ/2672.39)
- Atx = ((0.00229)/2672.39) = 0.857 [mm^2]
- Aty = ((0.00230)/2672.39) = 0.861 [mm^2]
- Atz = ((0.00045)/2672.39) = 0.168 [mm^2]
- Dt = 2*sqrt(At/π)
- Dtx = sqrt((0.857)⋅4/π) = 1.045 [mm]
- Dty = sqrt((0.861)⋅4/π) = 1.047 [mm]
- Dtz = sqrt((0.168)⋅4/π) = 0.462 [mm]
Nozzle Geometries
Now that we know what our throat diameter is all that is left is to figure out what to make our inlet and exit nozzle lengths and and angles. This is where we will come up with a set of geometries and perform empirical testing to see which works best for our use case. There are a few guidelines that help us come up with a starting set of nozzle geometries:
Now that we know what our throat diameter is all that is left is to figure out what to make our inlet and exit nozzle lengths and and angles. This is where we will come up with a set of geometries and perform empirical testing to see which works best for our use case. There are a few guidelines that help us come up with a starting set of nozzle geometries:
- Inlet
- In order to smoothly transition to the throat diameter without causing flow separation or turbulence we need to provide a long enough and gradual transition, but we also want to keep it short enough to save on weight and material.
- A length to throat diameter of 3:1 - 5:1 is typical, shallow angles will reduce separation between θinlet ~ 10-25 degrees is recommended (with angles closer to 10 degrees being more efficient, but adds length)
- Exit
- To goal with the exit is to convert the remaining pressure energy into kinetic energy as efficiently as possible. To do this we need to keep the ratio between the area of the exit and the area of the throat(Ae:At) >4.
- We also want to keep this angle shallow to minimize turbulence and flow separation. Angles between θexit ~ 10-15 degrees are optimal.
Throat Diameter (mm) |
Inlet Length (mm) |
Inlet Angle (°) |
Exit Diameter (mm) |
Exit Length (mm) |
Exit Angle (°) |
Expansion Ratio (Ae/At) |
0.58935 |
3 |
15 |
2.0 |
6 |
12 |
4 |
0.58935 |
5 |
10 |
3.0 |
10 |
15 |
10 |
0.58935 |
4 |
12 |
2.5 |
8 |
14 |
6.25 |
0.58935 |
6 |
10 |
3.5 |
12 |
10 |
14 |
0.58935 |
3 |
18 |
2.0 |
5 |
15 |
4 |
0.58935 |
5 |
15 |
2.5 |
9 |
12 |
6.25 |
|
|
TEST EQUIPTMENT
Valve Testing Rig
Prior to doing full scale Hex Solenoid valve body testing, I decided to modify the valve body down to a single valve and thruster so we can dial in our nozzle geometries before commiting them in the final valve body. The test rig consists of a load cell which is being compressed by a vertically guided bed which holds the valve body and nozzle assembly.
|
|
|
Before we can gather data from this test setup, there is some calibration that will be required from each of the sensors. For the load cells, I have purchased a set of calibration weights that will allow me to apply a load through the range of the sensor (0-5kg):
|
|
This provides me with the slope and offset needed to convert the raw ADC counts from the HX711s and convert them to kg units of applied load:
Next I moved onto calibrating the pressure transducers. I did this by hooking up my pressure transducers to quick disconnect fittings and connecting them to the outlet ports of a shop air compressor. Since my working pressure is the full range of the air compressor's output pressure range I simply sweep across the range using the pressure gage as my reference:
|
|
Now that all my sensors are calibrated and I've done click checks (simply listening for solenoid valve plunger movement when attempting to command a valve open) I can move onto full testing. In my setup, I am simply using my control boards for reading and streaming telemetry to my ground station, the rest of the RCS assembly is not actually doing anything. While this setup looks rather harmless, some simple TNT equivalency calculations involving the fluid's pressure (150psig) and the volume of the line (~20in^3) has a blast radius that will cause lung damage at ~3ft and a ear drum rupturing radius of ~5ft. For these setups, I am inside my house since these parts have never been proofed up to x1.5 Maximum Expected Operating Pressure which would normally allow this setup to active while I am around it. Also the anisotropic material properties of my FDM printed PLA valve body make these issues even more precarious.
Calculating Blast Radius
As harmless as 120psi of compressed air may seem, if uncontrolled, can create catastrophic damage. Which is why we need to take proper precautions to calculate the clear out/working distances with these 3D Printed parts when they are pressurized. To do this we will be referencing the Fire Protection Handbook (FPH) to calculate blast wave propagation and the potential consequences. The following equations can be used to calculate hazardous locations and proper standoff distances:
Testing Area
The following is an example of my test setup. I utilized cinder blocks to create a closed off area to prevent potential shrapnel from traveling further down my backyard. Ideally I would have moved the test setup even further from the house, but our blast zones were still outside of the house's perimeter.
|
|
AVIONICS - software
Software Control Algorithm
The avionics sub-system is the brains of a reaction control system by continuously monitoring an IMU's rotational vectors to calculate the error between this value and the desired attitude setpoint. Using the calculated error we will use a bang-bang style of control algorithm in order to activate certain thruster port solenoid valves which should impart a moment on the whole system, thus changing the attitude of the vehicle.
Here is the basic control algorithm that we will be implementing:
Here is the basic control algorithm that we will be implementing:
Here is a breakdown of the Bang Bang Controller's logic. There is some quaternion math required in order to calculate the attitude error:
Here is the software implementation of the control logic using Arduino code and the IMU data of a BNO085 sensor module:
Avionics - hardware
System Overview
Given everything we have designed thus far, we now need to design an embedded system that will function as the brains of this control system. Here is a high level overview of how our Avionics system should interface with with rest of the control system:
Physical Implementation: Version 1
Normally given the limited real estate between the tubing and shroud, I'd need to design some fixed linkages between either the valve body or tubing. However, I decided to utilize the space between the solenoid valves and tubing. Using the solenoid holding nuts as a fixed mounting point to hold a PCB. I could then build up from this fixed PCB in a wedding cake style to make further room for components while using the mounting standoffs between the boards to carry power. Temporarily for prototyping purposes I've stood off the microcontroller board as a shield connected to the wedding cake boards using a 90 degree connector and will be fixed in place with some 3D printed parts. Here is what the initial design looks like:
Physical Implementation: Version 2
After attempting to build the wedding cake stackup, there were so many issues with physical integration. Trying to secure the boards with the nuts of the solenoid coils was a bad idea and I ran into many clearance issues. Which led to a whole redesign involving a dedicated avionics bay which would provide some mounting real estate without using the solenoid valves. The use of interlocking sections allowed me to make seamless connections between each body section. I've also switched to using compression PCBs for the battery pack, a bit novel approach, but one that I was wanting to try for a while. The most unideal part of this setup is the microcontroller. Normally I'd convert the section of the microcontroller circuit into its own standalone board, but I did not want to risk big setbacks with troubleshooting a new board, especially with one I've never made a standalone board for. So temporarily you will see this awkwardly mounted microcontroller:
|
|
Interface Board Design
This board's main purpose is to interface with the 6 Solenoid Valves, 2 Pressure Transducers, 1 Limit Switch, 1 IMU, and Battery Pack. To drive the 6 solenoid valves, we'd need to design a driver circuit. Each solenoid requires 12V with a current consumption of 540mA. There are 6 of these circuits:
- U1 / C1 / C2 : Will provide a regulated 12V source with a 1A output capacity.
- Q1: Is an N-Channel MOSFET configured in a Low Side Switching configuration (Can switch 30V loads @ up to 5A
- R1: Defines how fast the Gate of Q1 will charge up (Lower = Faster, but limited by the DIO current capability of our microcontroller)
- R2: Will pull down the Gate voltage of Q1 when the gate is LOW, making sure the Gate Voltage does not float, and keeps the switch open
- D1: Is a flyback diode designed to dissipate the reverse voltage event caused by the solenoid when turned off (Handles up to -60V @ 6A)
- R3 / LED1: Will provide visual feedback that the Solenoid is receiving power
- X1: This is a 2 pin receptacle that will provide an interface for the wiring going to the solenoid
In order to acquire the voltage signal from our Pressure transducers I utilized the ADS1115 (I know the schematic shows 1015, but I used the 1115 instead) for access to a 16-bit version. This would convert the voltage signals into a 16-bit binary data that could be read over I2C:
The limit switch circuit was pretty simple, directly to a DIO with a pull up resistor. IMU was simply a connector that would interface 4 wires to an Adafruit BNO085 Development Board. And lastly a 12 pin connector for interfacing back to a microcontroller.
|
|
|
|
|
Battery Pack Design
Here is our power consumption chart which was used to size our battery:
Device Name |
Quantity |
Voltage Required |
Power Consumption |
Total Consumption |
Solenoid Valve |
6 |
12V |
6,500mW |
39,000mW |
Pressure Transducer |
2 |
12V |
120mW |
240mW |
Microcontroller/XBEE |
1 |
12V |
3,570mW |
3,570mW |
Total: |
42,810mW (42.81W) |
I had some leftover SANYO 18650 cells from an old project which I figured would make for an effective power source. These cells have a 2000mAh capacity with a nominal voltage of 3.7V. In order to achieve at least 12V even when the battery is drained to 2.7V we would need at least 5 cells in series which would put the lowest pack voltage at 13.5V. With 5 cells (This assumes that the solenoids are constantly powered on):
- Capacity: 2000mAh = 2Ah
- Charged Voltage: 5 x 4.2V = 21V
- Total Energy Capacity: 2Ah x 21V = 42 Wh
- Total Runtime (hours) = Total Energy Capacity / Load Power = (42 Wh) / (42.81 W) ~ 58.9 min
In my design I sandwich the 18650 cells between 2 PCBs and utilized large holes in the PCB to give access to areas where I could spot weld through the PCB. Here is what that looked like:
|
|
The use of a balance connector that taps into each of the cell voltages and the use of an XT60 connector allows this pack to be used like any other, and is able to be charged with a standard lithium ion charger. However, it is missing a BMS which does make the use of this pack a lot less safe, but we will add this as a feature in the next revision.
Wireless Link: XBEE
My main method of communication between the test article (The RCS Main Control Board) and the Ground Station is a Wifi Transceiver (XBEE) pair. I can even uses more than 2 transceivers to create a mesh network which all nodes can see all other node's data. This will be helpful when adding a node to control a compressor. In order to configure each XBEE to talk to each other I use Sparkfun's XBee-Explorer Shield along with Digi's XCTU Software. Once hook up to your computer with XCTU installed, I use the following settings:
|
|
|
Breakdown of the Settings
There are a lot of settings that can be configured, which can be confusing. I'll be focusing mainly on the ones that matter most, but I'll also provide the full list for a baseline.
There are a lot of settings that can be configured, which can be confusing. I'll be focusing mainly on the ones that matter most, but I'll also provide the full list for a baseline.
- Network & Security Settings:
- CH (Channel)
- This defines the frequency the XBEE will use for communication. (This must match between nodes) (There are 21 channels 0x0B-0x1A)
- ID (PAN ID)
- Personal Area Network Identifier. This defines the Network ID of your XBEE Network (This must match between Nodes)
- DH (Destination Address High) / DL (Destination Address Low)
- DH represents the higher 32-bits (DL is the remaining bits) of the 64-bit address of the module to which the XBEE will send data to.
- Broadcast Mode (Send Messages to all nodes): Set DH = 0x00000000 and DL = 0x0000FFFF
- Point-to-Point Communication (1 Master, +1 Slaves): Set DH and DL to match the SH and SL of the master module.
- Multi-Network Communication (+1 Masters, +1 Slaves): You can mix and match DH/DLs to create more complex mesh networks.
- MY (16-bit Source Address)
- This is similar to DH/DL but since it is 16-bit unique address, it can reduce the overhead of using 64-bit addresses in every packet.
- SH (Serial Number High) / SL (Serial Number Low)
- This is not configurable. It is a globally unique identifier for the XBEE module, and no other module will have this exact SH/SL.
- It is used to set the DH/DL of other nodes / reference id for packets from this node.
- MM (MAC Mode)
- This configures the behavior of the Media Mac Control (MAC) Layer, handling network communication and packet framing.
- 802.15.4 is an IEEE standard for a MAC Layer for simple point-to-point or point-to-multipoint communication
- Best for Networks where nodes send data directly to a single master
- + ACK means that the sender node waits for an acknowledgement packet frame from the receiver after transmitting a packet.
- This is good for reliable communication where your data integrity is critical
- Downside: Waiting for acknowledgements adds latency (slower communication) + power consumption
- + MaxStream Header is a proprietary addition to the normal 802.15.4 packet structure
- It provides extra information for debugging/routing
- Downside: It adds additional data to each packet (reducing your throughput capability), not compatible with non-Digi devices
- CE (Coordinator Enable)
- Determines whether the node will function as a Coordinator in a network, crucial for managing the network topology
- CE = 1, node will act as the coordinator, responsible for starting and managing the network by assigning to other devices and stucture.
- CE = 0, node will act as the Router or End Device, joins an existing network and communicates based on the roles assigned in the ntwk
- CH (Channel)
- Example Broadcast Network Setup:
- Coordinator (Master Node):
- Channel = C
- PAN ID = 0x0667
- DH = 0x00000000
- DL = 0x0000FFFF
- CE = 1
- Other Nodes (Slave Nodes):
- Channel = C
- PAN ID = 0x0667
- DH = 0x00000000
- DL = 0x0000FFFF
- CE = 0
- Coordinator (Master Node):
SIMULATION / DATA VISUALIZATION SOFTWARE
Picking a Software for Data Visualization
In traditional testing environments that require a console-style interface, my go-to tool has always been Processing, specifically leveraging the ControlP5 libraries for efficient UI design and data handling. However, the unique demands of this project required me to rethink my approach. The primary challenge was the need to visualize quaternion data produced by the IMU in an intuitive and interactive 3D environment. For this, I opted to explore Unity 3D as my visualization and simulation platform.
Unity 3D is widely recognized in the gaming and visual effects industries as a robust game engine. However, its capabilities extend far beyond creating immersive gaming experiences. Unity's pre-built physics engine, coupled with its comprehensive support for 3D rendering and interactive visualization, makes it an ideal choice for simulating and analyzing complex systems. Just as game developers use Unity to simulate realistic environments and mechanics, I found its tools equally beneficial for this RCS project.
By utilizing Unity, I could accurately simulate and visualize the orientation of the system in real time, making the abstract quaternion data more accessible and actionable. Unity’s flexibility also allowed me to create custom interfaces, integrate external data streams, and design visually compelling representations of system behavior, all within a single platform. This not only enhanced the development process but also provided a richer, more engaging way to validate and troubleshoot the RCS design.
Unity 3D is widely recognized in the gaming and visual effects industries as a robust game engine. However, its capabilities extend far beyond creating immersive gaming experiences. Unity's pre-built physics engine, coupled with its comprehensive support for 3D rendering and interactive visualization, makes it an ideal choice for simulating and analyzing complex systems. Just as game developers use Unity to simulate realistic environments and mechanics, I found its tools equally beneficial for this RCS project.
By utilizing Unity, I could accurately simulate and visualize the orientation of the system in real time, making the abstract quaternion data more accessible and actionable. Unity’s flexibility also allowed me to create custom interfaces, integrate external data streams, and design visually compelling representations of system behavior, all within a single platform. This not only enhanced the development process but also provided a richer, more engaging way to validate and troubleshoot the RCS design.
High Level Connection Diagram
Here is a diagram showing the data flow from the downlink microcontroller into our Visualization / Control Software Stack:
Here is an example of how incoming packet data looks like on the serial monitor:
Unity 3D C# Scripting: Serial Quaternion Receiver
This C# Code will constantly tap into the Serial Monitor and look for data in a JSON format ({"qx": 0.0, "qy": 0.0, "qz": 0.0, "qw": 1.0}) and transform our target 3DObject (a 3D Model of our RCS System) to emulate the rotations experience in real life.
Control Panel using Processing
This processing code not only allows me to visualize the incoming data packets, but also allows me to start logs that capture the data packets and stores them into csv files that I can analyze later.