Physics simulations in python

[Mad Rocket Scientist]

I've been working with a group of people on some model rocketry projects, and I wanted to try simulating retro-propulsive landing with solid engines. As far as I can tell, none of the already available rocket sims have enough control over the design of the rocket (multiple engines, actuators) or allow computer control of the rocket throughout the simulation. While KSP can do this, it doesn't work at small scales, plus I think this would be a fun challenge. Could anyone direct me to some beginner references for physics simulation with computers? I'm familiar with python and javascript, but can work from tutorials designed for other languages. Thanks!

[Green Baron]

I am not a programmer but i do some hobby tinkering with a similar thing (for private use ;-)). Unfortunately i have no clue of Python but some understanding of C/C++, but i am not far enough to show something off.

 

It is no witchcraft; seen from a very high level, in principle you 1 setup 2 loop 3 cleanup.

1 On program startup for every object you have, you setup the starting parameters. Lets assume a tank full of stuff and an engine consuming stuff. Then you enter the loop.

2 in the loop (fixed or variable doesn't matter), you simply calculate the deltaTime between the current and the last loop run, and apply that to your formulas for engine consumption, tank content, center of gravity, velocity, acceleration, whatever. The new values are used at the next loop run.

3 well, yeah. Cleanup after the loop has finished by user interaction (escape or so).

Defining your objects cleverly is crucial, and the technical challenges lie in the arrangement of objects, tasks and scheduling, memory management (in Python not that important), event handling etc.

 

This concept is frequently called the "game loop" and is one of the principle patterns of everything that calculates and does user interaction. Searching "game loop pattern" will give you many results. Also, if you have a concrete example or idea, we could try some pseudo code just for demo.

And maybe a real programmer shows up and helps :-)

Edited November 2, 2018 by Green Baron

[Mad Rocket Scientist]

Thanks, that's mostly how I imagined it, but I'm glad to hear that (at a high level at least) I'm not too far off.

On delta time: That is just the "fine-ness" of the simulation in time, right? For example, if I had an object moving at 10 m/s, a delta time of 1 second would advance the position of the object by 1 meter every loop cycle, and a delta time of 1/10 of a second would advance the object by 1/10 of a meter every time? And without the requirement of running in real time, like a game, I can just leave that as a constant, or are there more considerations than that?

As for concrete examples, I'd like to model a rocket with solid engines, including thrust curves, rotation, gravity, simple aerodynamics, etc. I'd also like to be able to "trick" a control system into thinking it is controlling the rocket, so producing appropriately inaccurate pressure and acceleration values. I want to add later things like specifying the exact location and rotation of the thrust vector relative to the rocket's origin, center of mass shift during flight, momentum effects from moving weights, fins, or landing legs, and multiple engines.

[Gargamel]

So disappointed... thought this would be about a professor getting eaten by a snake....

Edited November 3, 2018 by Gargamel

[kerbiloid]

Unlikely irl solid engines are enough accurately predictable to use them for landing as is.

A second sooner, a second later, and your rocket lands lithobrakes not just as planned.

Maybe you should use a special landing engine with a toroidal chamber getting filled by exhaust of powder gas generators.
With several nozzles around, equipped with flaps redirecting the nozzle exhaust.
Then you would stop descending at several meters height, hover with this engine and slowly land by tilting the flaps.

Edited November 3, 2018 by kerbiloid

[K^2]

Simple physics simulation is basically just numerical integration over Newton's 3rd Law. For general problems, it can get quite complicated, but for simple trajectory computations, Velocity Verlet is usually quite sufficient. Just keep making the time step smaller until results converge. If drag gives you trouble with Velocity Verlet, you can try generic RK4, but I doubt it'll be necessary.

The only notable exception is gravity simulations. These tend to go bad with explicit integration methods over any significant time scales, and you have to do something funky, like implicit collocation methods. But unless your goal is predicting trajectory of a spacecraft in interplanetary space over the next several decades, you simply don't need that sort of precision. For everything else, Verlet has you covered 90% of the time, and RK4 picks up the slack on the rest. So if you get comfortable with these two methods, you have numerical part down.

