Fly Straight Up

[krusty]

Hi Welcome aboard!

Check out this - https://hackaday.com/2010/08/03/diy-guided-missile-err-model-rocket/

and https://sites.google.com/site/airwavershr/Home/guided-rocket

Looking forward to seeing what you come up with!!

Krusty

 

[mikec]

Check out this - https://hackaday.com/2010/08/03/diy-guided-missile-err-model-rocket/

This project seems to use only accelerometers and no gyros. You can't solve the general guidance problem without gyros because accelerometers can't directly sense gravity.
Try reading this: https://www.lunar.org/docs/LUNARclips/v5/v5n1/Accelerometers.html

Flying straight up is probably easier to do with some sort of visual or thermal reference, like https://georgesrockets.com/AOL/GCGassaway/Sunguidance.htm

 

[jderimig]

I have been experimenting with an ST L3GD20 3 axis gyro. Using a DCM algorithm I have observed only about 1 degree of drift in about 20 secs.

A decent 3 axis gyro is all you need for this application.

The correction algorithm is very simple also. Perform a vector cross product of the body z-axis with the earth z-axis. The body x and y magnitudes of the result will proportional to the actuator magnitude of each control surface.

 

[Joe Walsh]

Thanks for the welcome, krusty. It's a helpful community you guys have here.

A saw the hackaday project last year when I first started looking into this stuff. Until reading mikec's post, I didn't realize they only used accelerometers (they wrote: "At launch as explained above, the rocket pitches over to horizontal. The Arduino knows this from the accelerometer data."). Now I'm wondering how they got the rocket to fly horizontal at all. Maybe just a fluke that matched expectations.

A decent 3 axis gyro is all you need for this application.

That really seems to be the case. I was thinking of using the accelerometer just for calibration on the pad. The DMP unit on the MPU-6050 can do that for me. It wanders for about 10 seconds before locking on an orientation. I use that as zero, and afterward it works fine. But I could just as well do a 10 second calibration with just the gyros. That might actually be what the DMP does: IvenSense has the functionings of the unit pretty well locked up. I looked at the L3GD20 too. I'm not sure if it's more accurate than the MPU-6050, but it might be.

The correction algorithm is very simple also. Perform a vector cross product of the body z-axis with the earth z-axis. The body x and y magnitudes of the result will proportional to the actuator magnitude of each control surface.

This is a good idea, but for my application I think it's incomplete. I'm not using control surfaces, so a simple displacement solution is going to hunt. That's why I was going to throw the angular velocity in, too. Once I've finished the math and run a few tests, I'll know what weight the derivative term should have. If it's less than %5 then I might just leave it out altogether.

Try reading this: https://www.lunar.org/docs/LUNARclips/v5/v5n1/Accelerometers.html

This is a good clip, thanks for sharing. It confirms my thoughts on accelerometers. The ArduIMU must not use accelerometers to determine which way is down. Although I sure got the opposite impression after reading their literature. On page 1 of their paper (https://gentlenav.googlecode.com/files/DCMDraft2.pdf) they write "The measurement of gravity is what is needed to level the plane but that is not what you get out of an accelerometer during accelerated motion." Exactly. But then they go on to say " A ballistic path can produce zero net forces and therefore fool accelerometers temporarily." Temporarily? An accelerometer is always fooled on an airplane. The ballistic path is just a special case of the foolery.

This seems to be a problem I've noticed among engineers, mathematicians, and scientists. Those that best understand something in their own head have the most trouble bringing about the same knowledge in somebody else's. I suppose that's what it takes to be recognized as a genius: understanding a new idea and communicating it with equal aptitude.

 

[jderimig]

I looked at the L3GD20 too. I'm not sure if it's more accurate than the MPU-6050, but it might be.

No idea, but it is cheap ~$5.

What is unknown (to me) is how any of these units react to large accelerations.

 

[mikec]

An accelerometer is always fooled on an airplane.

No, it isn't. When a plane is in level flight, it's being held up by lift and an accelerometer reads 1g from the reaction to the lift force, just as an accelerometer reads 1g sitting on a table.
You could try reading https://en.wikipedia.org/wiki/Proper_acceleration but it's not that clearly written.

 

[Sooner Boomer]

I've thought about this problem for many years. I've got a lot of experience in moving and controlling things (every thing from motion control systems like multi-axis mills/lathes to environmental control systems). Two issues, neither is controller/CPU. 1) you're going to need some sort of PID loop in the software, and 2) aircraft-type servos aren't going to work - speed, resolution, and lash/hysteresis are just a few of the problems.

