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.
If you think a 747 is wicked mathematically, look at the maths behind helicopters :wink:

Here is an example algorithm to calculate the trim of the vehicle during level flight:
View attachment 338054

The "H" with a circle around it is for the pilot to aim so's to keep the pieces confined to a smaller area upon landing. Kurt:wink::lol:
 
Andrew ASC

You lost me at hello.

Maybe Jim understands - for me that was way over my head - but this doesn’t have to be that tough. Jim is right there - maybe just slow the servos response time and movement speed way down or out a delay time on the control - like its “chasing gauges”.




Sent from my iPhone using Rocketry Forum
 
Andrew ASC

You lost me at hello.

Maybe Jim understands - for me that was way over my head - but this doesn’t have to be that tough. Jim is right there - maybe just slow the servos response time and movement speed way down or out a delay time on the control - like its “chasing gauges”.




Sent from my iPhone using Rocketry Forum

Don't worry Nick@JET, you're not the only one scratching their head. I am still trying to figure out what a Boeing 747 has to do with Jim's issue.
 
Maybe Jim understands - for me that was way over my head - but this doesn’t have to be that tough. Jim is right there - maybe just slow the servos response time and movement speed way down or out a delay time on the control - like its “chasing gauges”.

You want the servos to be as fast as possible to get the "transport time" down. Transport time is the time between figuring out the control movement and it actually happening. You tame the control loop by keeping the overall SYSTEM gains low. This can be achieved either electronically or by using smaller fins, or other methods.

Unless you need neck-snapping performance, a slow control loop is easy to tame.
 
Sadly my knowledge has faded with time. I could dig out my textbooks and refresh my memory but that would take time.

In a greatly simplified form, a system with negative feedback will be unstable (oscillate) if the phase shift on the output is 180 degrees. Add this to the 180 degree phase shift inherent in negative feedback and you now have positive feedback. If the loop gain is more than one, the system will oscillate.

Note that you want the gain to be high because the steady state error is dependent on the gain. Higher gain means less error.

Another report I ran across was for a control system designed for the Paiute-Tomahawk sounding rocket and used a compensator which had two poles. Alas, the reference in the paper was to "some dude" so they didn't show their work. That one was particularly relevant because it used small forward fins to control pitch and yaw.

Other than that annoying missing detail it is a quite detailed report showing the hardware design and even includes the program listing.


As for non-linear dynamics, almost all engineering analysis tools assume/require linear systems. Non-linearilty makes life very hard and while there are ways to cope (usually involving linearizing around an operating point), there are still dragons lurking.

While my skills are from the Electrical Engineering side, control systems have a lot of overlap. So here is a stab at the roll control problem.

First up I am going to assume that absolute roll orientation isn't required so that what is being controlled is roll rate. This is important because this improves phase margin by 90 degrees. (If you control roll you already have 180 degrees of phase shift baked in.)

There are of course other sources of phase shift in the control loop.

The sensor has some unknown phase shift due to its sampling and filtering. One of my big gripes with the MEMs sensors is while they include digital filters, they don't tell you anything about their performance. Which is really important here because all filters alter the phase. Some more than others.

The sensor data then goes into the micro-controller which updates periodically. The period matters because that represents a delay which is a frequency dependent phase shift.

In this case the controller then outputs a periodic pulse to control the servo. I have noticed that digital servos are being used which is good because some support higher update rates. Which means less delay and phase shift.

The servo of course has its own feedback system to control its output position. This needs to be included in any model because once again, it adds delay.

Finally the fin will create a force which torques the rocket. The rocket has inertia which will resist any change of course. A lower moment of inertia means that the loop has higher gain so a smaller rocket could oscillate if you use the same gain as you used with a larger one. I pulled up a couple of Rocksim files for some 4 inch class high power rockets and after motor burnout the moment of inertia in the longitudinal axis was on the order of 100 times greater than it was in the roll axis. So the same thing applies there. A gain that is fine for pitch/yaw could result in unstable roll control.

So just from basic principles I can see that it is likely that there will be some frequency where the phase shift is 180 degrees. Which means that the loop gain must not be greater than 1 at that frequency. Which means that the gain must drop with increasing frequency. Which means including a low pass filter.

Alas, low pass filters add phase shift as well so the pole (corner frequency) must be well placed.

Another issue to be dealt with is the update rate on the servos. Standard is 50Hz and that causes trouble. The control system must have more bandwidth than the system being controlled. A Saturn V would probably be fine with a 1Hz rate because nothing happens fast with something that big. But as things get smaller the frequencies get higher. You would like for the maximum frequencies in the system to be no more than 1/10th of the update rate to keep Nyquist and friends happy.
 