The rest is just picking the right models. Gravity is a constant force for your case, so that's easy. Simple quadratic drag is good for air resistance until you get into transonic speeds. Engine thrust is going to be tricky. You can get general thrust profiles from manufacturers, but the tolerance on these tend to be bad, so you'll have to add some random variation to have something resembling a real engine. If you encode the thrust curve with something like Bezier curve or cubic spline, moving a few control points around by small random amount, say 10%, should put you in a ballpark of what to expect. You'd have to read up on manufacturer docs to get more precise. But if your method will work with 10% variation in control points, it'll probably work with real engines.

If orientation of the rocket changes, things get a bit more complex. You have to do rigid body physics, for which the key concepts are angular momentum and moment of inertia tensor. Integrating orientation can generally use the same basic principles, but the actual EoMs for bodies with non-degenerate axes can be a touch overwhelming. There are some variations, but by far the cleanest approach is simply to go with Euler's Equations.

Things get further complicated by orientation changes in terms of aerodynamics. The drag coefficient will vary with orientation, and your body and control surfaces may start developing lift. Here, things can get as complex as you'd care to press them. But honestly, if you get to a point where it matters, this project probably has gotten a bit out of hand.

[Green Baron]

5 hours ago, Mad Rocket Scientist said:

On delta time: That is just the "fine-ness" of the simulation in time, right? For example, if I had an object moving at 10 m/s, a delta time of 1 second would advance the position of the object by 1 meter every loop cycle, and a delta time of 1/10 of a second would advance the object by 1/10 of a meter every time? And without the requirement of running in real time, like a game, I can just leave that as a constant, or are there more considerations than that?

Right with the "fine-ness". It takes care that the correct values are applied even if the program runs on computers with different performance. Well, in your example, if the speed is 10m/s, the rocket has moved 10m after 1 second. But the granularity of the clock is in micro- or even nanoseconds as it runs many times a second. PCs have a heartbeat of Gigahertz and 4-20 hearts :-), so on a PC your loop will run thousands of times a second if you let it.

If movement is linear you're fine, but it isn't, you come down from some terminal velocity to 0. Also your thrust curve varies, as does center of gravity, air density, etc. So you have to interpolate between values or look them up from pre-calculated stuff before you apply them to your formulas and use integration methods for the forces you calculated, as @K^2 hast stated in detail.

Quote

As for concrete examples, I'd like to model a rocket with solid engines, including thrust curves, rotation, gravity, simple aerodynamics, etc. I'd also like to be able to "trick" a control system into thinking it is controlling the rocket, so producing appropriately inaccurate pressure and acceleration values. I want to add later things like specifying the exact location and rotation of the thrust vector relative to the rocket's origin, center of mass shift during flight, momentum effects from moving weights, fins, or landing legs, and multiple engines.

I would run them in different modules and do some communication between them so it is easier to keep them apart and later try tinkering with multithreading if Python permits.

Suggestion: In your loop, first call the calculation of is-values and apply variable values for whatever you have as controlling stuff. Write calculated values to an independent data structure. Then call the controller module and let it read the structure, and compare it to what should be and calculate corrections  to the controlling variable as it sees fit, and feed them back via another structure to the calculation routine.

It all sounds that easy, but it isn't. Your rocket will probably paint funny things on the sky on the first tries :-)

Also you must take care that the calculator has finished before the other one reads and vice versa.

The biggest problem is probably choosing the right data structures for fast access and calculation ... ?

 

Edited November 3, 2018 by Green Baron

[Mad Rocket Scientist]

11 hours ago, kerbiloid said:

Unlikely irl solid engines are enough accurately predictable to use them for landing as is.

A second sooner, a second later, and your rocket lands lithobrakes not just as planned.

Yes, I've heard that their accuracy is surprisingly good though. Probably going to do some tests to determine how variable they are, unless anyone has a source for raw testing data of model engines?

11 hours ago, kerbiloid said:

Maybe you should use a special landing engine with a toroidal chamber getting filled by exhaust of powder gas generators.
With several nozzles around, equipped with flaps redirecting the nozzle exhaust.
Then you would stop descending at several meters height, hover with this engine and slowly land by tilting the flaps.

TVC is possible with solid engines: https://www.youtube.com/channel/UCILl8ozWuxnFYXIe2svjHhg/featured

But if I need to control thrust through the burn duration hybrid engines may be the best option, although pairs of 1/2 A or smaller solid engines may work too.

7 hours ago, K^2 said:

Simple physics simulation is basically just numerical integration over Newton's 3rd Law. For general problems, it can get quite complicated, but for simple trajectory computations, Velocity Verlet is usually quite sufficient. Just keep making the time step smaller until results converge. If drag gives you trouble with Velocity Verlet, you can try generic RK4, but I doubt it'll be necessary.

The only notable exception is gravity simulations. These tend to go bad with explicit integration methods over any significant time scales, and you have to do something funky, like implicit collocation methods. But unless your goal is predicting trajectory of a spacecraft in interplanetary space over the next several decades, you simply don't need that sort of precision. For everything else, Verlet has you covered 90% of the time, and RK4 picks up the slack on the rest. So if you get comfortable with these two methods, you have numerical part down.

The rest is just picking the right models. Gravity is a constant force for your case, so that's easy. Simple quadratic drag is good for air resistance until you get into transonic speeds. Engine thrust is going to be tricky. You can get general thrust profiles from manufacturers, but the tolerance on these tend to be bad, so you'll have to add some random variation to have something resembling a real engine. If you encode the thrust curve with something like Bezier curve or cubic spline, moving a few control points around by small random amount, say 10%, should put you in a ballpark of what to expect. You'd have to read up on manufacturer docs to get more precise. But if your method will work with 10% variation in control points, it'll probably work with real engines.

If orientation of the rocket changes, things get a bit more complex. You have to do rigid body physics, for which the key concepts are angular momentum and moment of inertia tensor. Integrating orientation can generally use the same basic principles, but the actual EoMs for bodies with non-degenerate axes can be a touch overwhelming. There are some variations, but by far the cleanest approach is simply to go with Euler's Equations.

Things get further complicated by orientation changes in terms of aerodynamics. The drag coefficient will vary with orientation, and your body and control surfaces may start developing lift. Here, things can get as complex as you'd care to press them. But honestly, if you get to a point where it matters, this project probably has gotten a bit out of hand.

That's really helpful, thanks.

Are quaternions overkill for this? I know they avoid gimbal lock, but is that really an issue if you're staying within 10 degrees of vertical throughout the entire flight?

[Gargamel]

You can spend a lot of effort on simulating the maths here, but given real world circumstances, your simulations will only get you within the ballpark of accuracy. 

I think you need to design for large margins of error, and have active systems on your rocket making adjustments. 

I know this is straying a bit from your intended OP, but...

Use your sims to find your final engine properties.  Then you will know how much thrust you need to do your final suicide burn, and at what altitude.   Unless you plan on launching on a salt flat or frozen lake bed, undulations in the topography will affect your timing of the engine, if that's the method you are planning to use.   Also, while you might try to stay within 10' of vertical, wind and launch angles might throw this off too.

My suggestion might be to limit your theoertical calculations, and lean more heavily on real time calculations.   There are Arduino chips out there that are small enough that won't affect launch mass that much, and using Ultrasonic transducers, you will be able to calculate your altitude accurately enough to perform a suicide burn. 

The transducers are somewhat bulky, but fairly light weight, so you'd probably have a pair of them to balance out the aero drag.  That also increases the reliability and accuracy of the data you are getting from them.  The sensor's are good to about 2-3m, which should be plenty for the size of craft you're building I assume.   

[Mad Rocket Scientist]

2 hours ago, Gargamel said:

You can spend a lot of effort on simulating the maths here, but given real world circumstances, your simulations will only get you within the ballpark of accuracy. 

I think you need to design for large margins of error, and have active systems on your rocket making adjustments. 

