Numerical Diff Eq problems.

[mardlamock]

Soo, I ve been trying to add orientation to my model of the flight dynamics of a rocket but I ve been running into a lot of problems. I didn't bother actually doing the math for the moments of inertia and everything because I guess it really doesnt have that much of an effect on the general behaviour of the rocket,but rather simple specifics of its movement.

The problem is the following, when the rocket is offset from a perfect 90 degree angle at launch, it gains horizontal velocity faster than vertical (due to gravity) and therefore acquires another offset form the launch angle (say it was 89 degrees). The fins of the rocket should stabilize it by using the lift gained from the small angle of attack and point it back towards the velocity vector, this is what produces the gravity turn we all know and love (I think, I might be wrong though). In my model though, the rocket fails to stabilize properly and starts rotating uncontrollably after a certain amount of time.

At first it oscillates as a pendulum would,but deviating just a bit more with each period and gaining more and more angular velocity. Is this something that naturally arises when using euler's method to analyse this type of motion or would it also happen if I were to use Runge-Kutta's? I was thinking it may be something that naturally happens when using discrete time to analyse something that would be continous. By reducing the time step I was able to increase the time it would take for the deadly rotation to take place, but im running out of memory on excel (Its waay easier than using matlab or anything else, at least for me).

Anyways, please tell me what you think, tell me if you want the sheet to see if there's anything wrong, and if you need i ll draw some pictures on paint to better illustrate the problem.

Thank you very much!

[UmbralRaptor]

Random thought: is there any damping force in the oscillation?

That said, pictures and equations are likely to help immensely.

[PakledHostage]

Random thought: is there any damping force in the oscillation?

I think this is a good guess. You're probably using the geometric angle of attack of the tail fins to impart a restoring moment, but in reality the fin's angle of attack would vary with the rotational speed and the angular displacement (i.e. aerodynamic angle of attack != geometric angle of attack).

You might also want to double check how you've formulated your equations to make sure you're not aggravating the problem due to a loss of precision. A good read is "Lies My Computer and Calculator Told Me".

[mardlamock]

http://latex.codecogs.com/gif.latex?%5Chuge%20x%27%27_%7Bj%7D%28t%29%3D%5Cfrac%7B-%5Cfrac%7B1%7D%7B2%7D*A*C_%7Bd%7D*1%2C225*e%5E%7B-x_%7Bj%7D*10%5E%7B-4%7D%7D*x%27_%7Bj%7D%5E2+F*sin%28%5Ctheta%20%29-g*%28M_%7B0%7D-M_%7Br%7D*t%29%7D%7BM_%7B0%7D-M_%7Br%7D*t%7D

http://latex.codecogs.com/gif.latex?%5Chuge%20x%27%27_%7Bi%7D%28t%29%3D%5Cfrac%7B-%5Cfrac%7B1%7D%7B2%7D*A*C_%7Bd%7D*1%2C225*e%5E%7B-x_%7Bj%7D*10%5E%7B-4%7D%7D*x%27_%7Bi%7D%5E2+F*cos%28%5Ctheta%20%29%7D%7BM_%7B0%7D-M_%7Br%7D*t%7D

- - - Updated - - -

I ll be posting a the rest in a few minutes

[K^2]

Have not had a chance to take a proper look at it, but from previous experience with aerodynamics sims, my first guess goes along with PackledHostages. Taking into account rotational velocity usually takes care of damping. Just compute relative wind vector for each fin, then use thin air foil theory as approximation.

Oscillations building up into tumbling could be due to integration errors. You should use at least 2nd order method for problems approximating harmonic oscillator.

[mardlamock]

Thats what I did, http://i.imgur.com/bXkdEyH.jpg I used thin airfoil theory to estimate the lift coefficient. By making the change in time smaller I was able to get almost rid of the osicllation but it is still there (+- 1 degreee isnt that bad IMO). https://cdn.fbsbx.com/hphotos-xpa1/v/t59.2708-21/10740687_10203439585645884_287536767_n.xlsx?oh=223ccd3ae4dae86deba3711280b4af32&oe=54A5B90E This is the excel file, sorry for the weird colours and ....ty colour coding, im terrible at making things look pretty (or work at all). Getting a 3rd or 4th degree runge kutta will take me a lot of time, but it may be worth it.

Edited December 31, 2014 by mardlamock
added file

[K^2]

Little advantage of higher order RK here. Should work with 2nd. Have you tried linearizing your diff eq? Ideally you want to see it turn into critically damped harmonic oscillator. But anything close should be stable.

