I could use just a little guidance

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Not trying to snark. Really I was blown away at a different method government contractors use. Last week one of the UTC rocket members claimed his govt contractor boss cleared him to put one of the new team's models into Missile Datcom 2011 with the AFRL/NPS updates. Being a mechanical he's only formally trained on the pitching moments and drag coefficients which this program does at high angles of attack. It's finding point forces in places we didn't have the CFD toolsets or research prof Linux hardcode capabilities to do so in the past. It took us three weeks to find a drag force and drag coefficient at some angles of attack after modeling the complete airframe in 3D solidworks then meshing with Inputs last summer. The new Missile DatCom under the limited license does all that and it does it while it's rapidly turning which the CFD goes bizerk on and it takes thirty seconds after user plugs rocket dimensions into a open rocket style Gui. They didn't want the newer nosecones shattering etc.

We aren't using the Matlab controls system pluggins but the defense company that I won't name is using it to develop missile control systems from the basically highly modified and upgraded fortran code with those speciality NPS/AFRL military plugins. We know our university rocket team won't have access to it for long just until end of semester. We just had some point forces done with it in places we couldn't do previously. You can get Missile DatCom 97' I found out from AIAA methodologies for design spacecraft transportation systems if you need the pitching moments or drag coefficients at angles of attack in methods much less tedious than hi resolution meshes and CFD environments to Mach 20+. I don't know how useful that method would be to you. I sorta hit my hand against the wall a bunch of times knowing Missile Datcom just well made struggles like Jim's so much less tedious and they don't open source anything close to it for hobby uses sadly. It really grinds me man. The CFD beats missile DatCom on accuracy. The DatCom beats CFD on controls integration,time to use, and on versitility of turning models. Still in a f--- they can do that state of mind. Controls lecture is going well. I still have respect for hobbyists that do this, because the reality is limited license programs do these systems for defense companies much much quicker. The yaw damper and public aircraft DatCom is the closest you'll see outside of a defense contractor from a Matlab perspective.

The hobbyists that get these active stability systems are doing it the hard way and are true rock stars of rocketry. Lots of tinkering the old school way like before DatCom existed. If they just had a controls variant that would help with active stability or rolling and not do guidance for public or civil space uses... It's a damn shame.
 
Last edited:
Interesting info. Thanks. It would really blow our minds if we got to see the leading-edge stuff that the military are working with. A lot of these faster systems rely on generalisations to get quicker results. I suspect the military has some more cleverness hidden away, and teaming that up with the high-speed computing they would have access to would give very quick turnaround on the result.

There is nearly always a compromise between how long a solution takes to find and the resolution of the data that a project needs. Sometimes it is better to go with lower fidelity simulations to get the projects completed on time. Simulation times generally grow exponentially with the number of points analysed, hence the ongoing efforts to be more clever about meshing and simulation approximations of small-scale features. High-speed computers are just improving the resolution that we need to compromise to for an answer in an acceptable timeframe :)
 
The data from missile DatCom wasn't as graphical as the high fidelity CFD meshes. Just a printout of data nothing cute. No pretty oblique shocks or supersonic exhaust plumes. But the CFD had drag coefficients for computing forces from -4 to +4 degrees angle of attack. Then it wouldn't go any further for us. Meanwhile this old fortran stuff is like 98% accurate for "most" cases, very seldom some PhD dork will whine it isn't accurate for extreme case ,and it spat out 1,2, 5, 10,15,20,25 degrees angle of attack and all the pitching moments and the drag coefficients which exceeded the CFD limits using fine mesh techniques which felt like more trouble than worth but only options prior to using this software. It's taking us CFD to get a drag coefficient when Mach exceeds the wind tunnel capability and they had math tactics into fortran purely numerically solve it without a 3D mesh or a bunch of DE or PhD level inviscid assumption on boundary layer blah theory crap. Cuz the CFD wants to run it all as a moving fluid in the surface as particles and boundary layer flow interaction stuff. The real slick stuff we don't have a clue on is the missile lab or MSDLN/NPS Matlab plugins but all the recent 2011 missile DatCom user manuals are public release describing more capabilities. And the Army missile DatCom user manuals also public release had a bunch of equations in back. Sometimes helpful when you want an oddball nose shape or biconvex fin blunted etc. We just had enough hard times finding forces in certain places.

