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
TEST EQUIPTMENT
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:
RCS_IMU_Ctrl_Alg.ino
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
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:
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:
Unity 3D C# Scripting: Serial Quaternion Receiver
The following 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.
SerialQuaternionReceiver.cs