Sadly my knowledge has faded with time. I could dig out my textbooks and refresh my memory but that would take time.

Dave, thanks for taking the time to explain this stuff. However, I'm starting to think that the cause of the problem 3 seconds into the flight may have been something other than a control strategy problem. When I recovered the rocket, the switches (attached to the section with the UDB5) had turned slightly. I also found that the key that aligns the board and the air frame was broken. I assumed that this happened during the descent or when the rocket was dragged, as the eyenut for the recovery harness is attached to all-thread that is connected to the control section, but perhaps this was not the case. The section with the control board is attached tightly to the eye nut below and the servo section above. But, it has some weight (the battery mainly) and it obviously did move at some point.

There are a couple of other reasons why I think this may have happened. First, from the gyro data I posted earlier, from 3-5 seconds, the y-axis gyro was oscillating from +1000°/s to -1000°/s over intervals of 0.1 seconds. That would be a rate of change in excess of 20,000°/s/s. I don't have much feel for what that number means, but it seems pretty high, and I question whether this is what the air frame was actually doing. Also, the rocket was rolling during the 7-12 second time period even though the velocity was dropping off quickly. I can't explain why this was happening. Here's a short vid showing the movements of the canards from launch to apogee. The sunlight on the air frame indicates when rolling was occurring. Thoughts?

https://youtu.be/8luuNJXYDDM

In any case, the rocket is ready to fly again at the first opportunity. There is plenty of control authority, so I am going to reduce the gains by a factor of two (unless someone has a better idea). This change would allow canard movement of up to 5° for yaw/pitch up to and above 7.5° or roll up to and above 250°/s, with a maximum canard movement of 10°.

Jim
 

~175 rad/s^2? that's some impressive angular acceleration. Even if it wasn't that high, it'd still be putting some non-negligible torque down the airframe. (side qestion, are there any torsional stress ratings for fwfg tubes? lol)

With this flight's overzealous control activity, how far off vertical did it end up at Apogee? And by your estimation, are you a bit closer to your goal of vertical flight for the big staging flights?

(also, Nasa Student Launch is coming up again! Will you be visiting Rocket City again?)
 
~175 rad/s^2? that's some impressive angular acceleration. Even if it wasn't that high, it'd still be putting some non-negligible torque down the airframe. (side qestion, are there any torsional stress ratings for fwfg tubes? lol)

With this flight's overzealous control activity, how far off vertical did it end up at Apogee? And by your estimation, are you a bit closer to your goal of vertical flight for the big staging flights?

(also, Nasa Student Launch is coming up again! Will you be visiting Rocket City again?)

Unfortunately, I didn't get a gps data file for the flight, so it's hard to say where things went and when. It appears from the first video that the angle changed about 5 seconds into the flight, but judging that angle is pretty hard. It reached 6,600 feet versus a predicted 8,000 feet, and apogee would have been about a half mile out (or maybe a bit more).

I've tried the system on three staged flights (other than the test two-stagers with no sustainer motor). On one flight, I think torque generated by having yaw/pitch activated during the boost caused the booster not to separate. We implemented separate activation of roll and yaw/pitch to address that (so that roll could be controlled through the boost with yaw/pitch turned on after separation). On the second attempt, Stu's booster crashed into the stabilization module causing it to separate. On the third flight, one of the servos failed, and these have now been upgraded. I guess trying to make a rocket go where it doesn't naturally want to go, on a budget, isn't all that easy. I haven't given up though.

My SLI team showed no interest in going back this year even though I think they would have been allowed to. No problem - against all odds, they had a good flight. With my involvement at NARCON and with a few space port teams, I probably won't get to Huntsville. It was a lot of fun though.

Jim
 
There are a couple of other reasons why I think this may have happened. First, from the gyro data I posted earlier, from 3-5 seconds, the y-axis gyro was oscillating from +1000°/s to -1000°/s over intervals of 0.1 seconds.

I can't really tell anything from the plots you posted as the sample rates are just too low. About 10 SPS. Minimum usable would be the same as the servo update rate.

I looked at the video and once I figured out how to step it frame by frame it seems to backup the roll oscillations. Assuming of course that the video frame rate (30fps?) was high enough so that aliasing wasn't a problem.

Which of course brings up questions about gyro LPF configuration. Has this code been published anywhere? I have been fighting the urge to look at it but it seems to be a losing battle. :)

It would be nice to know the control authority. I could calculate that if I knew little things like the roll moment of inertia, and fin geometry.
 
