A New Spin On Vertical Orientation Control

[Finicky]

Design and construction update. Over the last year I've taken a NoseCam above Mach on three different occasions. In all cases the brushless gimbal motor that rotates the nose shell would stall at or just above Mach, and then recover once the rocket slowed enough. I had already doubled the torque of the motor by increasing the motor voltage rail to 32V, but that didn't solve the problem, although it did move the stalling to higher velocities.

I've never been thrilled with relying on the internal bearings of the gimbal motor to act as the load bearing axis of rotation for the entire upper nose. These motors were never intended for this type and magnitude of loading. I'm happy that the gimbal motor bearings work as well as they do as long as you stay below Mach. I don't think that overloading the motor bearing was the primary cause of the motor stalling (more on that later), but I felt it was time to give the motor bearing a little help carrying the aerodynamic and inertial loads.

I modified one of the stationary lower shell pieces so I could install six miniature ball bearings with 2mm stainless dowel pin axels. The outer perimeter of the rotating nose shell support now presses against these bearings, taking some of the thrust and bending loads off of the gimbal motor bearings.









As to the primary reason for motor stalling, I have a pet theory. All versions of NoseCams (up until now) have had a thin sleeve of plastic at the bottom of the rotating nose that overlapped the stationary motor housing. This was done primarily for looks, since it hid a bunch of hardware gaps. I'm guessing that at high velocities a venturi effect of airflow over the nose would pull a vacuum on the inside of the nose. The air pressure differential across the thin cylindrical sleeve of plastic would cause it to get pushed inward and drag on the stationary components, almost like a drum brake. It's my belief that this was the primary cause for the motor stalling. The modified nose design no longer has this thin sleeve of plastic. It doesn't look quite so nice anymore, but I hope all these fixes solve the motor stalling problem.

 

[jderimig]

Design and construction update. Over the last year I've taken a NoseCam above Mach on three different occasions. In all cases the brushless gimbal motor that rotates the nose shell would stall at or just above Mach, and then recover once the rocket slowed enough. I had already doubled the torque of the motor by increasing the motor voltage rail to 32V, but that didn't solve the problem, although it did move the stalling to higher velocities.

I've never been thrilled with relying on the internal bearings of the gimbal motor to act as the load bearing axis of rotation for the entire upper nose. These motors were never intended for this type and magnitude of loading. I'm happy that the gimbal motor bearings work as well as they do as long as you stay below Mach. I don't think that overloading the motor bearing was the primary cause of the motor stalling (more on that later), but I felt it was time to give the motor bearing a little help carrying the aerodynamic and inertial loads.

I modified one of the stationary lower shell pieces so I could install six miniature ball bearings with 2mm stainless dowel pin axels. The outer perimeter of the rotating nose shell support now presses against these bearings, taking some of the thrust and bending loads off of the gimbal motor bearings.

View attachment 579177

View attachment 579178

View attachment 579179

View attachment 579180

As to the primary reason for motor stalling, I have a pet theory. All versions of NoseCams (up until now) have had a thin sleeve of plastic at the bottom of the rotating nose that overlapped the stationary motor housing. This was done primarily for looks, since it hid a bunch of hardware gaps. I'm guessing that at high velocities a venturi effect of airflow over the nose would pull a vacuum on the inside of the nose. The air pressure differential across the thin cylindrical sleeve of plastic would cause it to get pushed inward and drag on the stationary components, almost like a drum brake. It's my belief that this was the primary cause for the motor stalling. The modified nose design no longer has this thin sleeve of plastic. It doesn't look quite so nice anymore, but I hope all these fixes solve the motor stalling problem.

Brilliant!

 

[Finicky]

Brilliant!

Thanks John

 

[Finicky]

It's been many months since I posted anything about VOC systems. After all the fun I had at Argonia last year, I wanted to revisit the entire design to make it more amenable to +50K flights. Smaller, lighter, stronger, simpler ....... (Ok, maybe not simpler LOL)

The original Falcon design with the extending / retracting winglets is difficult to build. The nose is fully 3D printed because the internal geometries required to house and support the mechanisms are complex. I suppose a Jedi Master with a 5 axis CNC could make the nose parts out of a "real" material, but that's not me What I wanted was a design that could use a purchased FWFG nose that only required some simple modifications. In that way, I could have a "real" nose shell on the outside and all the complicated bits could be hidden safely on the inside.

Hence the new design(s). I'm calling this approach HammerHead for several reasons. It sounds cool, I have a penchant for giving things goofy names, it gives off a hammerhead shark vibe (to me anyway), and I needed to call it something new to differentiate from the old Falcon designs.

The first system I will describe fits on a 3" rocket frame.



The biggest difference compared to the original Falcon approach is that the two canards are no longer retractable. The air drag on the control surfaces is always there, even when you don't "need" the canards because you are already flying vertical.

However, this approach has several critical advantages:

-- HammerHead is a Symmetric System -- The original Falcon design didn't really like pushing the rocket to exactly vertical. Usually when that happens, the rocket actually goes "through" vertical slightly which results in a lot of control motion, specifically 1) retract winglets, 2) spin the nose and 3) re-extend the winglets. It works, but it’s not pretty or efficient. In truth, the Falcon control software actually targets one degree off of vertical (instead of perfectly vertical) to help minimize this effect. The new HammerHead design avoids all of that commotion.