I'm hoping the AIAA version the real old stuff is what is the ticket to find near CFD accuracy on drag coefficients without all the pain in the arse the CFD was. It just shouldn't take entire airframe models to do this. No wonder. So I don't think they have so much super PC as just they use math smarter and reduce resource requires then CFD the harder crap when required. And aparrently Tulhoma is still doing hypersonic tunnels so they must've hit a wall with CFD accuracy somewhere, likely testing real scrams or whatnot or aero hearing possibly with extreme angles of attack???. But those tunnels are super expensive to run. Idk. With work it'll help do controls, but that's outta our league here.
 
Not a contradiction. You have an unstable system (phase shift of 180 degrees at a frequency with gain > 1) and a gain that is constant with frequency. So the gain has to be less than 1 in order to be stable.

Your choice: high gains and unstable or low gains and large errors.


It can be fixed but not by fiddling with the gain. The current version of Scilab (6.0.0) is throwing lots of Java errors and is useless at this point. I may have to dig into that chapter on doing root locus by hand. Ugh.

So, my slightly better than back of the envelope calculations are showing angular acceleration rates above your 7000°/s/s estimate. Looks like this was the problem versus a mechanical problem, and the gain needs to decrease significantly. However, a gain of 1 seems very sluggish. Can you elaborate a little on your first sentence above? I see the words but I don't understand them. Doesn't servo response time factor in to this at some point?

Jim
 
So, my slightly better than back of the envelope calculations are showing angular acceleration rates above your 7000°/s/s estimate.

Nice to have confirmation that I didn't futz up the calculation somewhere.

Looks like this was the problem versus a mechanical problem, and the gain needs to decrease significantly. However, a gain of 1 seems very sluggish. Can you elaborate a little on your first sentence above? I see the words but I don't understand them. Doesn't servo response time factor in to this at some point?

Of course servo response time is a factor. A good model of the particular servo in question would help a lot. But it adds delay. Which pushes that crossover frequency even lower than it already is. If you had recorded data at a high enough frequency so that aliasing wasn't a concern, you could have estimated the crossover frequency from the frequency of oscillation.

Digital servos are much better than analog servos. I was surprised recently when I found that analog servos only apply power to their motors in response to the pulse from the receiver/controller. No pulse, no motion. Digital servos on the other hand are constantly applying power to their motors.


A common tool for analyzing things is the Bode plot. This has plots of magnitude and phase. For the current setup the magnitude is essentially constant. It rolls off over 42Hz because of the gyro filter but since that is greater than the sample rate, it doesn't matter.

Phase is more interesting. The integration (angular acceleration to angular rate) has a constant phase of -90 degrees. A Zero Order Hold (what the servos are doing in addition to their internal response) has a natural phase shift as well. Zero degrees at DC but rising to -90 degrees at fs/2. The gyro LPF adds some phase shift as well.

It is clear from this that the phase crosses over -180 degrees below fs/2. At that frequency it is not a negative feedback system but instead has positive feedback. Which makes it an oscillator if the gain is greater than 1 at that frequency.

The gain is the same at all frequencies.

Zero gain margin requires that something be done about the gain or phase response. The classic technique being lead compensation. The Wyatt paper I linked to earlier shows an example of that. But note also the high steady state error.

Lag compensation can be used to adjust that.


You also need to do something about the Nyquist violation with the data. A 42Hz corner frequency just doesn't cut it with a 40 Hz sample rate. The least that should be done is to filter all 5 samples rather than just drop 4 of them when going from 200SPS to 40SPS.

There is code in MatrixPilot to do that but it is for UDB4 that uses its internal ADC to read the data.
 
I was able to do another test flight of the stabilized rocket this weekend. I think it was a pretty good flight. Here's the video...

https://youtu.be/MkRiJGK7qV4

Relative to last month, I reduced the gain by quite a bit. This included canards that are half the size, a 30% reduction in the servo gain, and a lower top-end speed. Overall, this gives about a 4 to 5-fold reduction in the gain at the maximum speeds for the flights. There is still some instability in the roll control, but not nearly as bad as before. I also note that it took 2 seconds for the rocket to go from the initial 5.5° tilt to vertical. I suppose this is partly due to the change in the gain. However, the smaller canards and smaller motor make the rocket more over-stable (3.7 calibers), and I suspect this slows down the response as well. Good to have that data.

