hey again all! I thought it would be cool to have a dedicated thread for guys who build bigger hex and octocopters with apm where we can share tips and advice regarding tech specs, builds, code, firmware and whatever else comes up.
Firstly, how many of you are building bigger AP rigs with APM? We've been building all our commercial SteadiDrone RTF kits with APM with great results.
so, who else is out there, lets get chatting.
Tags:

There was some discussion on rcgroups regarding the DJI WKM autopilot. The setup procedure for that autopilot wants you to specify the IMU position offset in relation to CoG. A couple of us where wondering if maybe it would make more sense to specify the IMU's relation to CoR instead (center between propellers). And pretty quickly the discussion went out of hand as it usually does in forums, with people more or less claiming to be NASA engineers and stating that CoG is all that matters, or that CoR is always the same as CoG.. A lot of that did not make sense to me, so I just wanted your input.
Permalink Reply by Brad Hughey on July 23, 2012 at 6:32pm A CoG away from the CoR represents an "inertial counter-torque" of sorts, which adds a delay in system response as well as requiring a damping counter-force to achieve stasis again. Paul Pounds has found that having a CoG above the rotor plane aids response time, while having one below makes things more sluggish. While they are two distinctly separate quantities, perhaps I was misleading when I stated they were not related; a good design does take them both into account.
However, from a sensor mounting standpoint, you have two sets of three-dimensional sensors in the usual IMU topology. The gyros sense rotation, while the accelerometers sense movement. It stands to reason that If you mount the inertial array at a point other than equidistant from the prop centers, which presumably is nearest to where the control axes intersect, then there will be an error generated showing a lateral velocity vector magnitude when, in fact, there was only roll, pitch, or yaw rotation. There are engineers in these hallowed forums far more qualified to speak to the specifics of that than I am, but that's the general idea. It sounds as if DJI wants a guess as to how large this error might be from the onset to help trim itself faster.
There's an old joke. What you call the person who graduates at the very bottom of their class from medical school? Doctor.
The same is true for NASA engineers. They've hired some geniuses and some...not so much.

The question then becomes, how can they do IMU corrections by asking for the IMU's CoG offset, since the CoG may or may not be the same as the CoR? If you look at the type of sensors would it not make more sense to specify how the IMU is mounted in relation to CoR?
Permalink Reply by Brad Hughey on July 24, 2012 at 3:00am Oh, that's a different animal altogether. They're trying to get an idea of how difficult the craft is to maneuver, as a starting point for PID tuning. Methinks the DIYDrones adaptive learning algorithms idea will be a much better approach. Here's a Pounds paper which is pretty good at describing the issues, if you don't mind a little calculus.

Brad, is it not true, that technically speaking, the CoR can actually be several feet, even 10's of feet outside of the airframe? What I'm thinking of, is the fact that if your control system increases total thrust at the same time as it does thrust vectoring... say that instead of increasing thrust on one side while reducing it on the other, you simply increased thrust on one side, the craft would rise, as well as rotate, leading to a CoR at a virtual point quite outside the airframe?
This may sound like a stupid question, and a stupid control algorithm, but the fact is, currently our code assumes that thrust is directly and linearly related to PWM output. And this is not true at all. This was simply visible from the "rise on yaw" problem. While working on the yaw fix, I had my quad programmed such that it could achieve a very high yaw rate, on the order or 2 rotations/sec. The problem was that I actually couldn't keep it down. It just rose and rose and rose. I'd cut throttle to the point that I reached the bottom of the stick travel and thus the motors shut down.
I solved this by creating yaw differential. Simply put, the code splits the yaw PWM output. The motors which have to increase speed, get a PWM increase of 70% of the value of the old code, and the motors which need to decrease speed, actually decrease by 140% of what they would based on the old code. Just an empirical number I came up with by testing.
Currently we also have a function called "Throttle Boost", which attempts to hold the quad from falling when it is pitched and rolled. Simply put, it attempts to increase motor thrust as a function of thrust loss due to the simple trig of how far it's leaned over.
But since the actual pitch/roll rate measurement is blind to this effect, it is done outside of them, I wonder if it has any effect?
Not that this really matters because our controller does not care how far it is from the CoG or CoR anyway.
Permalink Reply by Brad Hughey on July 25, 2012 at 9:20am Not to devolve into a discussion of semantics, but strictly speaking, the CoR is dependent upon your perspective in space, whereas the control axes are fixed relative to the thrust vector origins (roll and pitch) or center of torque(s) (yaw).
Yaw control is a special problem, which is why I took the simple path by incorporating a full-flying mechanical rudder in my PoC prototype. It wasn't just about trying to zone 36 separate thrust units into the yaw control scheme, but indeed the thrust variance permutations were intimidating.
The "throttle boost" you describe, of course, is predicted by classical mechanics and is exactly what all fixed-wing pilots know - you have to apply a bit of up elevator when turning to maintain altitude.
I like the approach taken by another rather innovative quad designer recently who incorporated a preset yaw angle into the thruster mountings. Certainly this has an efficiency and forward-flight performance cost associated with it, but it flew pretty darn well in the video.