The software is not really a big problem (Ha!). There are lots of textbooks on the subject, including numerical method cookbooks. There's also the issue of how big a dead zone you'll have.

What I see as the biggest challenge will be the actuators. Will you use proportional output or bang-bang? They need to operate almost instantaneously, and can't have any "slop" (lash) or overshoot. The rate of response can be dealt with in part by the software. One interesting solution might be some kind of piezoelectric fin tab.

 

[DaveHein]

Here's the circuit I used in the Quad Pod II a few years ago. It used a 2D gyro chip with a Parallax SX microcontroller, which is similar to a PIC.

Gyro drift isn't a big problem since the control circuit only needs to work for the few seconds that the motor burns. I used an F10 motor that has a burn time of 7 seconds. It is important to use servos with a high slew rate, otherwise the control loop will become unstable.

 

[Derek]

What I see as the biggest challenge will be the actuators. Will you use proportional output or bang-bang? They need to operate almost instantaneously, and can't have any "slop" (lash) or overshoot. The rate of response can be dealt with in part by the software. One interesting solution might be some kind of piezoelectric fin tab.

I think modern digital servos can do this. Look at what 3d pilots can do with rc helis and planes.

 

[Derek]

I bought one of these boards to work on a project like this:

https://www.rctimer.com/index.php?gOo=goods_details.dwt&goodsid=765&productname=

It is kind of overkill for this project, but I got a pretty good deal on it. It is basically a arduino mega with a 10 dof imu. (3 x accel, gyro and compass plus barometer). The main reason I like it is because it has this (overpriced) add on board:

https://www.goodluckbuy.com/crius-all-in-one-pro-extend-board-lea-6h-gps-xbee-adapter.html

I am hoping to integrate it into me gps tracker system and this is a plug and play solution. Just write the code.

There are cheaper versions of the flight computer with regular arduinos on board. Ultimately this might be a better solution once I get it worked out and design a gps/xbee radio extension board for it.

The biggest issue with boards like these is they are designed to operate on 5v so they won't run on a 1s lipo.

 

[jadebox]

No, it isn't. When a plane is in level flight, it's being held up by lift and an accelerometer reads 1g from the reaction to the lift force, just as an accelerometer reads 1g sitting on a table.
You could try reading https://en.wikipedia.org/wiki/Proper_acceleration but it's not that clearly written.

But, how would you know that the plane was in level flight? That's the point I think. As the Wikipedia article states, the accelerometer aboard the aircraft reads acceleration relative to free-fall. The reason you feel 1G in a plane flying level (or in a 1G barrel roll, for example) is that the lift is keeping the aircraft from following a true free-fall trajectory in just the right way to produce 1G of acceleration in the "down" direction. The accelerometer, by itself, could not be used to determine which way is really down to the earth. You'd have to have some external reference or something that integrated all the changes in acceleration from a reference point.

-- Roger

 

[mikec]

But, how would you know that the plane was in level flight?

We're talking about the ArduIMU drift correction algorithm. All I am saying is that accelerometers are not useless in planes, just potentially confusing. I think ArduIMU uses heuristics based on gyro and accelerometer data to determine if flight is level, but I'm not that familiar with the code and as mentioned, it's not relevant for rockets anyway.

 