We definitely need active control. This simulation is mostly to determine whether it is possible to use solid engines for this, and to test and debug the control code without blowing things up.

2 hours ago, Gargamel said:

I know this is straying a bit from your intended OP, but...

Use your sims to find your final engine properties.  Then you will know how much thrust you need to do your final suicide burn, and at what altitude.   Unless you plan on launching on a salt flat or frozen lake bed, undulations in the topography will affect your timing of the engine, if that's the method you are planning to use.   Also, while you might try to stay within 10' of vertical, wind and launch angles might throw this off too.

My suggestion might be to limit your theoertical calculations, and lean more heavily on real time calculations.   There are Arduino chips out there that are small enough that won't affect launch mass that much, and using Ultrasonic transducers, you will be able to calculate your altitude accurately enough to perform a suicide burn. 

The transducers are somewhat bulky, but fairly light weight, so you'd probably have a pair of them to balance out the aero drag.  That also increases the reliability and accuracy of the data you are getting from them.  The sensor's are good to about 2-3m, which should be plenty for the size of craft you're building I assume.   

Do you mean cm? 2-3 meters is a lot. It also looks like you can improve the accuracy of those by correcting for the speed of sound based on air temp, but I'm hoping accurate enough accelerometers will let us integrate to get our altitude. Initial tests will likely be drop tests rather than using powered ascent, allowing for much more control over where it lands.

[Gargamel]

1 hour ago, Mad Rocket Scientist said:

Do you mean cm? 2-3 meters is a lot. I

That's their effective range.   Especially if you pair them up, it will cancel out the errors.   But yeah, they are accurate to about 2-3 cm, maybe less.  Good enough for the computer to yell FIRE! and then let it fall the last couple cm. 

 

[wumpus]

First with python: you have sci-py downloaded (the replacement for numpy)?  Not sure how well it works with pypy, for simple things it might make sense just to work with pypy.  Also if you want your "loop fineness" remotely reasonable, make sure all floats are 64bit.  Python should be 64 bit (I just checked mine, it is), but I've run into this issue with FFTs and such.