Jim
 
That looks reasonable for the conditions of the flight with reduced gains. What does the velocity look like?

One idea about the roll oscillations after burnout: I have seen something like this in motor controls I've designed: when go through a region with minimum error along with a deadband in the linkage, it will no longer act as a closed-loop system. It will thrash around with noise commanding the mechanical "looseness", often overshooting. A practical case in a servo controller of a robot arm would be the situation where the arm is pointing straight up, stationary, with very little load... and it cannot remain still. Dampening it with some mass (or move slightly off top-dead-center) and the "jittering" goes away.

Another reason could be the gains are too high after burnout at max Q, pushing the system into an unstable mode.
 
Sounds like you had a good flight Jim!

I also note that it took 2 seconds for the rocket to go from the initial 5.5° tilt to vertical.
If you are looking to maximise height then you don't need neck-snapping performance. That costs kinetic energy. What you have sounds pretty good to me.

However, the smaller canards and smaller motor make the rocket more over-stable (3.7 calibers), and I suspect this slows down the response as well. Good to have that data.
That will definitely slow the control system down.
 
However, the smaller canards and smaller motor make the rocket more over-stable (3.7 calibers), and I suspect this slows down the response as well. Good to have that data.

But what did the lighter and smaller diameter motor do to the moment of inertia?
 
But what did the lighter and smaller diameter motor do to the moment of inertia?
I am guessing both roll and pitch/yaw intertia figures are reduced a bit, which goes to making the control systems a bit more twitchy. The reduction in sweep and size of the canards, along with the reduction in airspeed will all go towards reducing the "gain" of the system and contributing to the stable flight.
 
Great video of the spin can in action! The flight looked great. Sorry to hear about the damage.


Sent from my iPhone using Rocketry Forum
 
That looks reasonable for the conditions of the flight with reduced gains. What does the velocity look like?

One idea about the roll oscillations after burnout: I have seen something like this in motor controls I've designed: when go through a region with minimum error along with a deadband in the linkage, it will no longer act as a closed-loop system. It will thrash around with noise commanding the mechanical "looseness", often overshooting. A practical case in a servo controller of a robot arm would be the situation where the arm is pointing straight up, stationary, with very little load... and it cannot remain still. Dampening it with some mass (or move slightly off top-dead-center) and the "jittering" goes away.

Another reason could be the gains are too high after burnout at max Q, pushing the system into an unstable mode.

The velocity for this flight reached about 660 ft/s versus 810 ft/s for the flight last month. I notice that the instability in the flight last month also started after burnout.

One other thing I noted in the current flight was that the rocket did about 2/3 of a turn in the period from 1-2 seconds where the rocket was making it's largest pitch/yaw adjustments. The roll correction gets superimposed on the pitch/yaw adjustments, and I guess if everything isn't exactly right, there could be some net turn. I've always wondered how well the control system would function on roll adjustments during a vertical correction.

Edit - There was supposed to be a significant wind shear at around 3K feet (wind around 25 mph but lower above and below). I think that shows up in the data. Looks like the rocket is kind of struggling to stay vertical.

Jim
 
If you are looking to maximise height then you don't need neck-snapping performance. That costs kinetic energy. What you have sounds pretty good to me.

Well, the real goal is "just a little guidance", just enough to go vertical during a nominal 10-second coast.

The spin can got damaged when the power company took the rocket off the wires. They were great to come out on a Saturday and they didn't charge me anything (nor did they charge the next guy that landed on the same wire). I do wish they would have noticed the quick link on the fin section and just used that rather than lifting the rocket over the wire and then then dropping it (since the fin section was initially sitting on the ground). That cracked a couple fins (I guess my last-minute tip to tip job wasn't all that great). The problem with repairing the fin can is removing that tip to tip material. I've done that before and it's not easy.

Jim
 
Great footage from the opposing cameras!


Are you wanting to do another smaller scale flight or start integrating the modifications on the stager?
 
Great footage from the opposing cameras!


Are you wanting to do another smaller scale flight or start integrating the modifications on the stager?

I've used the control module on three test flights (a two stage rocket with no sustainer motor) and on three flights with potential altitudes greater than 100K feet. I'm doing the single stage rocket to try to learn more about how the system works, because it's fun, and because I have to stay below 10K to fly it locally.