[DaveHein]

So far my guidance algorithm is looking something like this:

Angle_motor = d Velocity_angular + p Displacement_angular

I haven't done all the math, but anyone have any ballpark guesses for d and p (not actual numbers, but the ratio between them)? The wikipedia page on control loops recommends making the proportional term the largest.

For the Quad Pod II, I used p = -1. That is, if the rocket rotated one way I would rotate the motor that same amount the other way. This essentially kept the motor vertical at all times. This worked because I had the motor mounted above the Cg. For a more conventional rocket the motor will be below the Cg, so p would have a value of 1 instead. With a value of 1, the motor will have twice the angle of the rocket relative to vertical. So if the rocket it tilted by 5 degrees, the motor would be tilted by 10 degrees. At least that ratio worked OK for me.

The angular velocity term is used to provide some damping to prevent oscillation. Let's say the rocket was tilted by 5 degrees, with an angular velocity of zero. The motor will be tilted to bring the angle back to zero, but when it reaches an angle of zero it will have a negative angular velocity. The velocity term should be used to bring the angular velocity back to zero, so d should be a positive value also. I'll have to look at my code to figure out what value I used.

 

[DaveHein]

I looked at my source code for Quad Pod II, and it looks like I used a value of 0.01 for d. That seems a bit low, but it did improve the stability compared to my earlier tests where I didn't include any damping.

 

[Joe Walsh]

What I see as the biggest challenge will be the actuators. Will you use proportional output or bang-bang?

The plan all along was to use aircraft servos. After your warnings, I'm starting to see how servos might chew beyond my budget's borders. Starting this project I was sure that perfection wasn't one of the possible outcomes. I'm not yet convinced the same holds for success.

It is important to use servos with a high slew rate, otherwise the control loop will become unstable.

Thanks for the heads up about slew rate. I hadn't even heard the term before reading your post. Isn't slew rate wrapped up in the servo speed calculation? I would expect that any servo rated at 4.8v/0.05s/60° would achieve that speed, regardless of slew rate in the internal electronics.

I looked at my source code for Quad Pod II, and it looks like I used a value of 0.01 for d. That seems a bit low, but it did improve the stability compared to my earlier tests where I didn't include any damping.

That does seem a bit low. I had planned to ignore anything much under 5%, because I'm expecting around 5% slop in the servo-to-motor connections. I guess I'll know after some live tests.

 

[DaveHein]

I looked at my code some more to decipher what I did 5 years ago. The code is written in assembly for an 8-bit processor, so it wasn't immediately obvious what I was doing. I was able to reduce it down to the following pseudo-code:

void UpdateServo()
{
    sample = GetSample();                     // Get the raw angular velocity from the gyro
    velocity = sample - average;              // Remove the DC bias to compensate for drift
    vel_filt = (0.75 * vel_filt) + velocity;  // Filter the angular velocity
    angle += velocity;                        // Integrate the angular velocity to get the position
    servo_pulse = scale * (angle + vel_filt); // Compute the pulse width for the servo
}

The samples from the gyro were a bit noisy, so I filtered the velocity samples. I used a filtering coefficient of 0.75, which produced a gain of 4 for the vel_filt values versus the velocity values. In my earlier post I said I used a damping coefficient of 0.01. I quoted a value of 0.01 because I was sampling at 100 samples/second. Because of the gain of 4 in my velocity filter, the coefficient should actually be 0.04. If the sample rate was changed, the damping coefficient would need to be scaled accordingly to have the same effect.

BTW, the "average" value was determined during the time the rocket sat on the pad waiting to launch. I used a magnetic relay to detect when the launch was occurring. At that point I quit updating the average value, and began actively controlling the servos.

 

[Joe Walsh]

Your project is a real inspiration, Dave. Thanks for sharing.

