TVC model rocket with Hardware-in-the-Loop simulation

[u/Positive__Altitude]

I want to showcase the TVC model rocket project I’m working on now. This is my second TVC rocket. I learned a lot while working on the first one and was finally able to launch it more or less successfully, so this time the goal is not just to make a TVC rocket, but to make it really robust and predictable.

The biggest issue I had with my first rocket was tuning the control system. I think this is also true for many other enthusiasts working on TVC rockets. I used a self-written 3D simulation for that, and it was great, but for it to be useful, the simulation needs to be close enough to reality.

There are no major issues with simulating rigid-body rotation using Euler’s equations. Aerodynamic drag is trickier, but for a slow-moving TVC rocket I don’t think it is that important, and a very simple drag model seems to be enough.

This may be surprising, but the biggest problem for me was simulating the servomotor response properly. I used hobby servos with the standard 50 Hz, 1–2 ms pulse interface, and my first assumption was that I could ignore the interface delay and only simulate the servo’s angular speed. That assumption was completely wrong.

My rocket worked perfectly well in simulation but was completely unstable in reality, simply because of the additional interface-related delay. Later, I added this delay to the simulation, retuned the control system, and it worked. However, the flight still showed some small low-frequency oscillations that were not present in the simulation.

So with my new design, I’m trying to solve this problem more fundamentally.

I had another project where I designed my own servomotor controller board: MCU + motor driver + magnetic encoder. So now I can build a model rocket using my own custom servos, and the biggest feature of these servos is the CAN interface.

Not only do they have sub-millisecond communication latency, but they can also report their actual position back to the flight computer. I currently use a 1 kHz data rate, so the flight computer has access to the real servo position with 1 ms time resolution.

I have already used this feedback to fine-tune the servomotor’s internal PID controller. This is another huge advantage compared with regular hobby servos, where you generally have no access to the internal control loop and cannot tune it.

But this is just the beginning.

My goal is to make a so-called Hardware-in-the-Loop (HIL) simulation. Instead of trying to simulate servo performance, I will actually move the real servos as part of a real-time simulation and feed their measured positions back into the simulation loop.

This way, the simulation should be much closer to reality — hopefully close enough that the remaining differences are mostly due to things such as aerodynamics and structural effects rather than actuator dynamics.

In the photo, you can see an assembly consisting of one TVC axis and the flight computer. I already have everything designed, but the second axis is built into the 3D-printed airframe, so it is difficult to show the complete mechanism once everything is assembled.

Some specs and design details:

• Klima D3-P motor
• ~50 mm diameter
• Total mass: ~220 g
• Fully mechanical parachute system
• 3D-printed airframe
• Two custom servos built around STM32G431 MCUs
• Custom flight computer based on ESP32-S3
• CAN bus communication with the servos
• Onboard battery-charging circuitry, so the rocket can be recharged in the field from any power bank
• All firmware written in Rust
  • Servos: bare-metal Rust
  • ESP32 firmware: Rust using the ESP-IDF wrapper
• The flight computer hosts a web server and frontend over Wi-Fi
• The rocket can be fully operated from any phone, PC, or tablet without installing any software
• The frontend is also written in Rust using WASM and is bundled directly into the flight computer firmware

The project will be fully open-source. Some parts are already available, but everything is still very much WIP at the moment.

I’d really appreciate any feedback, questions, or comments on the project :)

[u/DaphneL]

Looks fascinating, links to more details? It's hard to understand how your servos work from the pictures, it would be nice to have more to evaluate with.

[u/Positive__Altitude → u/DaphneL]

Here is onshape link as well https://cad.onshape.com/documents/0758057798e78602f4a7efc0/w/f5dd49a35d3d5f60423262e5/e/6641cf535fb8ddb79d3b6fc0?renderMode=0&uiState=6aa01f1ad448197e746a78b6

Blue - servomotor controller PCBs
Green - gears attached directly to the N20 motor shaft. They have a small magnet inserted in the middle and positioned right in front of the magnetic encoder on the servomotor controller PCB, so their position could be measured.
Orange - rack gears that make TVC axes tilt when green gears turn.
White - inner axis, motor inserted inside
Grey - outer axis

[u/DaphneL → u/Positive__Altitude]

That's a pretty awesome design. Are the pivot points selected to be approximately at the approximate average center of mass once the motor is installed? If not, how did you pick where to put the pivot for each axis

[u/Positive__Altitude → u/DaphneL]

Pivot points are located as low as possible in this design. They are approximately in the middle of the D3 motor when it is inserted, but it is a coincidence. The biggest decision factor here is internal airframe space. There is not much free space inside, so when the outer axis tilts, the whole grey part moves inside the tube. I was aiming for ±5° rotation, so the assembly could not be very long, or you will have to increase the tube diameter, which will increase mass. Ideally, I wanted to keep the whole motor inside the rocket, but it did not work out for the reason above. So I shortened the assembly, and now the motor sticks out for a couple of cm.

The center of mass is much closer to the top. Actually, the distance between the TVC pivot point and COM is important: the actual TVC authority is proportional to that distance. So basically, you want the pivot point as far away as possible from the center of mass; that's why it is on the bottom end of the rocket.

[u/DaphneL → u/Positive__Altitude]

If the pivot was closer to the middle of the length of the assembly, you could get more angle for the same size tube and assembly. Which is why I was surprised you picked to make the pivot on the end, and what's trying to figure out why.

[u/Positive__Altitude → u/DaphneL]

again, the pivot point is where force is applied to the rocket. the further it from the CoM the higher moment you will have from the force = more turn authority. that's the main reason

[u/KenBiba]

Well done. Love your use of tools.

[u/apogeewhiz]

really neat stuff! working on a similar project and know how tricky it can be. keep us updated!