I haven't had a great deal of luck yet on the 100K flights, but mainly because of unrelated factors. On my first 3 stage attempt, the booster didn't separate, which meant that the system couldn't stabilize. It's an interesting video.

https://youtu.be/eHloNCGlYz4

On the P to N flight (with Stu), the booster whacked the stabilization section and knocked it off the rocket. It's complicated, but another interesting video.

https://youtu.be/87BVKLiDqXI

On the second three-stage attempt, there was a servo failure. A little less interesting video, but it does show the spin can on that rocket.

https://youtu.be/G-Iwi-UF2ck

If you're asking am I ready to abandon this testing to prepare for Balls this year, I'm not sure yet. I would fly it for sure if the fin can hadn't been damaged. But, with the delay of having to rebuild the fin can, I'm not sure there would be enough time to replace it if it was damaged a few months from now (for example). I will probably take a shot at trying to repair it and go from there.

Jim
 
Jim, I ran into something today that might have caused the ultra-fast reversals on your gyro readings a couple flights ago. It sounds like there's a hardware bug in several MPU gyros that will cause reversals and/or erroneous data if the max gyro rate is exceeded.

Here's a video that talks a little bit about it in relation to one of the quadcopter firmwares:
[video=youtube;xIQn35vZBvE]https://www.youtube.com/watch?v=xIQn35vZBvE[/video]

Here's someone with a similar issue on GitHub:
https://github.com/betaflight/betaflight/issues/3959

Googling "invensense gyro overflow bug" or "mpu gyro overflow bug" will bring up some results on it too.

It's possible that something caused on overflow/error condition on the gyro, then the garbage started flowing. Once you go crap in, you can definitely get crap out. The quadcopter firmware called Betaflight has a monitor for this built into their latest version (v3.3). That may be worth looking into or pinging your flight controller company about.

Good luck!
 
Jim, I ran into something today that might have caused the ultra-fast reversals on your gyro readings a couple flights ago. It sounds like there's a hardware bug in several MPU gyros that will cause reversals and/or erroneous data if the max gyro rate is exceeded.

I'm not sure how they can call this "yaw spin to the moon". Isn't that something that should be reserved for rockets?

Just looking at this a little, there are several places where it is stated that the problem is related to the newer 206 gyros and not the MPU6000 that I have. I'm not sure it would matter, though, because in my case, if the roll gyro exceeds the maximum of the range it is set at (1000 degrees/sec), then the yaw and pitch axes are going to lose their orientation and things aren't going to work very well after that. There are some similarities though.

On another note, I was able to sand off the spin can components and start putting it back together again. Maybe it will fly again.

Jim

IMG_1462.jpg
 
I'm not sure how they can call this "yaw spin to the moon". Isn't that something that should be reserved for rockets?
:) There are cases where if a quadcopter clips a racing gate and starts to spin, that the resulting yaw caused a gyro overflow which caused the flight controller to command weird stuff...including a max power climb out of sight. Whee!
 
I was able to do another test flight of the stabilized rocket this weekend. I think it was a pretty good flight. Here's the video...

https://youtu.be/MkRiJGK7qV4

Relative to last month, I reduced the gain by quite a bit. This included canards that are half the size, a 30% reduction in the servo gain, and a lower top-end speed. Overall, this gives about a 4 to 5-fold reduction in the gain at the maximum speeds for the flights. There is still some instability in the roll control, but not nearly as bad as before. I also note that it took 2 seconds for the rocket to go from the initial 5.5° tilt to vertical. I suppose this is partly due to the change in the gain. However, the smaller canards and smaller motor make the rocket more over-stable (3.7 calibers), and I suspect this slows down the response as well. Good to have that data.

Jim


Another advantage of your fin spin can is that the rocket itself doesn't rotate so it can be used for stable imaging of the ground and of space.

Bob Clark
 
I was able to do another test flight of the stabilized rocket this weekend. I think it was a pretty good flight. Here's the video...

https://youtu.be/MkRiJGK7qV4

Relative to last month, I reduced the gain by quite a bit. This included canards that are half the size, a 30% reduction in the servo gain, and a lower top-end speed. Overall, this gives about a 4 to 5-fold reduction in the gain at the maximum speeds for the flights. There is still some instability in the roll control, but not nearly as bad as before. I also note that it took 2 seconds for the rocket to go from the initial 5.5° tilt to vertical. I suppose this is partly due to the change in the gain. However, the smaller canards and smaller motor make the rocket more over-stable (3.7 calibers), and I suspect this slows down the response as well. Good to have that data.

