Hello to everyone on here!  You guys can thank Monroe for getting me involved with this project, he and I have been friends for quite a while now and we think a lot alike.  To make a long story short, we are working on a guided rocket project and the option that made the most sense was to use the APM hardware as the main flight controller since it was essentially usable as-is off the shelf.  However, the code leaves something to be desired.

I have only been working with it for about a week, but I have created what is essentially a pared-down version of ArduPlane 2.50 with large chunks of unnecessary code removed.  Mainly we are interested in active stabilization and simple guidance (as in fly straight up).  Eventually for something like a suborbital or orbital space shot we would need logic to fly a programmed flight path.  However, that still leaves a lot of the Arduplane code as unnecessary, stuff like:

-throttle control

-waypoints

-failsafe logic (how are you going to have a rocket circle or return to the launch site?)

I got to the point where the remaining code actually compiles without errors.  The really big gaps in the code are now the pitch and roll controllers.  The existing airplane based code is not suitable for rocket applications at all.  I'm trying to find Jon Challinger's new routines but I'm not sure where to start looking.  I'm aware that due to the wide speed range inherent in rocket flight none of the existing control routines may be suitable, leaving us with developing our own.  It's been a while since I took my control systems theory courses but I'm prepared to do that if necessary.

The hardware we are planning on building will be a modification to an existing high power rocket (G-H-I power) to add a guidance section in the payload bay at the nose.  The guidance section will contain the APM, RC receiver, standard rocket altimeter/parachute deployment controller, 2M APRS tracker, cameras, and two servos with canard fins.  Essentially to the APM it will be elevon mode, with the control directions reversed since the fins will be in front of the CG.  The rocket will have passive stability and the purpose of the guidance is just to make sure it goes absolutely straight up regardless of winds.  This is a common problem with rockets and becomes particularly acute with higher performance flights.  A small initial deviation from vertical grows over time.  For things like (A) setting altitude records and (B) not chasing rockets for miles downrange, it's advantageous to ensure it will always go straight up.  The APM will also provide a whole bunch of useful functions, some of which are available in current technology rocket flight computers and some of which aren't.  Things like data logging of accelerometer and GPS data can be done with currently available off the shelf parts, but none of them provide real time telemetry with a ground station.

The long term capability exists for ArduRocket to become its own full-featured vehicle platform for amateur and even professional rocketry.  Currently, rocket hobbyists have to buy a melange of altimeters, timers, radios, trackers and other hardware to get capabilities that could easily be exceeded by what one APM can do.  Also, the possibility of being able to do active stabilization is tantalizing, since there are many full-scale rockets that aren't passively stable and can't be done as a scale model without doing things like adding transparent fins as a crutch.

For anyone who's interested in helping, we will be open sourcing the code.  I have lots of experience coding in general but I'm still trying to get up to speed on the APM hardware and ArduPlane software.  Immediately, the main thing standing in the way of having usable code that we can start ground testing is the lack of the pitch and roll control functions.

Stew

Tags: ArduRocket

Views: 2877

Reply to This

Replies to This Discussion

You could also base your stuff on ArduCopter instead of ArduPlane...that's what I would do although it's mostly because i'm more familiar with the ArduCopter code.  One small advantage is that it's got the AP_Motors class which could be helpful in that it separates the mixing of the output to the servos from the main code base.

 

Guided rockets!  wow.  If you're too successful you will definitely make some people nervous.

Randy,

Yes, now that I'm at least somewhat familiar with the ArduPlane code I need to spend some time comparing to ArduCopter, so that I can understand what's different.  As you say, separating the output mixing would be a good thing.  We will only have 2 canard fins, each on its own servo, so it acts just like elevons.  The only way to control the other axis is by rolling the vehicle.