Can you wrap FAR (I assume it is c#) into something you can call with Python (I'm not even sure about the license, you may have to talk to the author)?  I'm guessing the aerodynamics are "good enough" (except that they are for far larger rockets, it might not scale down well to model rockets).  You might be able to build your rockets in KSP and then scale them down and run FAR on them.

Will you even get transonic?  I'd assume that "beyond transonic" would be past the range of model rocketry (in all but large multistage rockets), but getting transonic might be a problem.

And as far as retropropulsion in model rocketry: first, I'd recommend measuring your ignition delay on the groudn with whatever means you are using to ignite your retrorocket.  Also model rockets are kept stable by fins.  It is fairly easy to determine the required speed (about 10m/s assuming stability after a 5g launch off a 1m rod) for stability, so don't try to retro decelerate below 10m/s without fancy stability controls.

[K^2]

On 11/3/2018 at 10:02 AM, Mad Rocket Scientist said:

Are quaternions overkill for this? I know they avoid gimbal lock, but is that really an issue if you're staying within 10 degrees of vertical throughout the entire flight?

You wouldn't want to use Euler angles or anything similar, yes. But describing mechanics in terms of quaternions is awkward. It can certainly be done, but I wouldn't bother. Just use 3x3 rotation matrices. They avoid singularities just as well as quaternions do, but the math is easier to carry out, and rotation matrices have convenient intuitions about rows or columns as coordinate axes. Something that quaternions certainly lack. And there are standard formulae for extracting Euler angles from a rotation matrix if you need them for output or debugging.

As an aside, it's worth pointing out that rotation with quaternions and matrices are very closely related. The multiplicative group of unit quaternions is homomorphic to SO(3) group, which contains all matrices you'd use for rotation. That is, for every rotation matrix, there is a unit quaternion that describes the same rotation. Two, in fact, since changing sign of the quaternion doesn't change rotation it describes. So anything you can do with one, you can certainly do with the other. But your mileage may vary on implementation. Matrices are easier to work with, which is why I recommend them here. In contrast, quaternions take up less space, which is very important in cache optimization, and highly optimized code for quaternion math can be a little faster than matrix equivalent. Both of these make quaternions preferred method in video games. There are also some skinning techniques that leverage quaternions' better behavior under interpolation, such as Dual Quaternion Skinning, but that's getting way off on a tangent.

Some of these considerations may be valid for physics simulations in certain contexts. It's not something you'll ever have to worry simulating a few rigid bodies, though. There, I would absolutely place simplicity and better intuitiveness of rotation matrices above any computational edge you might have with quaternions. As a general rule, whenever correct beats fast, I would skip quaternions.

Edited November 4, 2018 by K^2

[Mad Rocket Scientist]

7 hours ago, wumpus said:

First with python: you have sci-py downloaded (the replacement for numpy)?  Not sure how well it works with pypy, for simple things it might make sense just to work with pypy.  Also if you want your "loop fineness" remotely reasonable, make sure all floats are 64bit.  Python should be 64 bit (I just checked mine, it is), but I've run into this issue with FFTs and such.

I'm just about to get my python environment set up. It's actually been a while since I last used it.

7 hours ago, wumpus said:

Can you wrap FAR (I assume it is c#) into something you can call with Python (I'm not even sure about the license, you may have to talk to the author)?  I'm guessing the aerodynamics are "good enough" (except that they are for far larger rockets, it might not scale down well to model rockets).  You might be able to build your rockets in KSP and then scale them down and run FAR on them.

Will you even get transonic?  I'd assume that "beyond transonic" would be past the range of model rocketry (in all but large multistage rockets), but getting transonic might be a problem.

I think trying to get calls to FAR working will be more effort than just rewriting my own version without any supersonic considerations. The rocket will also likely look like a tube, so there shouldn't be a need for the ability to simulate bricks like FAR can.

7 hours ago, wumpus said:

And as far as retropropulsion in model rocketry: first, I'd recommend measuring your ignition delay on the groudn with whatever means you are using to ignite your retrorocket.  Also model rockets are kept stable by fins.  It is fairly easy to determine the required speed (about 10m/s assuming stability after a 5g launch off a 1m rod) for stability, so don't try to retro decelerate below 10m/s without fancy stability controls.

We will probably end up needing stability control of some kind. Hopefully this sim will make it clear how much and what kind of stability hardware will be needed.

[K^2]

9 hours ago, Mad Rocket Scientist said:

We will probably end up needing stability control of some kind. Hopefully this sim will make it clear how much and what kind of stability hardware will be needed.

A ring rudder tends to work pretty good with model rockets. The ring is bellow nozzle and around the flow. Not being inserted into flow reduces need for fancy materials, and it tends to have enough authority for anything you'd use it for. From there, a simple PID loop should keep the rocket stable, but your overall solution is likely to be way more complex. If you just needed stabilization, I'd grab ready built drone control system, but since you'll probably need to control way more parameters, you'll need an MCU anyways (PIC, Arduino, etc.) and a serious IMU. Fortunately, later are plentiful for drones and helis, so you can get a good one cheap. Then you'd write your own PID loop along with everything else you need.

[wumpus]

On 11/3/2018 at 7:02 PM, Mad Rocket Scientist said:

We definitely need active control. This simulation is mostly to determine whether it is possible to use solid engines for this, and to test and debug the control code without blowing things up.

Do you mean cm? 2-3 meters is a lot. It also looks like you can improve the accuracy of those by correcting for the speed of sound based on air temp, but I'm hoping accurate enough accelerometers will let us integrate to get our altitude. Initial tests will likely be drop tests rather than using powered ascent, allowing for much more control over where it lands.

I'm curious what strategy you have for using solids for such landings.  I'd assume a '"hoverslam" is right out, although it might be possible to blow the tops of the motors (presumably side mounted).  Some sort of two step (burn to near hover, then descend on weaker engines) sounds far more possible, but replaces fine ignition timing with controls issues.

14 hours ago, Mad Rocket Scientist said:

We will probably end up needing stability control of some kind. Hopefully this sim will make it clear how much and what kind of stability hardware will be needed.

 

5 hours ago, K^2 said:

A ring rudder tends to work pretty good with model rockets. The ring is bellow nozzle and around the flow. Not being inserted into flow reduces need for fancy materials, and it tends to have enough authority for anything you'd use it for. From there, a simple PID loop should keep the rocket stable, but your overall solution is likely to be way more complex. If you just needed stabilization, I'd grab ready built drone control system, but since you'll probably need to control way more parameters, you'll need an MCU anyways (PIC, Arduino, etc.) and a serious IMU. Fortunately, later are plentiful for drones and helis, so you can get a good one cheap. Then you'd write your own PID loop along with everything else you need.

My point above is that a ring rudder isn't reliably stable under 10m/s (that's probably well beyond where the fins stall, but fairly easy to check by launching off a rod with controlled acceleration (probably just using a weight and lever to launch)).  You would either have to land with at least the rudder stall speed or put the rudder in the exhaust (or similar games with the exhaust).

Personally, I'd probably stick to "proof of concept" where I retrorocketed to some predetermined height and parachute the rest of the way (not sure if you can get a parachute to open from a good height to measure.  Possibly CO2-assissted parachutes are in order).

[Mad Rocket Scientist]

12 hours ago, K^2 said:

A ring rudder tends to work pretty good with model rockets. The ring is bellow nozzle and around the flow. Not being inserted into flow reduces need for fancy materials, and it tends to have enough authority for anything you'd use it for. From there, a simple PID loop should keep the rocket stable, but your overall solution is likely to be way more complex. If you just needed stabilization, I'd grab ready built drone control system, but since you'll probably need to control way more parameters, you'll need an MCU anyways (PIC, Arduino, etc.) and a serious IMU. Fortunately, later are plentiful for drones and helis, so you can get a good one cheap. Then you'd write your own PID loop along with everything else you need.

I'll look more into ring rudders, those sound useful. Buying a premade IMU might be a good idea, it looks like they cost about $15 USD. The tricky bit of landing probably won't be staying upright, but rather controlling horizontal drift. As for the flight computer, one of the people in the group is thinking of using a raspberry pi. Personally, I think an arduino would be adequate, but nothing's set in stone yet.

6 hours ago, wumpus said:

I'm curious what strategy you have for using solids for such landings.  I'd assume a '"hoverslam" is right out, although it might be possible to blow the tops of the motors (presumably side mounted).  Some sort of two step (burn to near hover, then descend on weaker engines) sounds far more possible, but replaces fine ignition timing with controls issues.

We're actually kind of forced to do a hoverslam/suicide burn since there is no way to control the thrust of the engine. If the engines have tight enough tolerances, then we just have a timing and stability problem as long as the drop height is the same. Otherwise, there is the option of adding smaller engines which the computer can decide to fire or not based on the thrust from the main engine, some kind of thrust termination system (I was personally imagining simply detaching the engine and letting it fly up through the center of the rocket, but some kind of fins that blocked the exhaust could work too), or even jettisoning weight as needed. Adding the smaller engines sort of moves your suggestion of two steps into one step. 

If we're not able to get consistent enough results with solid engines we'll probably have to move to hybrids.

Quote

My point above is that a ring rudder isn't reliably stable under 10m/s (that's probably well beyond where the fins stall, but fairly easy to check by launching off a rod with controlled acceleration (probably just using a weight and lever to launch)).  You would either have to land with at least the rudder stall speed or put the rudder in the exhaust (or similar games with the exhaust).