Jim


Since the spin can rotates but the rocket does not, that means gyroscopic stability is induced on the entire rocket just from that obtained from the rotating spin can. In that case, I'm curious about something. Suppose you put a spin can on the rocket without fins. Start the rotation of the can on the ground before launch, then gyroscopic stability should be obtained by the rocket even without fins after launch.

Bob Clark
 
Oh no, this thread has been bobclarked, too!

Since the spin can rotates but the rocket does not,

There is no guarantee the fin can spins at any specific rate or direction, or at all.

that means gyroscopic stability is induced on the entire rocket just from that obtained from the rotating spin can.

No it does not. It is a small (and variable and unintended) rotational inertia compared to the total of the rocket's moments.

In that case, I'm curious about something. Suppose you put a spin can on the rocket without fins. Start the rotation of the can on the ground before launch, then gyroscopic stability should be obtained by the rocket even without fins after launch.

Again, there is no "gyroscopic stability" of any significant magnitude from this design. And there is no "starting" a passive free-rotating fin can. It is a rocket, not a mortar firing with rifling. As usual, AI BOB, you are posting in random places with random BS.
 
I have been looking over the data from my last two flights trying to match up the movement of the canards with the resulting angular velocities. It's working out pretty well for roll, but for yaw/pitch, I still have work to do.

For roll, I calculated the 3D lift slope, the load on the canards as a function of velocity, the resulting torque and the then acceleration based on the radial MOI. I also calculated the "measured" angular acceleration based on the reported gyro rates (calculated using my 0.1 second interval data). The results are in the (second and third) graphs. For the February flight, I am in the ball park for agreement - about a factor of two error, and I suspect the error is due to not getting good measured values for angular acceleration because things were changing very fast relative to the 0.1 second data. For the March flight, with lower angular velocities, the agreement is pretty good. So, this means that I am correctly calculating the force on the canards as a function of deflection angle and velocity.

For yaw/pitch, I am taking the same canard forces as above, calculating the torque based on the distance from the canards to the CG, and then calculating the angular acceleration based on the longitudinal MOI. In this case, I am calculating the "measured" angular acceleration based on the tilt values. The measured and calculated angular accelerations for yaw/pitch are in the (first) graph. The actual changes in the angular acceleration of the rocket are easily an order of magnitude less than what it would be if there were no resistance to changing the direction of flight. Now, I need to incorporate the force resisting the change in direction into this calculation and see if I can come up with something that calculates the actions of the canards on acual rocket movement.

Jim

Edit - the second and third graphs are the radial acceleration and the first graph is the longitudinal acceleration.
Edited again to remove signs of late-night posting.

Graph 1.jpg

Graph 2.jpg

Graph 3.jpg
 
Now, I need to incorporate the force resisting the change in direction into this calculation and see if I can come up with something that calculates the actions of the canards on acual rocket movement.

Careful, that way lies a 6DOF simulation.
 
Careful, that way lies a 6DOF simulation.

I would just like to get a physical feel for the response of the rocket. I was looking at some calculations around the March flight where it appeared from the data that the rocket moved about 5 degrees to vertical over perhaps 1 second or so. Roughly, the torque required to make that change is about 0.5 Nm. At the velocity of the rocket at the time, the canards would have produced a torque on the order of 10 Nm. This would be about the torque on the airframe if traveling at an angle of attack of about 0.3 degrees (which is about what would be produced with a 2 mph cross wind). I'm not quite sure how to use this information?

Jim
 
I did another test flight Saturday. The purpose of the flight was to try to get some data on the vertical stabilization rate. I can calculate the response to roll fairly easily, but I don't know how to do this for changes in yaw/pitch.

The flight started with roll control active. The rocket was launched at 5° with vertical stabilization engaged at 3 seconds (rather than from launch). It took 5 seconds for the rocket to go vertical. This is consistent, but clearer, than data from prior tests.

Jim

https://youtu.be/81Z5_Y5dtrU
 
Fantastic! Of course if you keep doing this, you may get used to being able to fly locally and drop the big Balls flight altogether!
 
Back
Top