-- HammerHead can accomplish roll rate (or roll position) control -- I've been reading with great interest how high altitude flights can suffer from coning. One way to reduce the risk of coning is to keep the roll rate of the rocket to some low value. The two canards on HammerHead can be used to control both tilt and roll rate (or roll position, but that's a bit trickier and probably not necessary).

-- The nose shell can now be a purchased FWFG nose with slight modifications to accommodate the system.

For what I'm describing in this post the nose is still 3D printed. This is just for prototyping convenience, and based on previous experience should be good to Mach 1.5 or so without issues. The plan is to get the system working and debugged, and then switch over to a more robust FWFG nose shell.

 

[Finicky]

Since this was going to be a substantial upgrade to previous designs, I had a fresh list of "must haves" to add. These included:

-- A dedicated Bluetooth data link between the nose and the alt bay flight computer -- This allows two different and very useful functions.

1) On a two stage flight, the alt bay computer can relay timing information to the nose about when staging is happening (or going to happen). This is handy if the canard position needs to be reset since the dynamics of the rocket will change substantially at the moment of staging.

2) Camera Power Control -- For all previous NoseCams, the biggest power hog (by far) was the video camera. The system battery needed to be sized to handle the worst case of how long it might be between powering ON the camera/VOC and the LCO hitting the launch button. At large launches, this could be 30 minutes or more. On these systems there is one battery powering everything, so if the battery dies, the VOC system shuts down as well. Also, camera overheating is always a concern. My alt bay flight computers all have long range, bidirectional telemetry links. So now I can send a command to the alt bay just moments before launch, and that command is relayed to the nose via Bluetooth to power the video camera. The needed battery for the overall VOC system is now substantially smaller. And the risk of overheating is gone, since the camera is activated moments before launch and does not have a chance to overheat. Nice.

-- A Better Camera -- All of the previous NoseCams used a RunCam Split 3 Lite as the video camera. That video format was 1080p 60fps, but in the current world of 4K video that camera was getting a bit dated. The new camera is a Hawkeye Firefly 4K Split with Gyroflow. (I program the camera for 2.5K 50fps, since this is highest resolution that can use Gyroflow) A critical feature of the new camera (just like the old one) is that it can be programmed to start recording video the moment power is applied. Also, Hawkeye sells a custom 16ND filter for the Firefly camera lens, which really helps with glare reduction when flying on a sunny day.

-- More Aerodynamic Camera Position -- This was a compromise I begrudgingly made. Older systems had the camera pointed down, which made for great video by showing the motor burn and the fins "magically" spinning while the video remained stationary. But this required that there be a camera bump on the side of the nose. For the HammerHead design I moved the camera entirely inside the nose shell for better aerodynamics. The downside is that the camera is pointed sideways, so the bottom of the rocket is no longer visible.

-- Quickly Adjustable Canard Size -- If the canards in the photos below look small to you, that's because they are. If I want to test a larger canard surface area, I 3D print a canard shell that slides over the small canard.

Here are a few pictures and videos of the upper part of the nose during construction. Note that the lower part of the nose (what I have called the "Power Head" in earlier posts) is substantially the same as all previous builds. Some of the pictures show the angle calibration jig I 3D printed to ensure I was getting symmetrical motion on the canards. Since the canards are not "direct drive" from the servos there is a bit of skew between the commanded servo position and where the canards move to. This is compensated for in software.

 

[Finicky]

First video showing the motions of the primary rotary motor and the canard servos.

 

[Finicky]

Second video showing the motions of the primary rotary motor and the canard servos, this time with the upper nose installed.

 

[Finicky]

The first HammerHead VOC test flight was last weekend at MDRA. It was a short flight to 4K feet. Conditions were slightly breezy, and the short flight meant there would not be a lot of velocity to help the canards "grab". Nevertheless, I was fairly pleased with the results.



I'm a data junkie. The graphs below are a bit busy, but they provide important insight into what happened during the flight.

The first graph shows both rocket tilt and canard motion as a function of time. Tilt is the orange trace with units on the right vertical axis. Note the tilt can be either positive or negative. It's the absolute value that really matters. When tilt changes sign in the graph that indicates that the rocket passed "through vertical". Given how slow and short the flight was, I think the system did a good job keeping the rocket vertical.



The next two graphs show that the roll rate control was working as well. For this flight, the roll rate control software was very simplistic. Whenever the roll rate exceeded 360 degrees/sec, the canards were given a "bump" to oppose the roll.

The brushless motor that spins the entire nose is what provides the counter-torque to control the rocket roll rate. I data log motor electrical current, which is proportional to motor torque. Motor current (and hence motor torque) increased during the initial seconds of flight while the roll rate was being brought under control. Once the roll rate was reduced to a small value, the brushless motor current dropped to what was needed to match the slow spin of the rocket body.





The flight video is probably the smoothest I've ever made. Quite a bit of that is the Gyroflow software post-processing. Note that the rocket body is still (slowly) spinning even though the video camera (and hence the video itself) in the nose shell is not.

 