I can't really tell anything from the plots you posted as the sample rates are just too low. About 10 SPS. Minimum usable would be the same as the servo update rate.

I looked at the video and once I figured out how to step it frame by frame it seems to backup the roll oscillations. Assuming of course that the video frame rate (30fps?) was high enough so that aliasing wasn't a problem.

Which of course brings up questions about gyro LPF configuration. Has this code been published anywhere? I have been fighting the urge to look at it but it seems to be a losing battle. :)

It would be nice to know the control authority. I could calculate that if I knew little things like the roll moment of inertia, and fin geometry.

Yes, we should record data at a faster rate.

30 fps I believe

I can't help you much on the LPF. The basic program is MatrixPilot.

Remember that this rocket has a spin can.

Jim
 
I have looked at MatrixPilot and its default configuration is to set the MPU6000 DLPF to 42Hz. Which is not low enough for a 50Hz servo update rate. Assuming that is the rate used. I can't tell from the code. The MPU6000 code does say that 4 out of 5 samples (@200SPS) are ignored implying a 40Hz control loop update rate.

I have to assume that 42Hz is the 3dB down point for whatever filter the MPU6000 is using. But what is its slope? The data sheet doesn't say. With a 40Hz control loop you need to remove all (or at least most) noise above 20Hz and this will never do it.



The spin can will lower the roll moment of inertia a little.
 
Ooh ooh, I know! y=mx+b!

I'll be back next week, folks!

Let me break that down for those in the audience:
y: Why the heck in Jim doing this?!
m: money is directly proportional to the outcome, y.
x: success increases with the likelihood of having an X (hi Gloria!).
b: breakage factor. As in broken rocket parts, broken software, and broken dreams.

It's a slippery slope! ;-)
 
Let me break that down for those in the audience:
y: Why the heck in Jim doing this?!
m: money is directly proportional to the outcome, y.
x: success increases with the likelihood of having an X (hi Gloria!).
b: breakage factor. As in broken rocket parts, broken software, and broken dreams.

It's a slippery slope! ;-)

[emoji23]
You’re slaying it John!
 
Don't worry Nick@JET, you're not the only one scratching their head. I am still trying to figure out what a Boeing 747 has to do with Jim's issue.

Use the roll output as an input to controls system code from yaw damper device to non linearly adjust the pitch. This way the pitch and roll will no longer cause oscillations after extensive tweaking if the system is successfully developed. Well the system iteratively makes altered commands based on what it senses to remove oscillations. I don't think there's a way to totally remove oscillations entirely but it can nullify most of it in time. It's a method that is complicated to understand and many aspects are beyond my grasp. If you had 2+ degrees of roll at a velocity and you need 0.6 degrees pitch. Then at the next velocity or time higher you need 0.7 degrees roll and like 0.05 degrees pitch then next time stamp 0.1 degree roll and 0.75 degrees pitch. If it keep varying then it's not linear to avoid oscillations between pitch and roll so you want to dampen it ideally.

The methods to do it are there on Matlab website tutorial. The actual specifics of doing it practically and implementing it take skill and knowledge beyond my abilities. I could care less about the 747, the idea of using aileron (roll) control surface output in a controls system to input into another axial direction (pitch for rocket) as control surface to avoid oscillations are what is at heart here in a non linear self dampening math model.

Anyways I got a controls exam and it's gonna kick my rear. I'm still scratching my head.
 
For airplanes they like coordinated aileron/rudder (yaw) turns but in Jim's problem the pitch and roll commands of rocket aren't meshing smoothly in a way that minimizes oscillations. Yaw dampers correct oscillations in real time. Even if reduce gain you may still have oscillations by one control surface output affecting the other's direction control surface response output with the airframe vibrating until the yaw damper fixes it by successively making slight inputs. Kind of like mixing for R/C and varying the remote's axi control stick movement input to servo movement but way too dorky and harder but it uses more math.
 
Let me break that down for those in the audience:
y: Why the heck in Jim doing this?!
m: money is directly proportional to the outcome, y.
x: success increases with the likelihood of having an X (hi Gloria!).
b: breakage factor. As in broken rocket parts, broken software, and broken dreams.

It's a slippery slope! ;-)

I leave a thread unlocked for a day and look what happens. John, you have no =

Jim
 
I have looked at MatrixPilot and its default configuration is to set the MPU6000 DLPF to 42Hz. Which is not low enough for a 50Hz servo update rate. Assuming that is the rate used. I can't tell from the code. The MPU6000 code does say that 4 out of 5 samples (@200SPS) are ignored implying a 40Hz control loop update rate.