Personally, I'd probably stick to "proof of concept" where I retrorocketed to some predetermined height and parachute the rest of the way (not sure if you can get a parachute to open from a good height to measure.  Possibly CO2-assissted parachutes are in order).

"Landing" at a point in mid-air is almost certainly how we will initially test the rocket. To make our program sound more respectable, we could use a bouncy castle to prevent damage if the parachute doesn't deploy right.  

EDIT: 

What kind of mathematical model is recommended for velocity? X, Y, Z velocities stored separately? Vectors?

Edited November 5, 2018 by Mad Rocket Scientist

[K^2]

1 hour ago, Mad Rocket Scientist said:

As for the flight computer, one of the people in the group is thinking of using a raspberry pi. Personally, I think an arduino would be adequate, but nothing's set in stone yet.

Pi Zero is definitely viable, and will give you some advantages if you want to get fancy. It's heavier than a stripped-down Arduino, but actually lighter than some devboards I've seen.

1 hour ago, Mad Rocket Scientist said:

What kind of mathematical model is recommended for velocity? X, Y, Z velocities stored separately? Vectors?

You don't want to drag them around as 3 different variables. That's a pain. Use numpy. It provides +/- operator overloads that will let you add two arrays as vectors. (Otherwise, tuples and arrays default to treating + as concatenation.)