[neil_w]

This is an amazing project and I'm glad to see updates.

I can't help being a bit disappointed, though, at the new camera position. Watching the airframe rotate (seemingly) randomly while the image stayed locked was one of the great things about the previous system.

[edit: don't want to come off sounding negative, I love this whole thing and hope it ends up in a commercial product one day]

 

[Finicky]

This is an amazing project and I'm glad to see updates.

I can't help being a bit disappointed, though, at the new camera position. Watching the airframe rotate (seemingly) randomly while the image stayed locked was one of the great things about the previous system.

[edit: don't want to come off sounding negative, I love this whole thing and hope it ends up in a commercial product one day]

Fear not !!! Can you say TWO CAMERAS ?!? (No VOC though. This is a different project.)

 

[JimJarvis50]

Nice job! (and you can't do this stuff unless you're a data junkie!)

Jim

 

[2-0turbo]

Just stumbled on this thread. Great work! Very interesting to see the development. I would love to dabble in this space eventually. But it’s several years off.

How did you handle the flight data/ overlay on the camera feed for your earlier videos? That was really slick.

I will have to go check out the other build thread.

 

[Finicky]

Just stumbled on this thread. Great work! Very interesting to see the development. I would love to dabble in this space eventually. But it’s several years off.

How did you handle the flight data/ overlay on the camera feed for your earlier videos? That was really slick.

I will have to go check out the other build thread.

Dashware. Ancient and very difficult to use. But free. There are certainly more modern approaches available.

 

[Finicky]

Next up .............. the smallest VOC system I have ever built and flown. Think of this as the "light beer" version of the 3" HammerHead system. It fits in a 2.6" body tube. For this first round I kept things simple. No camera. No roll control. Only tilt control. One servo drives both canards.

One of the photos shows the 2.6" system next to the 3" system. As the nose gets smaller, it gets exponentially more difficult to fit everything in. It's like building a ship in a bottle

 

[Finicky]

The first flight of the 2.6" system also occurred at MDRA. Low and slow, looking to find the more obvious system issues. I think the tilt performance is OK. The canard motion railed against the limit early on, but that's because the velocity was so low. The next test flight will be higher / faster, and I expect hitting the limit to be less of an issue. I can't wait to use this on a 2.6" two stage. Smaller rockets mean smaller / cheaper motors !

 

[Finicky]

I have one additional VOC design to share. This one is the most unusual. It also fits into a 2.6" body tube. I'm calling it RamJet. No servos. No canards. Just a spinning nose tip that routes airflow in the needed direction to steer the rocket back to vertical. I think the images below give the basic idea of what is going on. Adding this design on top of the NoseCam foundation was a piece of cake compared to my other VOC system designs.



I'll be the first to point out that this idea for steering a rocket using a directed air jet is not new. I have seen references to a Model Rocketry Magazine two-part article by Forrest Mims in the February and March 1970 issues on a design he called "Ram Air" which is almost identical to what I constructed. So give credit where credit is due.

 

[Finicky]

The first test flight also occurred at MDRA. Very conservative low and slow to about 2500 feet.

 

[Finicky]

So did it work ? Maybe. I configured the control software to aim the air jet when tilt exceeded 3 degrees. From the graph below I can say that it MIGHT have worked. More test flights required. Stay tuned ..........................

 

[Finicky]

I've been busy with building and flying VOC systems the last few months and have a few new things to share. First up is a "canard direct drive" HammerHead VOC design. It takes really small servos to fit inside the taper of a 3" nose in this orientation and still leave some support for the canard shafts. It's not quite as rigid as I had hoped, but I'd say it should be OK for sub-Mach flights.

 

[Finicky]

Next up is my first HammerHead VOC with canard gear drive. This design is MUCH more robust w.r.t the canard axis of rotation. I'm planning to test it to about Mach 1.5. After that I need to switch to a FWFG nose shell, at least for the upper nose section.

What's really interesting about the gear drive approach is that I think I can get it to fit into noses as small as 54mm base diameter.

 

[Finicky]

Here's the two new designs side by side. Both fit on 3" airframes.

 

[Finicky]

Finally, I've been working on the latest VOC circuit board design with lots of upgrades and improvements, and also the ability (hopefully) to fit into noses that attach to 54mm diameter airframes. The design is fairly flexible, and includes:

Feather M4 microcontroller
6DOF accel/gyro with 16g/1000dps limits
6DOF accel/gyro with 30g/2000dps limits
3DOF accel with 200g limits
35V/3A BLDC motor drive amplifier
Quadrature rotary encoder input
Up to 3 hardware UARTS for things like GPS, LoRa and Bluetooth
Up to 4 PWM outputs for servos
A few leftover digital lines for things like remote power switching of cameras via long range wireless (great for saving battery life)

Whenever possible I take a "stacked" approach when stuffing a circuit board in order to fit as much as possible into a 3D space. Hence the microcontroller sits on top of the 6DOF modules. It's still at least 20x bigger than a truly integrated design (like the Blue Raven for example), since my circuit skills are "sub-optimal" LOL.