I see that you didn't mount your gyros at the center of mass. The RC people swear up and down that you have to place the gyro very near the CG for things to work right. But nobody seems to care to express why. For example, this page (https://z8rc.com/2013/01/installing-a-3-axis-gyro-in-an-airplane/) offers the supremely unhelpful explanation that "The ideal mounting location for a 3-Axis Gyro is at the aircraft CG, since airborne motion rotates about the CG." And then Albert Helfrick, on page 359 of his book "Principles of Avionics," writes simply "The gyro performs best when mounted near the center of gravity of the aircraft." Even the B-17 had the autopilot gyros mounted at the CG.

Did you perform any translation of your gyro values from their actual position to the real CG? If so, why is this necessary?

What is unknown (to me) is how any of these units react to large accelerations.

That's a good question. They physically stressed the unit to 3kg without affecting the output (https://www.adafruit.com/datasheets/STMEMS.pdf#page=26). That's not the same as a high acceleration, but maybe there's a correlation.

This resource claims that MEMS gyros are theoretically independent of acceleration: https://www.electroiq.com/articles/stm/2010/11/introduction-to-mems-gyroscopes.html. Apparently, until you hit the flex limits of the material, you'll be fine. I don't know what the limits are, though. And the ST folks aren't using the "three tuning forks" concept anyway, rather a "beating heart" model. Good question, indeed.

If you're terribly worried about high acceleration, you might have to fork over the $50 for an ADXRS450. Its accuracy decreases by 0.03°/s for every g of acceleration (https://www.analog.com/static/imported-files/data_sheets/ADXRS450.pdf#page=3). Not bad, I'd say. You could fly at 16 g's for 10 seconds and be off by less than 5°.

 

[CarVac]

Your project is a real inspiration, Dave. Thanks for sharing.

I see that you didn't mount your gyros at the center of mass. The RC people swear up and down that you have to place the gyro very near the CG for things to work right. But nobody seems to care to express why.

That's because there's no reason why. The angular velocity of any point on a rigid body is the same, so a rate gyro mounted anywhere on the rigid body will give the same readout.

If you're terribly worried about high acceleration, you might have to fork over the $50 for an ADXRS450. Its accuracy decreases by 0.03°/s for every g of acceleration (https://www.analog.com/static/imported-files/data_sheets/ADXRS450.pdf#page=3). Not bad, I'd say. You could fly at 16 g's for 10 seconds and be off by less than 5°.

Ten seconds of integration of nearly any MEMS rate gyro will easily yield 5 degrees of drift, whether it's experiencing acceleration or not.

 

[jderimig]

Ten seconds of integration of nearly any MEMS rate gyro will easily yield 5 degrees of drift, whether it's experiencing acceleration or not.

They have gotten better in that regard. Like I said in an earlier post, I have a ST L3GD20 running a DCM algorithm and I get 1 degree drift after 20 seconds of integration. Some samples (from an ArduImu I got) took a full minute before 1 degree of drift was accumulated. The key is to get a good zero before you start the integration.

 

[TALON]

VERY interesting thread & cool From a 12 year old kid in 1967 to my current BAR days now it has always interested me in how to build/fly a scale rocket, i.e. Gemini Titan & Saturn V with out fins (clear plastic).:eyepop: Since I became a BAR, I have fantasized building V-2 w/ gyro controlled vanes like the real thing.:y: Now I must say that I haven't even progressed passed the low power rockets (yet) I am still flying BP, Ds & Es, but that hasn't stopped me from dreaming, so imagine that this would take the skill set of a L3 and would need to be a big rocket:jaw: Hope this isn't too far off topic, just wanted to share my madness :dark:

 

[jderimig]

I have fantasized building V-2 w/ gyro controlled vanes like the real thing.:y:

Good thing Sparkfun wasn't around when VanBraun was designing the V2.

 

[Joe Walsh]

Launch video:
[video=vimeo;74696290]https://vimeo.com/74696290[/video]

The project was managed here: https://trello.com/b/cjrC6GHw/fx3-project