import numpy as np
a = np.array([1, 2, 3])
b = np.array([4, 5, 6])
print (a + b)

Moreover, you can do np.cross(a, b) to do cross products, and np.dot(a, b) to do scalar products. So that's basically all of your vector math right there. Numpy will also do matrix products for you. It's a pretty good library for handling all kinds of tensor-like data.

[Gargamel]

2 hours ago, K^2 said:

Pi Zero is definitely viable, and will give you some advantages if you want to get fancy. It's heavier than a stripped-down Arduino, but actually lighter than some devboards I've seen.

Quote

As for the flight computer, one of the people in the group is thinking of using a raspberry pi. Personally, I think an arduino would be adequate, but nothing's set in stone yet. @Mad Rocket Scientist

Way overkill too.

 I use ATTiny 45/85/44/84 chips for anything I need a really small package.   All the circuitry can fit on the tip of my finger if you design the board correctly, bit bigger if not. The bigger chips (44/84) are about 3/4" long and about 1/4" wide (18mm x 6mm), the smaller ones about half that length.  I won't even guess at the weight, but it's less than 2-3 US quarters.    I think you'll need a Resistor and a cap too to filter the noise, but you could get away without.  

They will take the entire C++ language that you can put into a normal Arduino.  You'll need to make yourself an ISP programming shield that runs off an Uno to program it.    You just upload the ISP programming sketch onto the UNO, plop the shield on,  drop the chip onto the shield, upload the Flight control program onto the chip, and then drop the chip onto the final circuit board.     You can even add jumpers to your FC board if you need to reprogram it later, or just use a socket so you can pull the chip on and off at will, but that will add a bit of size and weight, but not much.  The ISP programmer shield is easily to build, I did it in an afternoon.   I have hand soldered entire boards on circular perfboard that were about 20mm diameter. 

The entire package from UNO to Attinys shouldn't run you more than $40 all said, depending on what you get.   Each ATTiny runs about $1-$2 each, less if you buy in bulk (like a stick of 12 or so).   And bulk may be good if you plan on wrecking some in a fiery crash.  

The reason you don't see them pushed a lot, is that they are a lone chip.   You have to design your own IC board with it.  That itself is it's own rabbit hole.  But if you only have one or maybe 2 other IC's on the same board, it should be a fairly simple task to do.   The art of home board making is pretty fun too.  Even if you don't go with a printed board, perfboard is an option too, but that will add weight.    At the very least someone can design you a board, and then you could send it out for fabrication.  That's pretty cheap too.

 

ATTiny 45/85 for size.   It's the little black 8 legged chip in the corner.   The 44/84's have an extra 8 legs for more connections if needed.   And if you have the moxy and get a surface mounted version, rather than a through hole, they get tiiiiiiiiny. 

Edited November 6, 2018 by Gargamel

[Mad Rocket Scientist]

1 hour ago, Gargamel said:

Way overkill too.

 I use ATTiny 45/85/44/84 chips for anything I need a really small package.   All the circuitry can fit on the tip of my finger if you design the board correctly, bit bigger if not. The bigger chips (44/84) are about 3/4" long and about 1/4" wide (18mm x 6mm), the smaller ones about half that length.  I won't even guess at the weight, but it's less than 2-3 US quarters.    I think you'll need a Resistor and a cap too to filter the noise, but you could get away without.  

