Fly Straight Up

I'm new here. Hi everybody.

My family has been doing casual rocketry with estes kits for my entire life, but for the past year I've been bit with a bug to make a finless rocket that can still fly straight up. Last year I tried this with toy gyroscopes. Unfortunately my clustered engines suffered ignition problems, and the all-important guidance motor never ignited.

I'm preparing to try again this summer, this time with electronics. Right now I'm figuring out which boards to use: I think I'll only need two (microcontroller and IMU). For the microcontroller I thought I'd use something from the -duino family, but several posters on this forum are of the opinion that all the -duinos are way overkill. I've looked at IMUs offered by sparkfun, but I'm also considering something like Mongoose/ArduIMU/FreeIMU.

I've read these two threads (guidance Rocket Guidance). The list here is useful, but a little outside my price range.

IMUs aside, what types of microcontrollers do you folks have experience with? I've seen "PIC" mentioned here and there, but usually on posts as old as most fine wines. I can program in C, C#, Perl, and Java. I'm guessing microcontrollers which can be programmed in C would be my best bet.

My interest in this concept is mostly for cinematics; the more slowly the rocket rises the better. I appreciate your time.

Our rockets will never be able to do a "Saturn V Style" liftoff. Our hobby propellants burn way too short and ours do not have have GNC and gimbaled engines. But, it would be cool if they could.

Consider that the Saturn V weighed over 6 million pounds and the 5 engines produced 7.5 million pounds of thrust. For safety in our hobby, we prefer a 5-to-1 thrust/weight ratio, which is considerably higher.

BTW, welcome to the forum!

Greg

Thanks for the welcome Greg!

Saturn V launches are gracefully paced and would be awesome to reproduce. But you're right: the slow beauty is difficult to replicate at hobby scales.

For this project I wanted something around 2:1. As for burn time, I was planning to use Apogee F10s.

What microcontrollers did you use for your "GNC and gimbaled engines"?

Joe Walsh said:

My family has been doing casual rocketry with estes kits for my entire life, but for the past year I've been bit with a bug to make a finless rocket that can still fly straight up. Last year I tried this with toy gyroscopes. Unfortunately my clustered engines suffered ignition problems, and the all-important guidance motor never ignited.

Click to expand...

As you may have discovered, gyroscopes can be used to make a finless rocket stable, but not without some fancy electronics to support them. For an explanation, see https://www.ninfinger.org/rockets/gcsfaq.html and scroll down to the "Can I use Gyroscopes to stabilize my rocket without fins?" section.

And, be sure to visit https://www.ukrocketman.com/rocketry/gimbal.shtml to read about a similar project. His results are pretty darn cool!

-- Roger

Joe Walsh said:

... What microcontrollers did you use for your "GNC and gimbaled engines"?

Click to expand...

Sorry. I meant to say we did "not" use such equipment.

However, John Pursley did actually do this on his Vangaurd scale model rocket.

https://www.accur8.com/NARAM41_Vanguard.html

Greg

I meant to say we did "not" use such equipment.

Click to expand...

Despite the typo, I probably should have seen your meaning from context.

I got the idea to do this last March, and while waiting for school to end I researched the concept as much as I could. The UKRocketman project was fuel to the fire.

I called my project EX5 because it would have 5 E motors. The complexity of igniting so many motors was really the project's downfall. Midway through the project I discovered John Pursley's website and was astonished at how advanced his gimbal designs were in comparison with mine.

Although I would really love to do this entirely mechanically, I've given up on such a design for the time being. I'm especially convinced that recent changes in amateur electronics have made an microcontroller implementation much easier than before. For example:

Furuta Pendulum
Balancing Robot prototype
Arduino Balancing Robot

Based on these examples, arduino looks like a good platform. But all the IMUs I've seen interface using I2C, and the FreeIMU project already has code for PIC 24 and something called "NXP LPC1343 Cortex m3": https://www.varesano.net/projects/hardware/FreeIMU#lib-ports

Another question I have is about frequency. Specifically, where is the frequency bottleneck in such a system? The arduino is the slowest of the available microcontrollers, but it's still at 16 MHz. That's only a fraction of the speed available on a PIC, but at this point, wouldn't the servos be the limiting factor?

Joe Walsh said:

Another question I have is about frequency. Specifically, where is the frequency bottleneck in such a system? The arduino is the slowest of the available microcontrollers, but it's still at 16 MHz. That's only a fraction of the speed available on a PIC, but at this point, wouldn't the servos be the limiting factor?

Click to expand...