[mardlamock]

Cool, less work to do if I only need 2nd order RK. I havent tried linearizing it but i will have to learn what the hell that is and try it out (still in junior hs, any good resources you might recommend). The problem seems to become apparent when the velocity reaches speeds below 50m-s (that is it is launched somewhere close to a 90 degree angle), the rocket then has to do a pretty large turn to start facing the velocity vector and it just fails and flops all over the place. Changing the moments of inertia to something realistic could help, but I dont have any flight data to compare it with. Tomorrow I´ll try doing the 2nd order RK and see if it is any better, thanks a lot man!

[Three1415]

mardlamock, I think I found your problem(s). First though less significantly, your units are kind of broken (acceleration != Force/(mass*time) -g), but more problematic is that you did the same thing that I did when I was trying to model drag forces: You used Newton drag and broke it down into velocity components, which cannot be done. This is because breaking the velocity vector into components and then squaring them individually does not give you a drag-force vector at the angle opposite to motion [arctan(x_j/x_i)] but rather a much different one [arctan(x_j^2/x_i^2)], which means that in your model, drag is applying a torque to your craft, thus the wobbling.

The correct form is counterintuitive: drag force in two dimensions looks like this: F_x = C * (v_total) * (v_y) and F_y = C * (v_total) * (v_x). Since you are already doing this numerically, correction is probably not that hard, though you may have to use higher-order numerical approximations like Runge-Kutta to account for this. I do not have much experience with numerical models, however, and thus I will defer to K^2 or other people with more.

Edited January 2, 2015 by Three1415

[arkie87]

I dont think adding in moment of inertia terms will help, since although it will take longer for the oscillations to form, they will also be harder to stop, since they will have much more inertia..

The correct form is counterintuitive: drag force in two dimensions looks like this: F_x = C * (v_total) * (v_y) and F_y = C * (v_total) * (v_x). Since you are already doing this numerically, correction is probably not that hard, though you may have to use higher-order numerical approximations like Runge-Kutta to account for this. I do not have much experience with numerical models, however, and thus I will defer to K^2 or other people with more.

Why is F_x = C*v_total*V_y and not: F_x = C*v_total^2 * cos(theta) and F_y = C*V_total^2 * sin(theta)?

[mardlamock]

mardlamock, I think I found your problem(s). First though less significantly, your units are kind of broken (acceleration != Force/(mass*time) -g), but more problematic is that you did the same thing that I did when I was trying to model drag forces: You used Newton drag and broke it down into velocity components, which cannot be done. This is because breaking the velocity vector into components and then squaring them individually does not give you a drag-force vector at the angle opposite to motion [arctan(x_j/x_i)] but rather a much different one [arctan(x_j^2/x_i^2)], which means that in your model, drag is applying a torque to your craft, thus the wobbling.

The correct form is counterintuitive: drag force in two dimensions looks like this: F_x = C * (v_total) * (v_y) and F_y = C * (v_total) * (v_x). Since you are already doing this numerically, correction is probably not that hard, though you may have to use higher-order numerical approximations like Runge-Kutta to account for this. I do not have much experience with numerical models, however, and thus I will defer to K^2 or other people with more.

Crap, I had no idea you couldnt separate the components like I did, it just seemed like a reasonable thing to do. Could you draw something for me to illustrate what you mean by saying the drag force is applying a torque on the craft? What I understood in your comment is that when there is a horizontal drag force being applied to the craft, it will always generate a torque and no translation due to a missplacement from the center of mass, therefore doing what I did and breaking the translational motion taking into account sideways drag is wrong, because the drag wont generate any translational movement. What I fail to understand though is how, without me having done it, that torque is being taken into account in the equations I formulated. http://i.imgur.com/4I3cFUB.png Here is a pic with a bit of explaining of what I thought. I will change the model and see if it removes the oscillation, but I still dont see quite how. Oh and btw, the units arent broken, its Force/(initialmass-massflowrate*t)-g. If you dont mind me asking, what where you building a drag force model for? Anyways, thanks a lot man, you ve been extremely helpful!

[Three1415]

Why is F_x = C*v_total*V_y and not: F_x = C*v_total^2 * cos(theta) and F_y = C*V_total^2 * sin(theta)?

Blast--I switched v_x and v_y for some reason. But otherwise the descriptions are equivalent:

theta = arctan(v_y/v_x)

sin(theta) = sin(arctan(v_y/v_x)) = v_y/sqrt(v_x^2+v_y^2) = v_y/v_total