Yes, I like the slightly vectored for yaw mountings as well. But there are two issues for me:
1) Difficult to do when using square tubing.
2) Not really possible in an X8 platform, unless you did something really wacky I guess.

Is not the extra airframe inertia also a net benefit, instead of a net loss to stability, if your goal is *stability* and not *manoeverability*?
This because the increased rotational inertia also reduces the effect of outside forces, which we are trying to cancel out?
Oh, and while I have your ear... what is your feeling on the DJI Spreadwings S800 frame, which actually has camber or dihedral built into the motor arms, angling all the motors towards the center. Is this a marketing gimic, or do you think it actually increases stability?
Permalink Reply by Brad Hughey on July 25, 2012 at 9:45am Let's define "stability" as an aircraft's property of staying at a desired flight attitude or heading while being resistant to external forces or imprecise control movements. Inertia is a proverbial double-edged sword in this case, as while it would appear to help resist perturbations, it would similarly impede any desired corrective control. In short, inertia adds time - it takes longer for turbulence to affect the craft, and longer for you to fix anomalies once they start. Since weight is the enemy of anything that flies, adding more of it capriciously it is never a good idea. Because you have to have some weight, you should put it as close as you can to the center of the craft so you don't have to "move it around so much" when changing flight attitudes.
Angling the thrust vectors inward to achieve a sort of "dihedral effect" scheme sounds rather plausible, and I've considered it myself. It does sacrifice efficiency, total lift, and control responsiveness for a bit of self-leveling tendency. That's the on-going challenge of engineering, though, to decide among all the necessary compromises in a design.

In my case, the goal is to reduce the amplitude of attitude errors, and also lower the frequency of those errors. The application is Aerial Photography, and I'm simply interested in allowing the gimbal gyros and image stabilization parts a bit more time to do their job. I think mass obviously helps lower the frequency. But what about Amplitude?
I think we have to consider not just the amount of thrust needed to make attitude corrections, and in our case, thrust is somewhat changeable. We can put bigger motors on if we want. But we also have to consider the control system. In this case the controller is running at a fixed rate regardless of airframe inertia. So it we change the "natural frequency" of the airframe, we give the controller more time to sense the disturbance, and decide what to do about it. I think this means that more mass will result in more stability.
As for vectoring, one of the things about this design is that, let's say there is a gust of wind which blows the craft to the left. In order to prevent the movement, we have to roll the craft to the right, in order to vector the thrust to stop the movement. Rolling to the right requires increase in throttle on the left, and decrease on the right. With the "dihedral" you get a benefit here because I think you don't need to roll the airframe as much to stop the movement. As luck would have it, the same throttle change needed to roll the craft to the right, also produces a thrust to the right before the craft even rolls!