Many thanks to Dave Hein for readily sharing his project. The stabilization of a rocket from the bottom end turned out to be hugely more subtle than Dave's project, but the internal workings of the Quad Pod were a welcome confirmation of my early thoughts on the guidance algorithm. Thanks, Dave.

Thanks to awseiger, who once wrote me "you want to be troubleshooting your control system, not your integration/derivation." Replacing "integration/derivation" with "xyz" saved me from many a dumb decision during the project. I probably took it too far: I purposely did not include a recovery system for the rocket because of this maxim. It would have been just another thing to go wrong.

Thanks to everyone for their interest. Our previous project (failed: guidance motor never lit) shows what happens to unguided finless rockets:
[video=youtube;4OQ44lfE5sQ]https://www.youtube.com/watch?v=4OQ44lfE5sQ[/video].

 

[awseiger]

Launch video:
Video Link: https://vimeo.com/74696290

The project was managed here: https://trello.com/b/cjrC6GHw/fx3-project

Many thanks to Dave Hein for readily sharing his project. The stabilization of a rocket from the bottom end turned out to be hugely more subtle than Dave's project, but the internal workings of the Quad Pod were a welcome confirmation of my early thoughts on the guidance algorithm. Thanks, Dave.

Thanks to awseiger, who once wrote me "you want to be troubleshooting your control system, not your integration/derivation." Replacing "integration/derivation" with "xyz" saved me from many a dumb decision during the project. I probably took it too far: I purposely did not include a recovery system for the rocket because of this maxim. It would have been just another thing to go wrong.

Thanks to everyone for their interest. Our previous project (failed: guidance motor never lit) shows what happens to unguided finless rockets:
YouTube Link: https://www.youtube.com/watch?v=4OQ44lfE5sQ.

Thanks for the honorable mention! I gotta say, that launch was WAY TOO COOL. Wow!

 

[DaveHein]

Joe,

Very nice! I like the gimbal mechanism you built. Can you provide more details about it, like what materials you used, and how you attached it to the servos. It looks like the servo linkage could be little springy, which could cause problems if significant force was needed to position the motor. More pictures would be nice.

What was the mass of your rocket? It seemed to rise quite a bit faster than 1G of acceleration, which I thought was your goal. I noticed a little bit of oscillation as the rocket ascended, but it wasn't too bad. How much damping did you use in your control loop?

Your launch pad was interesting. Had you considered just using a very short launch rod, like maybe 6 inches long, just to hold the rocket vertical until it was under thrust?

Are you planning on rebuilding your rocket and adding a parachute? I never used a chute on the Quad Pod, but then it was intended to land under thrust just as the motor burned out. However, minor differences in impulse between motors would make the Quad Pod go up 20 feet and land after just a few seconds, or hover at 35 feet and then crash when the motor burned out, which is what it did on it's last flight.

Congratulations on a good flight. I hope to see more in the future.

Dave

 

[Joe Walsh]

Thanks Dave, I'm very happy to hear you liked it!

The gimbal was a very amateur construction. The gimbal rings are simply short lengths of PVC pipe. The servo rods attach to control horns stolen from an R/C plane kit. The struts between the rings are cut from 8mm kabob stick. Surprisingly, the final assembly with the servo rods had almost no slop.