[...]

I didn't even know they made microcontrollers that small and cheap. Thanks.

Getting more into the specifics:

I have a object at rest 10 m above the ground. To simulate its motion, can I do something like this?

import numpy as np
g0 = np.array([0.0,0.0,-9.81])
position = np.array([0.0,0.0,10]) #does it matter if these are arrays vs. lists?
velocity = np.array([0.0,0.0,0.0])
t = 0
dt = 0.01

while position[2] > 0:
  t += dt
  position += velocity * dt + 0.5 * g0 *dt * dt #Just stealing this from someone else's implementation of the velocity verlet...
  velocity += g0 * dt

Testing this, I get 0.003 seconds of from sqrt(2*d/9.81) where d = 10. I also get completely shocked that it worked so well. 

[K^2]

3 hours ago, Gargamel said:

Way overkill too.

For a simple control loop? Absolutely. But with Pi, you can also be managing video recording and live telemetry (via WiFi if you get Zero W version). Not to mention that you're basically running a full OS, so you can write your control scripts in anything you want, and use full debug suit without having to worry about compiling/assembling code for a particular MCU, and worrying about op counts and memory overhead. Granted, later tends to become moot with modern MCUs, but even then, debugging in viva can be troublesome.

Doesn't change the fact that it's overkill, of course, but I also see little reason not to go overkill. Pi Zero is cheap, light enough for anything bigger than an A engine, and very easy to use even for somebody with no experience with programming and flashing MCU.

I never tried ATTiny, but I've used to be all about PIC MCUs myself. Tiny, cheap, come in variety of models and packages for every job. But I'm starting to lean more and more towards just dropping a Pi Zero in and having the same tools available as if I was working with a PC. Call it lazy, but for $10 and 9g, I don't mind being lazy.

Also, I don't insist that it's the right solution. Just that the fact that it's overkill doesn't make it the wrong solution.

 

@Mad Rocket Scientist That code looks good. Your dt is 0.01 seconds, so that's as precise as you're going to get your answer. You can try reducing dt further, and you should get closer and closer to the analytical result, but whether you need to will depend on precision you actually need from your system.

[Gargamel]

17 hours ago, K^2 said:

Call it lazy, but for $10 and 9g, I don't mind being lazy.

I hear that, but if your budget is $2 and 1g..... 

As for live telemetry, I would fully expect a rocket to travel outside of wifi range.   If not, the ESP-whatever breakout boards are very small.  Arduino does have a 2.4ghz radio chip available, small and light, with basically LOS range, along with requisite software libraries. 

But it depends on budgets: money, size, and weight.  

[K^2]

On 11/6/2018 at 2:58 PM, Gargamel said:

I hear that, but if your budget is $2 and 1g.....

*shrug* No argument in general, but the smallest servos I've worked with just happen to be 9g each as well, and you'll want at least two of these, plus a power pack to keep them running. So you're probably looking at something like 30g and $20+ of hardware before you consider MCU. That still doesn't make cost and weight of Pi Zero trivial, but certainly blunts the impact of going with something smaller.

Anyways, without more details, "It depends," is probably the most that can be said, yeah.

[Gargamel]

2 hours ago, K^2 said:

I've worked with just happen to be 9g each as well

Those will do, the 9g's will probably be able to handle the loads, but they do make smaller, lighter, and stronger digitals, but for that, it'll cost ya....

2 hours ago, K^2 said:

Anyways, without more details, "It depends," is probably the most that can be said, yeah.

Yup.  

[Mad Rocket Scientist]

I don't know about what budgets (money, mass, time) will be the most important.

Two other questions:

Is it reasonable to assume that mass flow rate is linearly correlated with thrust?

And about 3x3 rotation matrices: do they describe a specific rotation of an object in space at a point in time, or do they describe the act of rotating from one rotational point to another?