F_y = C*v_total^2*v_y/v_total = C * v_total * v_y

cos(theta) = v_x/v_total

F_x = C*v_total^2*v_x/v_total = C * v_total * v_x

Crap, I had no idea you couldnt separate the components like I did, it just seemed like a reasonable thing to do. Could you draw something for me to illustrate what you mean by saying the drag force is applying a torque on the craft? What I understood in your comment is that when there is a horizontal drag force being applied to the craft, it will always generate a torque and no translation due to a missplacement from the center of mass, therefore doing what I did and breaking the translational motion taking into account sideways drag is wrong, because the drag wont generate any translational movement.

Well, it is not actually torque; it just changes the direction of velocity, rather than the orientation of the rocket, but this has disastrous consequences due to the lifting force of your aerofoils.

But first, a demonstration of why one cannot break Newton (F_drag = C*v^2) into components like one would think.

Prepare for poorly illustrated MS Paint diagrams!

This shows what happens when you try to square the components rather than the total velocity: Not only is the magnitude incorrect, but for theta = arctan(v_y/v_x), the direction of this "component drag" is instead arctan([v_y/v_x]^2), which is not the same angle. This property has been annoying physicists (and probably engineers too) for centuries, as now one must resort to the v_total * v_x or v_total * v_y equations, which are coupled and thus unsolvable. Like I said before, you are doing this numerically, so it is not much of a problem for you, but it is unfortunate nonetheless. It is also worthwhile to note that the disparity between "real" and component drag decreases exponentially as one approaches a forty-five-degree angle--this, too, wreaks havoc upon things, as you shall see shortly.

This image shows the effect of the "pseudo-torque" I was talking about earlier on the path of a projectile launched at some initial velocity v. With component drag, it will exhibit "path-bending" and arc upwards rather than downwards for high initial v, as well as weird behavior approaching what would otherwise be terminal velocity. Obviously, this is not what happens in reality, but blame it for causing your model to oscillate and flail about uncontrollably.

Finally, this image illustrates the effects that lead to oscillation with component drag. These effects become more noticeable at high launch angles for the rocket (due to the large disparity between real and component drag as well as the effect of angle of attack on aerofoils), which explains the behavior that you are seeing. In the first stage of the oscillation, the component drag generates force far closer to a ninety-degree angle than the rocket's actual direction of motion, which compounds with the effect of gravity to cause the rocket to accelerate much more in the horizontal direction, forcing its velocity vector towards the x-axis. However, the disparity between real and component drag decreases vastly as the rocket's direction of motion nears forty-five degrees, while the lift generated by the aerofoils increases greatly. This results in the "failed normalization" characteristic of stage two of the oscillation--these rapidly changing forces cause the rocket's direction of motion to, instead of be dampened, "rebound" to an even higher angle than it started with, making this a positive feedback loop exacerbated even further by the fact that the rocket is still accelerating, and the magnitudes of both lift and drag forces grow quickly as speed increases. Thus, this creates the pseudo-resonance that eventually causes the model breakdown: The rocket is "pushed downwards" by component drag, then rebounded to an even greater angle by lift, then pushed down even further, etc. This effect also explains why smaller time-steps prolong failure: Large time-steps will not account for the exponentially-decreasing disparity between real and component drag as well, allowing the rocket to go even closer to the horizontal and thus making it bounce up even higher and so fail faster.

I assumed in these images that the center of lift was not precisely aligned with the center of mass and so could generate torque to, in ideal circumstances, "force" the rocket into a gravity turn like you stated in the OP. However, even if lift cannot provide torque, oscillatory effects will only be suppressed, not removed, and failure will merely be delayed rather than stopped entirely. So correct your drag model!

Oh and btw, the units arent broken, its Force/(initialmass-massflowrate*t)-g.

Well, at least that is something that you do not have to deal with--I did not realize that M_r was mass flow-rate. But now you are stuck with coupled unsolvable differential equations. What fun!

If you dont mind me asking, what where you building a drag force model for?

Well, I represent my high school's FRC team's only non-engineering-type person (I am far more a physicist at heart) and so last year I created a set of equations that would determine what impulse would send the ball into the goal as well as the optimal launch angle to do so. As this model did not include drag, however, and I hate ignoring possibly significant factors in modelling, I resolved that I would expand it this year to include drag forces (on the assumption that we would again be launching projectiles this season) and use that data to program a targeting computer into the robot's cRio. But I made the same assumption that you did--that Newton drag could be split into components. And so, after several weeks of terrible integrals (hyperbolic arctangent, anyone?), horrifying substitutions for velocity, and shoehorning the model into a form that could be used in a C++ framework, I finally realized my error, of course just as I thought I was finished. *POOF* went about fifteen pages of algebra, two MATLAB scripts, an Excel spreadsheet, and some C++ pseudocode. And now I have been relegated to using Stokes drag (F_drag = C * v_total)...So inaccurate at higher Reynold's numbers...So inaccurate... *eye twitches involuntarily*