And yes, I figure there's a chance some people might get nervous about this whole idea.  I think most people don't realize how advanced the existing hobbyist-level UAV technology is and how much mayhem could already be committed with it.  Some months back Monroe was describing to be all about this "DIY Drones" thing and I was absolutely floored.  Once some idiot does something stupid we will all have to live with the consequences.  The key as hobbyists and amateurs is to act responsibly and make sure there's no opportunity for problems.  For Monroe and I it's a little easier since I live on a farm and we have our own flying field, we don't have to get anyone's permission and there are no housing developments nearby to get concerned about objects whizzing over their heads.  For higher performance flights, Monroe owns land on the Texas coast, so we have options.

Oh yes, and we do intend to be successful....  www.teamprometheus.com

Stew

Hi Stewart,
What are you going to do about the accelerometers during the initial takeoff? I suspect the rocket will saturate them. That will throw off the attitude estimate from DCM.
You'll also need quite different code for the speed. I suspect the barometer is your best bet. That will need to be fed into the speed scaling used for the surfaces.
Cheers, Tridge

Tridge,

Very good points you bring up, these are exactly the things I need to know about.  What is the G range for the accelerometers?  We have both APM1 and APM2 units to test with.  The orientation of the APM in the vehicle is more plane-like than copter-like, in other words, the long direction of the board will be aligned with the long axis of the rocket.  This is mainly because the rocket I already I have is 2.6" diameter and the APM won't fit any other way.  Monroe brought up the saturation point to me too and mentioned that we may need to use physical gyros or FOG's instead.  Once we have the payload section built we will make a few flights with the APM as a passenger and the canard fins removed so we can see what it would have done.  Hopefully by the time we fly it live under control we'll have a good chance of it working right, or at least not cratering the rocket.

Also, I'm aware the speed scaling will be an issue.  I already removed part of that logic.  There's no way with a rocket to know ahead of time exactly how fast you're going to go, so you can't scale to some "maximum speed".  For our initial testing with lower performance motors it will probably reach 300 mph or so.  With higher performance motors it could go transonic.  We have the pitot-static dual pressure unit and will employ that for barometric speed sensing, we also have the Ublox GPS with 5 Hz data output.  But I'm thinking the control laws will need to be computed ahead of time and the code will have to compensate the gain according to the current airspeed.  This will require knowing quite a few parameters about the vehicle, as in moments of inertia, canard fin area and coefficient of lift vs. angle for starters.  Also, where do I go to look at Jon's improved attitude control code?  Thanks for the input.

Stew

In some places at least, adding guidance to an amateur rocket is illegal. ( as it goes from legally being a hobby device, to legally being a guided missile ) ... you don't need to have on-board explosives ( or any other deadly nasties) for it to be classified as a missile, just being guided and being rocket/impulse powered is enough.   I know of a man in NZ who had built a large (guided) pulse-jet rocket, and had the authorities involved in a bad way.*   Please check with your local authorities , or at  least do a *very* careful read of your local, state, and federal legislation before proceeding with this.

Oh, and good luck, and have fun.   We want to see a video, preferably from on-board!

Buzz

* http://www.interestingprojects.com/cruisemissile/

Buzz,

I'm glad you brought this up since I forgot that this is a worldwide community, not just us in the US.  Monroe and I are in a slightly different position than your average hobbyists/amateurs since we have the Team Prometheus banner to operate under and are more a professional organization (not for profit however).  We comply with all regulations and our mission plans will require flight plans and permission from the FAA (and possibly other agencies) to fly.  Monroe is more on top of the regulatory aspects than I am, he has already started some of the paperwork.  I suppose there is a risk that the code is too sensitive and it will get regulated as export restricted or some such.  However, there's no fundamental reason why you can't put an APM on a rocket and program it appropriately for guidance and control, I'm sure we're not the first people to think of this.  I imagine most people here realize that it makes no difference to the guidance system whatsoever whether there are astronauts on top of the rocket and the trajectory goes into orbit, or whether there is a warhead on top and the trajectory comes down somewhere on earth.  The rocket doesn't care, and technology that can be used for one can be used for the other.  But unless we forsake all technology and choose to live like primitives, eventually someone will come along and make powerful tools that could have nefarious purposes.  It's inevitable as hobbyist technology progresses that it will get easier to make weapons with it.  How different is ArduPlane from cruise missile guidance software?  It can auto takeoff and land, fly pre-programmed missions, respond to radio commands and much more.  Add a high performance vehicle and a weaponized payload and what would you have?  A poor man's cruise missile.  Eventually someone with more technical skill than good sense will figure this out and then governments everywhere will scramble to regulate what everyone on this forum is already doing.  I hope it's a long time before that happens, because if we keep the tools of the future out of the hands of the next generation of scientists, engineers, and inventors, then who's going to build the future?