At launch the rocket weighed 794 grams. The purpose of the hold-downs was to delay liftoff until after the large thrust spike on the F10 (also the reason that I didn't just use a short launch rod). Theoretically that would cause a 1/4th G acceleration, but the liftoff still looks fast. I don't think the motors burn evenly enough to support going to 1/8th or 1/10th G accelerations.

The control loop was a simple PD control loop. I didn't damp either the P or the D term, although I'm sure that the gyroscope unit did some damping on its own already. Some damping may help the oscillation. Or adding the I term to the controller.

There are many parts of the project that need to be extended, and first on the list is the addition of a recovery system. School started again on Monday; there will be more launches coming, but probably not for a while.

Thanks again for your interest and willingness to help,

-Joe

 

[DaveHein]

I watched your launch video a few more times, and the acceleration does appear to be less than 1G. I think the first couple of times I watched it I thought it was playing in slow motion. I like the way you built the gimbal out of PVC pipe. I think I'll give that a try.

I looked at the pictures you have on your project website, and noticed that you built a static test rig. Do you have any videos of your static tests?

EDIT: I found your static test videos on your Vimeo site. That must have been exciting when the rocket broke free of the static test rig. The fact that it continued to go up instead of sideways is a good testament to your active control mechanism.

 

[Joe Walsh]

Your initial feeling was correct: the footage of the launch is played back at half speed (except the camera on the pad, which plays back at 1/4th). Perhaps the rocket did simply take off really fast. Maybe we didn't wait long enough to get past the initial thrust spike.

The static test was exciting and embarrassing. I over-simplified the test stand in an effort to save money. As you might have seen on the project page, it was originally supposed to look like this:

The project ended up costing around $100. In hindsight, a little extra spent on the test stand wouldn't have been too tragic and would have prevented the breakout.

The test was run with just the P term in the control loop. Although it oscillated wildly after breaking free, the oscillations did not appear to be diverging. They weren't converging either, but that gave me confidence that the final launch would be stable.

 

[rasciodc]

Hi!

I'm an aerospace engineering student and I've been launching rockets for a while. I've just started looking for ways to stabilize/control my rockets and I came across this:
https://github.com/vshymanskyy/GY80
to be used with this ("10" DOF):
https://dx.com/p/gy-80-bmp085-9-axis-magnetic-acceleration-gyroscope-module-for-arduino-145912 (and of course, the arduino)

I guess that would be a straight forward and cheap way to go... The code as it is right now outputs yaw, roll and pitch angles and compensates yaw gyro drifting using the compass magnetic heading. More coding needs to be written to use these angles and send signals to control surfaces/gymbals.

You guys think this configuration/coding has a future or is worth working on? Or is it better buy an IMU from SparFun, which is already supported by this:
https://github.com/ptrbrtz/razor-9dof-ahrs
and then just worry about the "controlling" issue?

I'm really not sure because, if you look the codes from the 2 websites, they are the same... The guy just adapted the code written for the SparkFun devices to use with the cheap GY80....

 

[bobkrech]

Hi!

I'm an aerospace engineering student and I've been launching rockets for a while. I've just started looking for ways to stabilize/control my rockets and I came across this:
https://github.com/vshymanskyy/GY80
to be used with this ("10" DOF):
https://dx.com/p/gy-80-bmp085-9-axis-magnetic-acceleration-gyroscope-module-for-arduino-145912 (and of course, the arduino)

I guess that would be a straight forward and cheap way to go... The code as it is right now outputs yaw, roll and pitch angles and compensates yaw gyro drifting using the compass magnetic heading. More coding needs to be written to use these angles and send signals to control surfaces/gymbals.

You guys think this configuration/coding has a future or is worth working on? Or is it better buy an IMU from SparFun, which is already supported by this:
https://github.com/ptrbrtz/razor-9dof-ahrs
and then just worry about the "controlling" issue?

I'm really not sure because, if you look the codes from the 2 websites, they are the same... The guy just adapted the code written for the SparkFun devices to use with the cheap GY80....

Neither one will work if your rocket has more than a 16 G acceleration unless you add an accelerometer with a lower sensitivity.

Bob

 

[rasciodc]

Would that be the only problem?
Either way, have you ever seen this project?
https://github.com/zortness/rocket-mega-shield
It's pretty complete and includes a second accelerometer for high G's. Right now it is ready for telemetry, logging, deployment etc.... I'm in contact with the author and he says it's possible to implement a controlling function to the board as it has a few available pins to attach servos and stuff.