Guidance
Purpose: The LV2.3 rocket design is intended to be a testbed for development of our avionics, recovery, and control systems. We have successfully planned, designed, built, and tested systems in each of these areas. This project represents our next progression from simple control systems such as roll control (link) to a considerably more complex six-degree-of-freedom control system. This step in our development process will likely result in some failures because it is more complex (by orders of magnitude) than anything we have done so far. From our failures and successes, we aim to actively guide our rocket.
There will be a final step in this process, which will be guiding our rocket in an unstable configuration (no fins) using only thrust vectoring. With that, we will push toward orbit.
Requirements:
- Rocket must be statically stable (pass RSO eval).
- On error, fins lock neutral through apogee, then servos OFF.
- Fins have short mechanical travel to minimize control gain.
- Fins have margin between mechanical travel and software travel limits to avoid travel stop nonlinearities.
- Hardware watchdog timer centers the servo if FC COMM is lost.
- MORE...
Requirements:
- Control rocket(s) through an optimal orbital insertion trajectory.
- Design aspects should be reusable, in that, the software/modeling can be defined such that it can control rockets with different sizes, dynamics and motor characteristics.
- Computer
- modern 1+ghz CPU with an FPU
- running a real time variant of Linux
- COTS hardware (PC104 or other similar class of industrial/milspec hardware)
- Computer should allow for hardware-in-the-loop testing (e.g. faking out the analog inputs to the sensors to simulate flight)
- Fin design chosen with known aerodynamic properties from sub-sonic thru super sonic
- Mechanical design in solidworks, such that it’s actually machinable using available tools.
- Low-latency interconnect method between host computer and sensors/actuators
- CAN bus to actuators, which are “distant” from control computer While this version the control computer will likely be directly above the actuators, in future iterations, using RCS or in other designs, the actuators could be far more distant.
- CAN bus to GFE node which in turn has sensor(s) on them.
- CAN to PC Bridge - LPC generic node for now, to be replaced by some other PC-104 type card
- Nothing should preclude the modification of controls such that it can handle staging and completely different control actuator methods. (e.g. moving from fin-based mechanism to RCS mechanism after stage separation)
- IMU will provide data to flight computer.
- IMU is TBD as part of a separate project.
- Assume good data is coming from some IMU
- Ability to interface with one (or more) GPS units - possibly to include GPS attitude module
- Do calculations for control bandwidth based on Ixx for required force to achieve 100Hz, 20Hz, 10Hz, 5Hz, 1Hz swinging rocket +/- 15 degrees.
- from that determine servo speed
- Note: minimum fin size will be defined by passively stable rocket design
- linkage design will limit min/max fin movement such that the fins won’t tear off
- Provision for realtime RF data downlink to ground including raw sensor readings, control outputs, current tracked rocket state (position, velocity, roll rate).
- What about flight plans? Who decides when to separate stages? Guidance? separate controller flight computer? Don’t design this such that it turns into a problem.
- What’s our “tube diameter” through which we must fly in order to get into a good enough orbit? Nathan?
- Modeled and simulated in matlab
- Matlab models decomposed into tractable sub-modules that can be simulated on their own and worked on by individuals
- With accounting for performance aspects of servos (or other actuators)
- Ability to input trajectory and have control simulate following trajectory
- Ability to simulate jet-stream winds aloft
- Do we need to simulate temperature, air pressure, humidity?
- Ability to define “assertions”, which if violated during any simulation will raise an obvious indicator that an assertion failed for the given system.
- Creation of mathematical scripts, which for the given configuration, can calculate the required control authority, control bandwidth and other critical control parameters.
- Scripts that can take calculated critical control parameters in conjunction with rocket model values (mass, mass moment of inertia etc) and calculate useful values such as fin sizes.
- Scripts such that control bandwidth can be defined, and control forces, actuator speeds, sensor feedback latencies, resolutions etc can be back-calculated.
- Ability to simulate upper and lower bounds of various real-world scenerios (e.g. too much/too little control authority, too much/too little control bandwidth, failed hardware etc)
- Utilization of quaternions for tracking state of rocket so as to avoid numerical singularities
- Mechanical properties of the physical fin should be such that the actuator cannot induce a resonance in the fin. e.g. Stiff enough that it’s natural frequency is far above the maximum frequency of the actuator.
- Size of the fins must be large enough that the rocket is naturally stable when the fins are in the vertical. Necessary to satisfy Tripoli requirements.
- this likely means that the fin sizes will be very large compared to the necessary control authority, and thus we will need small and precise angular movement on the main fins. This may be on the order of 1 to 3 degrees of control of the main fins
- Actuator mechanism should be it’s own mini-module that sits above the motor, possibly to be directly a part of the motor bulkhead, or mounted directly to the motor bulkhead. Mechanical rigidity will be key.
- Self-test mechanism or startup procedure should be automatic. Key for pre-launch testing and power up in the field.
- In-field setup should be minimal, simply power on and check for expected behavior, such as self-test fins moving, beep sequences or LED status codes.
- Launch detect should be done via simple pin-header jumper or breakwire
- For flight, a pre-defined flight plan should be defined, which should include a variety of classes of control maneuvers, such as translation maneuvers, roll, pitch, yaw.
Current Design
Coming...
Next items needed:
- Fin equations relating fin length, airspeed, air-density, and angle-of-attack to lift and drag
- Mass moment of inertia calculations
- Measured mass moment of inertia in principle axes
- Determination of performance requirements
- Estimate of control forces based on performance requirements
- System diagrams describing datums, PC's and MC's positions and forces
- Equations of motion describing the plant
- State-Space representation of plant
- Pole placement and control design
Analysis
Mass Moment of Inertia
Our project requires the full inertia tensor. We will measure this experimentally, then check against the model.
Needed:
- Model audit
- List all parts in model
- Check material properties in each part (steel aluminum, etc)
- Check mass of parts against actual parts
CFT notes
![\left [ \begin{matrix}
\overset{\centerdot}{\phi} \\
\overset{\centerdot}{\theta} \\
\overset{\centerdot}{\psi}
\end{matrix} \right ] =
\left [ \begin{matrix}
1 & tan \theta sin \phi & tan \theta cos \phi \\
0 & cos \phi & -sin \phi \\
0 & sec \theta sin \phi & sec \theta cos \phi
\end{matrix} \right ]
\left [ \begin{matrix}
\omega_{x} \\
\omega_{y} \\
\omega_{z}
\end{matrix} \right ]](./a35824486e46df003893b745aff766c6.png)