OK, sorry for the soapbox, I trust that I'm preaching to the choir here on this forum.  I knew the instant we started talking about "rocket" and "guidance" in the same sentence it was going to open a can of worms.  But Monroe and I, the other members of Team Prometheus, and a whole lot of other "new space" initiative folks, both professionals, amateurs, and cheerleaders, want to pioneer new and ridiculously cheap ways to get into near-space, space, and orbit.  One of the keys to doing this is leveraging the state of the art in off the shelf technology.  Hopefully the people that make the rules will see the sense in letting us share what we do in an open source format, so that others can also build on what we do.  This is how we make progress and invent the future, something mankind definitely needs at this juncture.

Stew

P.S.  All detractors please reply in this thread with your name and lat/long coordinates....

OK, here's today's progress.  I chopped even more code out of the build and started adding new code in places.  The big item for us will be the roll/pitch/yaw stabilization routines, so I dove into that.  I removed pretty much all the existing code and wrote some new.  It looks like the existing PID control mechanism should work pretty well, with the right coefficients of course.  I was hoping that acceptable yaw control could be achieved with pitch/roll coupling the way that ArduPlane does it, but that's just not going to work for a rocket.  You can't just bank to turn.  The yaw control will need to be separate and explicit, basically just like the pitch controller only on the yaw axis.  This means that we can't just have a 2-fin canard rig, but will need 4 fins (actually 3 with suitable mixing but that's more complicated).  It's just too complicated to control 3 degrees of freedom with only 2 channels of output.  Controlling 3 with 4 is overdetermined but in this case it's much easier.  Good thing I bought those extra servos.

The initial prerelease code is version 0.1 and is now available on github at https://github.com/stew-lilley/ArduRocket.

Stew

Stew,

I am curious why you choose to use canards rather than the tail fins for the control surfaces, I recall reading somewhere so I may be remembering it wrong, that another group doing a similar thing found that canards caused a larger change in direction for a similar control movement than a adjusting a tail fin. They ended up using both, the canards were used to do major adjustments, and the tail fins were used to do the 'fine tuned' adjustments. 

Will the canards interfere with the air flow over the tail fins. 

How will you handle the changing center of mass and pressure differences as the fuel is used up.

One potential solution to the accelerometers being 'drowned' out is to use a few accelerometers with differing 'G' levels, the MPU6000 (comes with the APM) - can handle 2/4/8/16 G - so you would be able to adjust that, but you would need at minimum two of them set high enough to handle the thrust acceleration, and a much more sensitive one to handle the other 2 axis. I have seen on some rocket forums, that you can get one accelerometer that is designed for this where the 'z' axis is set for many magnitudes more 'G' than the other axis.

I thought your comment about all detractors was pretty clever ;) 

Stew,

I’m not sure that for a guided rocket device you want to be using fins to totally control the attitude.

A gimbal device on the main thrusters should allow for stabilisation on vertical flights. If the wind is strong then you might want to hold off with the launch...

The best bit with guided missiles is that they are easy to control with moving fins, but you've got to make sure that they are stable in the control loop or you might end up with some VERY big craters in your farm land! You don't need to have yaw control, just roll and pitch and you should have it sorted from there.

I'm very interested in helping out in any way :)

RSS

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service