Now trying to get back on track of my desired Octo machine:
For me, the only reason to build an Octo is to gain the advantage of redundancy. I want something that will not fall from the sky if it loses a motor. I think part of the problem here is as I say, people are building Octos with the theoretical benefit of redundancy, but then they also take advantage of the payload, and install massive cameras and gimbals. The result is that, regardless of who's flight controller they use, if you lose one motor, you effectively lose 25% of your thrust, not just 12%. I think the design MUST plan for this, and ensure that you have sufficient reserve thrust that the flight controller has a reasonable chance of controlling it.
So, I think the power specification must result in an "overpowered" octo. This isn't great for efficiency, but it's necessary for redundancy. You're going to have to chose here. In my case, I choose redundancy. I simply can't consciously put an expensive camera up in the sky if the darn thing will fall because one of 16 single points of failure can cause it to crash.
I prefer an X8 platform over a flat Octo, because I have heard that they simply do better in the wind. I find my quad is bad enough in even a light wind, I don't want to make it worse by going with a flat Octo. And of the frames I've looked at, I prefer the CarbonCore X8 650. Simply put, I think square arms are better, because it avoids all the complexity of round tubing adaptors. Weight is 650g.
I also know I want to use 4S 5000 batteries, because I already have a lot for my heli.
And obviously I'm going to use an APM. ;)
I want to lift cameras ranging from a lightweight P&S such as the Sony WX10, which is only 162g. Up to a Nex5N which weighs 465g. I'm not sure how much weight to add for the gimbal, I'm assuming the whole thing will come to 1kg with the camera. I'm not sure this is enough, realistically, for the Nex5 though? A Photohigher AV130 is 410g without pan, which I'm undecided on wanting pan at this point.
But the power system I'm not sure about. I'm using Ecalc, and looking at something like the Turnigy Propdrive 2830-750 with 12x4.5 props. Ecalc says that with an empty frame weight of 1800g, it will fly with only 49% throttle. Good. Now I do a check, and reduce it to 6 motors, but add the weight of the dead motors back in. It says 64% throttle. That sounds great. Too good to be true. Am I missing something?
Realistically, I'd probably get the 2836 motors and have even more power. Very little cost/weight penalty.
But I just can't get past the idea that these motors just "seem" too small for what I want to do. So any input would be appreciated.
Permalink Reply by Brad Hughey on July 25, 2012 at 12:04pm If taking pictures is the priority, then having a flying rock is the plan, to the almost complete exclusion of agility. As long as you can get to the position in space you want, nothing else matters.
Electric motors are most efficient operating at about 1/3rd of maximum power, so don't assume buying big ones will hurt your efficiency unless the weight penalty is too great.
The X8s respond less to wind because the effective disk area is smaller. It's analogous to a fixed-wing sailplane versus a Cessna 182 - the latter will have a "smoother ride" because the higher wing loading means less surface area for turbulence to push against. Also be aware that coaxial props cost you an additional 20-40% of your lifting efficiency for the sake of compact packaging. Again, "rock in space" is more important in your application.
I would suggest starting your iterative design process by figuring out how much the total vehicle weight is going to be with the motors, and then calculate the ideal power for each motor based on your 12" prop area (.785 sq ft.). Multiply by 3.1 (assumes prop FM = .6, motor efficiency of 70%, and 30% control headroom). Now, what was that about oversized motors? Hmm...then triple it for the efficiency sweet spot?
Just working my "Case for Large Scale Electric Multicopters" 11" example for comparison sake, assuming your total GVW is up around 8 lbs., that means your motors ought to have a maximum power rating of 225 watts. Not too terrible I guess. Remember to add some for the coaxial loss if you go that route. In fact, the 2836 motors would be more than enough, especially with 12" props. Good call.
I've never played with eCalc, as using the tried-and-true basic formulae seems easy enough.
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.10 members
110 members
182 members
1289 members
140 members
© 2013 Created by Chris Anderson.
Powered by