Anyways, thanks a lot man, you ve been extremely helpful!

You're very welcome.

But honestly, as much as I really hate drag now, I enjoy physics too much not to still like doing things such as this. And I certainly do not want other people to have to suffer what I went through and more or less lose all of their work.

...Wow. As usual, I A: Took a lot longer than I expected to; and B: Wrote far more than was probably necessary...Whatever.

Edited January 2, 2015 by Three1415

[arkie87]

Well, I represent my high school's FRC team's only non-engineering-type person (I am far more a physicist at heart) and so last year I created a set of equations that would determine what impulse would send the ball into the goal as well as the optimal launch angle to do so. As this model did not include drag, however, and I hate ignoring possibly significant factors in modelling, I resolved that I would expand it this year to include drag forces (on the assumption that we would again be launching projectiles this season) and use that data to program a targeting computer into the robot's cRio. But I made the same assumption that you did--that Newton drag could be split into components. And so, after several weeks of terrible integrals (hyperbolic arctangent, anyone?), horrifying substitutions for velocity, and shoehorning the model into a form that could be used in a C++ framework, I finally realized my error, of course just as I thought I was finished. *POOF* went about fifteen pages of algebra, two MATLAB scripts, an Excel spreadsheet, and some C++ pseudocode. And now I have been relegated to using Stokes drag (F_drag = C * v_total)...So inaccurate at higher Reynold's numbers...So inaccurate... *eye twitches involuntarily*

What is FRC? Why are you relegated to using stokes drag (rules of the competition or giving up)?

Either way, I'd say doing all that in high school is quite impressive...

- - - Updated - - -

Soo, I ve been trying to add orientation to my model of the flight dynamics of a rocket but I ve been running into a lot of problems. I didn't bother actually doing the math for the moments of inertia and everything because I guess it really doesnt have that much of an effect on the general behaviour of the rocket,but rather simple specifics of its movement.

The problem is the following, when the rocket is offset from a perfect 90 degree angle at launch, it gains horizontal velocity faster than vertical (due to gravity) and therefore acquires another offset form the launch angle (say it was 89 degrees). The fins of the rocket should stabilize it by using the lift gained from the small angle of attack and point it back towards the velocity vector, this is what produces the gravity turn we all know and love (I think, I might be wrong though). In my model though, the rocket fails to stabilize properly and starts rotating uncontrollably after a certain amount of time.

At first it oscillates as a pendulum would,but deviating just a bit more with each period and gaining more and more angular velocity. Is this something that naturally arises when using euler's method to analyse this type of motion or would it also happen if I were to use Runge-Kutta's? I was thinking it may be something that naturally happens when using discrete time to analyse something that would be continous. By reducing the time step I was able to increase the time it would take for the deadly rotation to take place, but im running out of memory on excel (Its waay easier than using matlab or anything else, at least for me).

Anyways, please tell me what you think, tell me if you want the sheet to see if there's anything wrong, and if you need i ll draw some pictures on paint to better illustrate the problem.

Thank you very much!

When you say you didnt add math for moment of inertia, you mean you assume moment of inertia is zero, or moment of inertia is some small, but finite number, because if its zero, the rocket will never be stable numerically, since any torque will produce infinite angular acceleration...

[mardlamock]

What is FRC? Why are you relegated to using stokes drag (rules of the competition or giving up)?

Either way, I'd say doing all that in high school is quite impressive...

- - - Updated - - -

When you say you didnt add math for moment of inertia, you mean you assume moment of inertia is zero, or moment of inertia is some small, but finite number, because if its zero, the rocket will never be stable numerically, since any torque will produce infinite angular acceleration...

I never said that, I just arbitrarily added a 1/12 moment of inertia constant and then used that. No matter what the moment of inertia is the rocket will tend to stablity if the model is correct, only the time it takes will change.

- - - Updated - - -