I have to assume that 42Hz is the 3dB down point for whatever filter the MPU6000 is using. But what is its slope? The data sheet doesn't say. With a 40Hz control loop you need to remove all (or at least most) noise above 20Hz and this will never do it.

I asked Dr. Premerlani about your question. Here's a slightly edited version of his response. I added a data plot from the last flight as he suggested, showing the time prior to launch (including lifting the rocket and setting to 5 degrees), and I can confirm that the servos are quiet when the board is not moving. If there is other data that might help, let me know.

Jim
----------
In principle he is correct, but, as I am sure you have observed, in practice there is no noise at all getting through to the servos. There are several reasons for this:

1. The MPU6000 has very low noise to begin with. This has been verified with measurements. This is because it has its own built in A/D converter.
2. The computation that determines tilt from the gyros is mostly an integration step. This acts as another filter with a transfer function of 1/s.
3. The roll control gain is very low, we are talking about roll rates with a range of 1000 degrees per second. The noise is literally lost in the signal. Signal to noise ratio is very good.
4. Accelerometers are a bit noisy, but they are not used during your rocket flights. They are used during preflight, but the computations that we use to determine the gyro offsets attenuate the accelerometer noise.

If you want to get a rough idea of how much noise there is, watch and/or listen to the servos when the controls are running and the board is not moving.

The first time I ran the MatrixPilot IMU computations into some servos, I thought the computations were not running, the servos were so quiet they appeared dead.
It was not until I moved the gyros that I realized how slick the whole thing is.

If you want to convince your friend, show him some tilt and roll data prior to launch.

Noise.jpg
 
1) Yes it does. But this one has a lot of noise. (see below)
2) The topic here has been roll oscillation so the integration seen by the tilt computation doesn't apply.
3) I have no idea what the gains really are. The code isn't available and I don't know the properties of the fins or airframe.
4) I don't care about the accels. And why you need them to get gyro offsets I don't know.


That plot does not make me feel any better. In fact it makes me think that there is a problem since that is more noise than you should see at any DLPF setting. The MPU6000 is supposed to have half the noise of the MPU9250 yet I see roughly the same magnitude of noise in my 32KSPS data (see attached plot) with 8,800Hz bandwidth as you have in data with 42Hz bandwidth.

There should be 0.032 degrees/sec RMS of noise at a 42Hz bandwidth but that is much higher. I have no idea how you get that much noise. I looked at the PCB design files and the power supply decoupling capacitor for the MPU6000 is stupidly placed. It is connected to pin 1 which is the clock input pin, not the device power supply ground. That is on the opposite side of the part along with the power supply pin. That capacitor should have been located as closely as possible to the supply pins. It does no good at all where it is but is unlikely to be responsible for that much noise.

But my primary concern was not sensor noise.

To show the problem I filtered data from the MPU9250 and reduced the sample rate to 200SPS. The same sample rate that MatrixPilot runs at. There is a lot of high amplitude noise during launch. Now imagine what happens if you don't filter it out and happen to sample at a peak or three.

Things can and will happen during flight that produce high frequency and high amplitude data.

noise1.png

noise.png
 
That plot does not make me feel any better. In fact it makes me think that there is a problem since that is more noise than you should see at any DLPF setting. The MPU6000 is supposed to have half the noise of the MPU9250 yet I see roughly the same magnitude of noise in my 32KSPS data (see attached plot) with 8,800Hz bandwidth as you have in data with 42Hz bandwidth.

Maybe I didn't plot a good data set? There was a lot of wind. Here's a plot from last fall.

Jim

Noise2.jpg.jpg
 
That would be a rate of change in excess of 20,000°/s/s.

I ran a back of the envelop calculation which resulted in a roll angular acceleration at 250m/s and 5 degrees of 120 rad/s^2 per fin. Or nearly 7,000 degrees/s^2.

I had to guess at the physical parameters but that is definitely in the ballpark of what was seen.
 
Have not checked into this thread in awhile.

In my 1988 Sunguidance project, while most of it was about fight path control (pitch/yaw), I also did a little testing for roll control, with this configuration:

t1nvkhG.jpg


Go to 2:20 in the video linked below, to see the start of 5 Sunguidance fights that had a Cineroc onboard. First two flights were ballistic, with roll control only. Sun sensors were arranged to sense slight for the side, and the sun was at an angle around 45 to 60 degrees elevation. The first fight was badly over controlled. As it builds up speed, it overshoots, comes back, overshoots further,r comes back, and then it just “locks up” because the roll rate overshoot was so much that it rolled to far to come back. Also, the nice slide fit of the payload section allowed it to rapidly rotate around and around (note the lower main body and fins spin around). It rolled so much I was able to see it by eye, so knew I needed to make some changes. But I had no means to reduce the servo range of motion at the field.