That would depend on if you use a hardware PWM ports or software driven. Most processor have one or two PWM pins, but are dependent on master clock freq. Most processors have a 16meg clock and in the case of Pic chips they use a over clocking PLL circuit to get faster clock speeds (32 and 64meg)and the timing of the PWM is based on that clock.
Always used Pic chips for my projects , a C compiler is with the free software package from Microchip, but is limited, I use assem lang. Or PBP3 to finish off my stuff.

I think you'll find this is rather tough to do... if not mildly impossible at the hobby level.

Take a look at almost any Modern Missile. You'll notice that they have 2 sets of fins. For instance, the Sidewinder missile has a rear set of fins for stability and a set of fins in the front for controlling its direction.

The Phoenix has 4 fins in the rear that determine direction, and the fins in front of it help decrease the stability of the missile so that it remains maneuverable in flight.

This is also why most Missile models require TONS of noseweight... Engineers design missiles to be unstable so that they can have them change direction quickly. They use electronics and gyroscopes to stabilize the missile using the "steering fins" We, however, want our rockets stable without this, usually.

If I were you, I'd start on making a roll stabilizing system. I'm currently working on a system right now, and it uses off-the-shelf Adafruit parts, like a 3-axis gyroscope.

At least with a roll stabilizer, your rocket will still go "up" if your electronics fail. RSO's don't like rockets that can steer usually, unless you've proven their stability.

It's an interesting problem. I'm no Aerospace engineer, but if you want, PM me and I can tell you all that I know from my experience with Roll stabilizers.

Always used Pic chips for my projects , a C compiler is with the free software package from Microchip, but is limited, I use assem lang. Or PBP3 to finish off my stuff.

Click to expand...

Thanks for this. I'll give it a look-over.

awseiger said:

This is also why most Missile models require TONS of noseweight... Engineers design missiles to be unstable so that they can have them change direction quickly. They use electronics and gyroscopes to stabilize the missile using the "steering fins" We, however, want our rockets stable without this, usually.

Click to expand...

I'd never thought of that; that's a very enlightening piece of info. I'll get in touch about your roll-stabilization experiences.

It's a bit hard to say which idea I had first: slow cinematic takeoff or finless rocket. The two are of course related. Slow takeoffs can't utilize fins. However, the resulting forward CP position is less of a problem with slow takeoffs, making fins less of a requirement. At least if your rocket doesn't start booking it later in the flight.

You need to check what the German regulations are concerning this, but I assume the German regulations are similar to the US regulations: active stabalization is ok, but any type of targeting is forbidden.

Hobby rocket motors do not have extended burntimes, and motor gimbeled guidance systems only are effective while the motor is burning. Most military missiles employ a self-contained finned maneuvering unit located forward of the CG because it will function with rapid response as long as there is forward air speed, and this type of system is better for hobby rockets, and totally doable with inexpensive mems sensors.

Bob

Sorry for the confusion: my IP is in Germany because that's where I'm currently working. I'll be back in the US in the summer, though. The other project members (my brothers) have already started construction of many of the parts. My main task is to build the guidance computer, so I thought a good place to start would be by researching a good microcontroller. I already own a netduino and a raspberry pi. The netduino runs C# on a 48MHz ARM7, but it's a $60 board (with ethernet, no less). I'd rather plow something a little cheaper into the ground. The pi is a total power hog and is really only good for testing the principle, if that.

I've decided to move ahead with the arduino. PIC microcontrollers offer modest price advantages and significant performance increases. However, what I'm hearing here is that the servos are the real bottleneck in the system. I believe that gives me freedom to choose a board based on ease of use, and with the massive arduino community and the freely-available libraries for servos and IMUs, arduino wins out.

Thanks for all your help. I'll post back once the project has some interesting developments.

Please keep us updated. This is something I'm also interested in trying.

My first attempt will probably be to put a rc heli gyro in the rocket with one servo. I already have the gyro so it should be mostly plug and play. I may need to create a fake servo input to get the gyro to work, though. I haven't tried that yet.

https://www.sparkfun.com/categories/23 is a good source of IMUs and CPUs.

Bob

Has anyone looked at using the control boards from multi copters? Seems to me most of the work is already done, save adapting the motor outputs to what ever control you would use on the rocket.

I cannot afford to investigate it at this time.


Richard

The controls problem is a bit different. In a quatrotor you change the power delivered to the motors to maneuver the quadrotor. For a rocket you need servos to pivot fins. The controlled hardware is quite different as are the control loop time constants.

Bob

TheTellurian said:

Has anyone looked at using the control boards from multi copters? Seems to me most of the work is already done, save adapting the motor outputs to what ever control you would use on the rocket.

I cannot afford to investigate it at this time.

Richard

Click to expand...

The inertial measurment units are available at sparkfun. They contain a 3-axis gyro, accelerometer, and magnetometer. They also contain a microprocessor which takes all the data and tells you the vector components of position, velocity, and acceleration. These units are ideal for pocket stabilization... With one catch. It's very easy to overload the 5g accelerometers with a normal rocket flight... But if you're actively stabilizing the idea is to go slow, so this may not be an issue.

They're also very expensive...

that's why I'm going to start with the heli gyro first. they are optimized for exactly what we are trying to do and can do it over crazy rates. just look at some rc heli videos on youtube...

for example, watch this:

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

you can see the extreme yaw rates the gyro has to deal with starting around 1:25. I don't know about your rockets, but mine don't spin anywhere near that fast.

bobkrech said:

https://www.sparkfun.com/categories/23 is a good source of IMUs and CPUs.

Bob

Click to expand...

Sparkfun is probably where I'll end up buying my stuff, but I'm a little mad at them for being misleading. If you read their product descriptions, all their IMUs come with "DMP" or "Fusion" or some other onboard processing that handles signal calibration and filtering. At least that's what you would get if you're somebody like Nintendo. From reading around I've ascertained that the API given to non-licensees is so obscure as to be unusable, but if anybody knows contrary then I would love to hear about it.

I was able to find three basic options for hobbyist IMUs, all of them based on arduino:

The FreeIMU project: (https://www.varesano.net/projects/hardware/FreeIMU). Unfortunately, getting a FreeIMU chip is probably going to be impossible: the guy who made them was killed by a heart attack in December.

Then there's the ArduIMU (https://store.diydrones.com/ArduIMU_V3_p/kt-arduimu-30.htm). This chip was designed to calculate orientation and position solutions and is pretty slow (site says ~8hz). It outputs the final attitude and position, but not the intermediate steps in the integration (i.e angular velocities). Which leads me to ask: is taking the derivative of a position more accurate than integrating a velocity? Or does it not much matter?

Then there's Mongoose IMU (https://store.ckdevices.com/products/Mongoose-9DoF-IMU-with-Barometric-Pressure-Sensor-.html) it's the most expensive of the IMUs, but my general feeling is that it's much more accurate than the other two. Perhaps someone has experience with this and can verify?

If I give up my dream of a dedicated IMU, I could perform all the necessary maths on the microcontroller. This will of course slow down the speed of the control loop. For this concept there's the following resources:

Jeff Rowberg's I2CDevLib project (https://www.i2cdevlib.com/devices) handles interfacing with several popular gyro and accelerometer units.

The FreeIMU library can also be run on an arduino with the appropriate sensors plugged in. That's what the FreeIMU board was itself, anyway.

Sebastian Madgwick and Robert Mayhony wrote filtering algorithms which are simpler and faster (albeit less accurate) than the ubiquitous Kalman. Implementations of which are available here: https://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/

Also based on the Madgwick algorithm is this filter: https://mbed.org/cookbook/IMU.

I looked into the quadcopter boards. Unfortunately, the commercial ones are all integrated with the motor hardware. There are people using arduinos to make quadcopters, but their blogs tell of blind stumblings through the mazes of the IMU world, trying multiple IMUs and liking none of them (https://blog.mobileapes.com/2010_05_01_archive.html)

bobkrech said:

The controls problem is a bit different. In a quatrotor you change the power delivered to the motors to maneuver the quadrotor. For a rocket you need servos to pivot fins. The controlled hardware is quite different as are the control loop time constants.

Bob

Click to expand...

I use a servo tester to bench test my motor controls [ESC] so assumed the signal was identical for motors or servos. If you could clear up my confusion [in layman's terms] I would appreciate it. I don't know much about multis other than some require seperate ESCs to adapt to differing motors or so I thought.

Thank you for your patience

Richard

I was primarily talking about the controls software time constants. In a quadrotor, motor thrust controls both lift and directional stability whereas in a fixed wing aircraft, directional control is maintained by the rudder, elevator and alerons wheres the lift is controlled by the thrust. You have to prevent the surfaces from stalling so control inputs may have to be dynamically controlled.

In a rocket guidance package, the simplest control system is 2 servos connected to perpendicular opposed fin pairs, and is usually located in a forward canard location. The simplest control system would be to couple an x-y accelerometer pair to zero out the x and y axis tilts. It is easy to check as well by simply tilting the airframe: as the airframe tilts, the fins stay vertical. This control system will attempt to keep the rocket vertical throughout it's ascent.

Bob

I've decided to make the IMU with an Arduino nano and a GY-521 (breakout for the MPU-6050). Cost me about $25.



I'm using the code from Jeff Rowberg: https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050
It uses a concept called "sensor fusion" to calculate attitudes.

There are some problems with these MEMS sensors: the accelerometers jitter and the gyros drift. But accelerometers don't drift (long term), and the gyros don't jitter. The accelerometer senses the acceleration due to gravity when it's resting on a surface. So sensor fusion uses the accelerometer to remove drift from the gyro. This doesn't work for yaw (rotation around the vertical axis. In our field I think that's usually referred to as "roll"). You can use a magnetometer (which, like the accelerometer, jitters but doesn't drift) to correct gyro drift in yaw.

That's the basic idea. But as soon as you put the accelerometer in a flying object, it can't detect gravity anymore because it's in freefall. This is my understanding, anyway. However, if I've understood this correctly, then projects like the ArduIMU shouldn't be able to detect the direction of gravity relative to an RC plane. The accelerometer would only detect the acceleration due to lift from the wing, changes in thrust, and drag. I read the paper on the ArduIMU development: https://gentlenav.googlecode.com/files/DCMDraft2.pdf

They talk about losing the gravity reference when the plane flies a ballistic arc, but they don't mention my perceived freefall issue. Perhaps somebody knows how the accelerometer manages to detect gravity while in flight?

Joe Walsh said:

Perhaps somebody knows how the accelerometer manages to detect gravity while in flight?

Click to expand...

It doesn't, which is why the whole drift correction method method outlined in that web site doesn't apply to rockets.

The good news is that you only need to control the rocket for a few seconds, and the gyros may not drift enough to matter in that time.

You're going to need some kind of Kalman filter to smooth out your accelerometer and gyro data, or the noise will make your IMU keep overcorrecting. Better to take fewer samples with a filter than a lot without one.

Joe Walsh said:

I've decided to make the IMU with an Arduino nano and a GY-521 (breakout for the MPU-6050). Cost me about $25.

View attachment 131639

I'm using the code from Jeff Rowberg: https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050
It uses a concept called "sensor fusion" to calculate attitudes.

There are some problems with these MEMS sensors: the accelerometers jitter and the gyros drift. But accelerometers don't drift (long term), and the gyros don't jitter. The accelerometer senses the acceleration due to gravity when it's resting on a surface. So sensor fusion uses the accelerometer to remove drift from the gyro. This doesn't work for yaw (rotation around the vertical axis. In our field I think that's usually referred to as "roll"). You can use a magnetometer (which, like the accelerometer, jitters but doesn't drift) to correct gyro drift in yaw.

That's the basic idea. But as soon as you put the accelerometer in a flying object, it can't detect gravity anymore because it's in freefall. This is my understanding, anyway. However, if I've understood this correctly, then projects like the ArduIMU shouldn't be able to detect the direction of gravity relative to an RC plane. The accelerometer would only detect the acceleration due to lift from the wing, changes in thrust, and drag. I read the paper on the ArduIMU development: https://gentlenav.googlecode.com/files/DCMDraft2.pdf

They talk about losing the gravity reference when the plane flies a ballistic arc, but they don't mention my perceived freefall issue. Perhaps somebody knows how the accelerometer manages to detect gravity while in flight?

Click to expand...

mikec said:

It doesn't, which is why the whole drift correction method method outlined in that web site doesn't apply to rockets.

Click to expand...

That's what I thought. And I think you're right: the short control time means the gyro drift shouldn't be a problem.

I still don't see how the ArduIMU can detect gravity while in flight, but I guess I don't need to. I'm not trying to fly a plane.

Joe Walsh said:

I've decided to make the IMU with an Arduino nano and a GY-521 (breakout for the MPU-6050). Cost me about $25.

View attachment 131639

I'm using the code from Jeff Rowberg: https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050
It uses a concept called "sensor fusion" to calculate attitudes.

There are some problems with these MEMS sensors: the accelerometers jitter and the gyros drift. But accelerometers don't drift (long term), and the gyros don't jitter. The accelerometer senses the acceleration due to gravity when it's resting on a surface. So sensor fusion uses the accelerometer to remove drift from the gyro. This doesn't work for yaw (rotation around the vertical axis. In our field I think that's usually referred to as "roll"). You can use a magnetometer (which, like the accelerometer, jitters but doesn't drift) to correct gyro drift in yaw.

That's the basic idea. But as soon as you put the accelerometer in a flying object, it can't detect gravity anymore because it's in freefall. This is my understanding, anyway. However, if I've understood this correctly, then projects like the ArduIMU shouldn't be able to detect the direction of gravity relative to an RC plane. The accelerometer would only detect the acceleration due to lift from the wing, changes in thrust, and drag. I read the paper on the ArduIMU development: https://gentlenav.googlecode.com/files/DCMDraft2.pdf

They talk about losing the gravity reference when the plane flies a ballistic arc, but they don't mention my perceived freefall issue. Perhaps somebody knows how the accelerometer manages to detect gravity while in flight?

Click to expand...

With respect to use in rockets, accelerometers do drift. The rocket is effectively in free"fall" the entire flight (aside from burnout) with only aerodynamic forces detectable by the accelerometers, so you really cannot use them to "remove drift" from the gyro.

cerving said:

You're going to need some kind of Kalman filter to smooth out your accelerometer and gyro data, or the noise will make your IMU keep overcorrecting.

Click to expand...

Jeff managed to reverse engineer most of the motion processing functionality that's built into the MPU-6050. It's pretty dang smooth at 200Hz (±0.02° jitter), with very little delay (looks like around 0.1 seconds before readings match actual). Quite impressive work he did there.



For the raw gyro values, I tried a really simple filter. I took 98% of the previous reading and added 2% of the current reading to it. At 200 readings per second, it also gets down to around ±0.02° jitter, but has much worse lag. Nice thing is I can adjust the weights to make a tradeoff between jitter and lag.

The fastest servos I found can do 60° sweep in 0.05 seconds. That means I can update 20 times a second and still reach anywhere inside the 60° cone, and each servo command would have 10 readings in between it and the previous command. I actually found some servos that can do the 60° in 0.03 seconds, but their power consumption to deliver the torque I need starts to bump into the weight constraints for the batteries.

Joe Walsh said:

I still don't see how the ArduIMU can detect gravity while in flight, but I guess I don't need to. I'm not trying to fly a plane.

Click to expand...

Planes aren't usually in free fall (try walking in an airliner, works fine). That's essentially how ArduIMU drift correction works in level flight.

Weighted average filters (the 98%/2%) work great if the samples aren't expected to vary too much over a short sample period. In this case, that should be true, especially at 200 samples/sec; at 20 samples/sec you might see a bit more lag, especially if you get into an oscillatory mode. You're probably going to want to kick up the real-time percentage, maybe to 5%. The nice thing about this is that it's pretty easy to bench-test, you shake your IMU sled around a bit and see how the data compares with different percentage values.

Joe Walsh said:

Jeff managed to reverse engineer most of the motion processing functionality that's built into the MPU-6050. It's pretty dang smooth at 200Hz (±0.02° jitter), with very little delay (looks like around 0.1 seconds before readings match actual). Quite impressive work he did there.

View attachment 131651

For the raw gyro values, I tried a really simple filter. I took 98% of the previous reading and added 2% of the current reading to it. At 200 readings per second, it also gets down to around ±0.02° jitter, but has much worse lag. Nice thing is I can adjust the weights to make a tradeoff between jitter and lag.

The fastest servos I found can do 60° sweep in 0.05 seconds. That means I can update 20 times a second and still reach anywhere inside the 60° cone, and each servo command would have 10 readings in between it and the previous command. I actually found some servos that can do the 60° in 0.03 seconds, but their power consumption to deliver the torque I need starts to bump into the weight constraints for the batteries.

Click to expand...

mikec said:

Planes aren't usually in free fall (try walking in an airliner, works fine). That's essentially how ArduIMU drift correction works in level flight.

Click to expand...

Here's my understanding of the situation. A plane stays airborne because of the lift from the wing. Lift from the wing always points in the same direction, regardless of the orientation of the plane. If the plane was upside down and there weren't any inputs to the elevator to keep it level, the plane's path would describe an arc and you'd still be able to walk down the aisle just fine. If the plane rolled 90° on its side (and no rudder input), it would be in freefall in the wing axis (the axis that now points through the center of the earth). But you'd still be able walk down the aisle, because the lift from the wing will still cause an acceleration.

I suppose I should take this to physicsforums or something and see what they think.

cerving said:

You're probably going to want to kick up the real-time percentage, maybe to 5%.

Click to expand...

Thanks for the tips. I was planning to implement a PD control loop, using both angular displacement and angular velocity. You wouldn't happen to also know what percentage weights I should use for the proportional (displacement) part and derivative (velocity) part?

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.