Im not seeing any of the behaviour you described, and im sorry if this sounds rude, but even though the drag breakdown makes sense, the oscillations you talked about dont (at least tome=. I sent you a message to see if you want to talk about this in a much more dynamic fashion and maybe see if I can help you with your model and you with mine.

Edited January 4, 2015 by mardlamock

[arkie87]

I never said that, I just arbitrarily added a 1/12 moment of inertia constant and then used that. No matter what the moment of inertia is the rocket will tend to stablity if the model is correct, only the time it takes will change.

- - - Updated - - -

Im not seeing any of the behaviour you described, and im sorry if this sounds rude, but even though the drag breakdown makes sense, the oscillations you talked about dont (at least tome=. I sent you a message to see if you want to talk about this in a much more dynamic fashion and maybe see if I can help you with your model and you with mine.

To clarify, you said:

Soo, I ve been trying to add orientation to my model of the flight dynamics of a rocket but I ve been running into a lot of problems. I didn't bother actually doing the math for the moments of inertia and everything because I guess it really doesnt have that much of an effect on the general behaviour of the rocket,but rather simple specifics of its movement.

Emphasis mine.

So by doing the math you mean calculating the actual moment of inertia, as opposed to just adding in a constant, but non-zero moment of inertia term, which is what you did, and will prevent oscillations from going to infinity.

And which behavior are you not seeing/who are you responding to?

[mardlamock]

To clarify, you said:

Emphasis mine.

So by doing the math you mean calculating the actual moment of inertia, as opposed to just adding in a constant, but non-zero moment of inertia term, which is what you did, and will prevent oscillations from going to infinity.

And which behavior are you not seeing/who are you responding to?

Exactly, I figured that determining the moment of inertia would be better done with real life measurements as opposed to doing it analytically. The behaviour I am not seeing is the ¨Path-Bending¨. I understand why it would happen if the lift force exerted translational acceleration on the body, but that is not the case with a rocket, therefore, the oscillations are not the result of that. Having changed the drag and lift to be dependant on the total velocity and component velocity, the oscillations are still there. Im doing switching to a 3rd order Runge Kutta but its taking been taking me some time. I still believe it is a problem inherent to the use of euler´s method to approximate harmonic motion.

[arkie87]

Exactly, I figured that determining the moment of inertia would be better done with real life measurements as opposed to doing it analytically. The behaviour I am not seeing is the ¨Path-Bending¨. I understand why it would happen if the lift force exerted translational acceleration on the body, but that is not the case with a rocket, therefore, the oscillations are not the result of that. Having changed the drag and lift to be dependant on the total velocity and component velocity, the oscillations are still there. Im doing switching to a 3rd order Runge Kutta but its taking been taking me some time. I still believe it is a problem inherent to the use of euler´s method to approximate harmonic motion.

3rd order runge-kutta? I've heard of 4th, but not third.

I'm not convinced its due to integration order or lack of "component" drag. I've modeled component drag, and i still get oscillations.

How do you model drag and/or lift?

Do you account for area difference when off 0 degree AoA? Do you account for fulcrum distance changing with changing angle?

[mardlamock]

This is what I did. http://imgur.com/4I3cFUB. Im using Newton drag, an exponential model for atmospheric density, thin airfoil theory to estimate the coefficient of lift as a function of the angle of attack. I do account for area difference, the area being an orthogonal projection. http://www./download/led0x2ubszo7avv/10740687_10203439585645884_287536767_n.xlsx This is the older excel spreadsheet I used, I know changed it for component drag and on the side im doing Runge kutta, and yes you can do 3rd order, 4th is more common though. As this particular equation is a stiff equation I might need to use a higher order Rk, but It doesnt hurt to try with 3rd first. As you may see on the side, the whole idea of this is to then detach the fin orientation from the rocket orientation and test dead reckoning and active stabilization systems.

Edited January 5, 2015 by mardlamock

[arkie87]

This is what I did. http://imgur.com/4I3cFUB. Im using Newton drag, an exponential model for atmospheric density, thin airfoil theory to estimate the coefficient of lift as a function of the angle of attack. I do account for area difference, the area being an orthogonal projection. http://www./download/led0x2ubszo7avv/10740687_10203439585645884_287536767_n.xlsx This is the older excel spreadsheet I used, I know changed it for component drag and on the side im doing Runge kutta, and yes you can do 3rd order, 4th is more common though. As this particular equation is a stiff equation I might need to use a higher order Rk, but It doesnt hurt to try with 3rd first. As you may see on the side, the whole idea of this is to then detach the fin orientation from the rocket orientation and test dead reckoning and active stabilization systems.

Angle of attack formula is incorrect as written (might just be a typo); should be x'j/x'i not xj/xi

(Same problem with projected area formula)

also, an easy way to get around the changing sign of drag if velocity is negative part is to use:

abs(v)*v instead of v^2 i.e. F_drag = -C*abs(v)*v (since drag starts out negative)

For components, this isnt necessary since v=sqrt(vx^2+vy^2) >=0

Edited January 5, 2015 by arkie87

[mardlamock]

Yeah thats a typo, same with the projected area. Funny thing you say that, I had just done that sign change in excel when I was getting positive drag all the time.

[arkie87]

Yeah thats a typo, same with the projected area. Funny thing you say that, I had just done that sign change in excel when I was getting positive drag all the time.

So you said before that 1st order euler is unstable for harmonic motion.

It seems like you are right, and it is known to not conserve energy. However, according to this reference, you can used a modified version of euler, which will conserve energy.

[mardlamock]

So you said before that 1st order euler is unstable for harmonic motion.

It seems like you are right, and it is known to not conserve energy. However, according to this reference, you can used a modified version of euler, which will conserve energy.

You have confirmed my suspicions, the only problem is that I dont think adding an energy constraint is possible, maybe making it so that it doesnt increase after MECO could solve it, but if it is harmonic then I am still going to get oscillations. I need some sort of damping but I dont know what force might act as such. Ideas?

[arkie87]

You have confirmed my suspicions, the only problem is that I dont think adding an energy constraint is possible, maybe making it so that it doesnt increase after MECO could solve it, but if it is harmonic then I am still going to get oscillations. I need some sort of damping but I dont know what force might act as such. Ideas?

(1) You misunderstand: if you click on the reference, there is a slightly modified algorithm (Euler-Cromer's Method) which is formulated to conserve energy. You do not have to add this in as a constraint. (all you have to do is use euler, but use x = x + v(k+1)*dt instead of v(k)*dt ) EDIT: it conserves energy to tolerance based on step used. I have tested regular Euler, Euler-Cromer and 4th order runge-kutta, and while regular Euler is unstable and diverges after only a few iterations, Euler-Cromer (and obviously Runge-Kutta) are stable even after thousands of periods.

(2) I think if with 4th order or Euler-Cromer method you conserve energy, then you are solving the physics itself. If the system oscillates, it oscillates... (though in real life, this oscillation is damped by pilot/autopilot using control surfaces).

Edited January 6, 2015 by arkie87

[mardlamock]

(1) You misunderstand: if you click on the reference, there is a slightly modified algorithm (Euler-Cromer's Method) which is formulated to conserve energy. You do not have to add this in as a constraint. (all you have to do is use euler, but use x = x + v(k+1)*dt instead of v(k)*dt ) EDIT: it conserves energy to tolerance based on step used. I have tested regular Euler, Euler-Cromer and 4th order runge-kutta, and while regular Euler is unstable and diverges after only a few iterations, Euler-Cromer (and obviously Runge-Kutta) are stable even after thousands of periods.

(2) I think if with 4th order or Euler-Cromer method you conserve energy, then you are solving the physics itself. If the system oscillates, it oscillates... (though in real life, this oscillation is damped by pilot/autopilot using control surfaces).

Oh I see now, looks cool! Maybe I will try it out, im feeling particularly lazy today so dont count on seeing it today, but maybe further down the week I will compare it to Rk. Im testing the old euler method against some flight data from http://www.altduino.de/ this guy, Its holding up pretty well, but I still want to do the orientation and stability analysis. What did you compare the different approximation methods for? I remember you saying something about having a model for drag as well, would you mind explaining what you used it for? Anyways, thanks man, ill update you when I get Rk working and compare it to Euler Cromer.

[arkie87]

Oh I see now, looks cool! Maybe I will try it out, im feeling particularly lazy today so dont count on seeing it today, but maybe further down the week I will compare it to Rk. Im testing the old euler method against some flight data from http://www.altduino.de/ this guy, Its holding up pretty well, but I still want to do the orientation and stability analysis. What did you compare the different approximation methods for? I remember you saying something about having a model for drag as well, would you mind explaining what you used it for? Anyways, thanks man, ill update you when I get Rk working and compare it to Euler Cromer.

To compare euler, euler-cromer, and RK, i used simple mass-on-spring system, since the point was to show that euler eventually diverges regardless of time step, while euler-cromer and RK are unconditionally stable (regardless of timestep).

I have created a few flight models (in excel and Matlab), but am having trouble deciding what the correct form of the equations should be... perhaps i should just bother ferram...