For flight 2, I physically trimmed the roll tabs to be smaller, which helped lot. For awhile it was REALLY in a sweet spot for control (made the planned 90 degree roll correction due to the way it was oriented at launch, then stopped the roll and held position nicely for awhile), then got fast enough to start to over control some. Not too badly but enough to show that ideally the control response range ought to be relative to the velocity, not a fixed control response range. And this model did not have that much of an increase in velocity from the "sweet spot" to where it began to wander. Eventually it ended up rolling but it was more due to the ballistic path veering towards the sun so there was no longer a good sun angle by the side-facing roll sensor (ground-based video shows the flight path, before the Cineroc footage).

[video=youtube;I6ZFSSBQNT0]https://www.youtube.com/watch?v=I6ZFSSBQNT0[/video]

Pretty sure I posted some of the above before. Only two tests of roll, but I learned a lot from them. A big one being how easy it can be to over-control in roll. I theorized that the best way to address that would be to have an onboard computer, or some other means, to dial down the servo range of motion dependent on the speed of the rocket. Of course that being in 1988, where I barely knew enough electronics to make sun guidance work (relatively easy for the sensors used), microcontrollers not being a thing (for hobbyists at my level) and zero programming, I left that as a method someone might try someday.

I know many in this thread know this, but I’ll mention that aerodynamic force is squared by the increase in velocity. So let’s say the roll control system is tuned to work perfectly at 100 mph, no overshooting. Now let’s say the rocket will have a maximum velocity of 600 mph (I choose 600 to avoid messiness with Transonic issues). The aerodynamic forces are not 6 times higher than at 100 mph. They are 36 times higher than at 100 mph ( Velocity squared, so 6x6=36). So if the roll control response was ideal at 100 mph, then the servos need move 1/36th as much at 600 mph than at 100 mph.

Of course I’ve just picked a convenient number by saying 100 mph, let’s say the roll control was tuned to work ideally at 200 mph, in which case for 600 mph the servos should move 1/6th as much (or for 800 mph, ignoring sonic issues, 1/16th as much).

Which then begs the question, how best to determine and program that to happen real-time during flight. If the velocity data from the accelerometers is good (not badly affected by axial vibrations from the motor), then it could use that as a basis for determining how much to tune down the servo response as the velocity increases, squared.
 
Last edited:
Thanks for paving the way George. At some point, I'd like to have the gain adjusted to match velocity. I suspect the easiest way to do this is just to program in the flight profile (as opposed to using on-board instrumentation). My system has a launch detect, which would provide the starting time.

Was that a little Jetex fuse?

Jim
 
In any case, the rocket is ready to fly again at the first opportunity. There is plenty of control authority, so I am going to reduce the gains by a factor of two (unless someone has a better idea). This change would allow canard movement of up to 5° for yaw/pitch up to and above 7.5° or roll up to and above 250°/s, with a maximum canard movement of 10°.

Jim

You need to reduce the gains below 1. ( 1 rad/sec/sec for a 1 rad/sec error.)

Angular acceleration = torque/moment of inertia so you are going to have to do some math.

But steady state error is going to be 1/(1 + G) where G is that gain. Gains of less than 1 are pretty much not worth the effort.
 
I am going to reduce the gains by a factor of two (unless someone has a better idea).
In my experience a factor of two in control systems is usually not that significant. I usually (and have been over the past few days on a work project :)) use a factor of three as a minimum change if you want to have a significant change and a better chance of ending up where you want to be. YMMV.
 
You need to reduce the gains below 1. ( 1 rad/sec/sec for a 1 rad/sec error.)

Angular acceleration = torque/moment of inertia so you are going to have to do some math.

But steady state error is going to be 1/(1 + G) where G is that gain. Gains of less than 1 are pretty much not worth the effort.

I can take a look at the numbers, but you seem to be contradicting yourself. Need a gain below 1 but gains less than 1 are not worth the effort?

Jim
 
In my experience a factor of two in control systems is usually not that significant. I usually (and have been over the past few days on a work project :)) use a factor of three as a minimum change if you want to have a significant change and a better chance of ending up where you want to be. YMMV.

As I said earlier, I think the problem I had was a mechanical one. I'm not sure I need to reduce the gains at all, but I'll run some numbers. Next step would be to reduce the canard size, which is no problem.

Jim
 
I can take a look at the numbers, but you seem to be contradicting yourself. Need a gain below 1 but gains less than 1 are not worth the effort?

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.
 
Back
Top