Developer Comment by R_Lefebvre on October 24, 2012 at 7:22am

Leonard, I responded on the list, but I'll attach here too for further discussion:

I think it's a pretty good idea, provided we can get the accel stuff to work well enough.  That is obviously the kingpin of the whole thing.  If that fails, well, obviously we don't have anything to base the Zaccel stuff on.  But that is looking promising so that's fine.

Generally, I like this scheme, it seems straight forward.  I'm a little concerned about piling a full rate  PID on top of an accel PID.  The I of accel is rate, and the D of rate is accel.  So we are going to have problems, no?  Shouldn't it just be Alt_Hold_P-->Alt_Rate_P-->Zaccel_PiD

Also, I'm a little concerned that we are boxing ourselves in a corner here.  This type of thing will really only work for pretty simple hovering devices, but it is not going to work for tradheli and other complicated things, tilt-rotors, etc.  It's working for multi-rotors only because they have a huge amount of airspeed damping, and we are generally flying waypoints pretty slowly.

The problem is throttle does not really give us Z-accel.  It gives us energy. This all comes out of my talk with Jonathan on the weekend.  Throttle is energy, and the vector of the energy is what gives us both forward acceleration, and vertical acceleration (taking into account the constant 9.81 m/s/s downward decleration).

We need to unify both forward speed regulation, and vertical speed regulation, into a single unified thrust vector.

Here's why you should care, even for multi-rotors:  What is going to happen when somebody tries to fly a waypoint mission at 10+ m/s in a quad, and on the return leg, there's a headwind?  They might not make it home.  Currently, the nav controller will drive the tilt further and further over to try and maintain ground speed.  Thus, the thrust vector is tilting over, losing vertical component.  The quad starts falling, so the auto_throttle starts trying to maintain altitude.

Eventually it can get to the point that there is not enough throttle to maintain altitude, and there is currently NOTHING stopping that from happening.  The groundspeed regulator will happily push it over to 45°, while the Alt_Hold is struggling to maintain altitude.  It's completely possible this will drive it into the ground.  Or what happens when we are flying at speed, and encounter a hill.  The sonar picks it up, but the groundspeed regulator has the thing tilted over and there is not enough vertical component of thrust left to gain altitude?

Sure, we can stop this with some groundspeed controller output constrains, or possibly an observer.  But that's the low-performance way to do this.

The high performance way, looking at this from a unified thrust vector standpoint, will easily allow us to manage this problem, as well as unlock the potential to work with high speed TradHelis, tilt-rotors, etc.  It also makes it easier to intelligently put some controls in that make altitude regulation more important than groundspeed regulation, the same way we did that when we made attitude control more important than yaw control.

We're not far off.  3-axis Acceleration measurement is a big key to it.  Then we just need to consider the thrust vector in all 3 axes, and place that on top of the auto-mode controller.

Developer Comment by leonardthall on October 24, 2012 at 8:19am

Thanks Robert,

Robert you made quiet a few points there, I will try to address talk about these but I think some of your points really concern the use of throttle by the rest of the system rather than how we control the throttle itself.

First up I agree that we might be able to simplify the design by making it a Alt_Hold_P-->Alt_Rate_P-->Zaccel_PiD topology. I kept the rate pid in to make a better link with the current system and because I don't know how this will effect the performance yet. Double pid loops arn't a problem though because they are each working on the error between the desired and measured values, not just the measured values.
 
This pid design doesn't need Randy's accelerate stuff because we aren't tempting to combine all three accel censors to work out the vertical acceleration in the z frame. In fact, we don't even need a calibrated z-axis acceleration measurement. This design is there to specifically control the magnitude of the thrust force vector, what we do with it in the higher levels is up to us. In this case the higher level is using it to maintain altitude.

I understand what you are saying about the throttle providing an energy vector however I don't think this is strictly true. In hover the throttle doesn't provide energy because we are not moving, it provides force (Energy = force x distance) if distance is 0 then energy is 0. For the proposes of staying airborne in any given flight mode we must ensure that the force in the vertical earth frame is enough to sustain 9.8g, the energy we are generating is not important provided we don't compromise the vertical component of force (that doesn't add energy to our airframe) to get horizontal force that increases or velocity (adds energy) and/or counters drag. When we hit our motor limit we should be able to easily calculate what our body axis z force is and from this calculate the maximum pitch angle we can use and still maintain altitude. As I said though, in my opinion this is really a higher level control function.

Now I am not sure why this can't be used by helli's and other airframes as well. Can you explain this more? The only thing that would complicate matters is if the lift force is not in the same direction as the z axis (tilt-rotors).

Thanks for your feedback, I still have to get a better understanding of how this will work in the dynamic environment of varying batteries and a human in the loop.

Comment by Crashpilot1000 on October 24, 2012 at 9:57am

Comment by Crashpilot1000 1 second ago

Delete Comment

A accz integration into althold and throttle angle correction is the key. I did a much more simpler solution for multiwii, wich works really good http://diydrones.com/xn/detail/705844:Comment:1009947

So long

Kraut Rob

Developer Comment by leonardthall on October 24, 2012 at 1:49pm

Hi all,

I haven't had a chance to read through all the emails but overnight I
have been thinking about this and I did discover a problem. While in
hover the z accelerometer is proportional to the force being applied
to the copter, HOWEVER in fast forward flight the drag force counters
the lifting force resulting in a reduced accel measurement..........

I need to think about this to work out how it effects the idea, it
defiantly throws a spanner in the works!

Thanks everybody for their help. I will read through the discussion asap!

Developer Comment by leonardthall on October 24, 2012 at 2:20pm

Thanks for that Crashpilot! I will have a look.

Developer Comment by leonardthall on October 24, 2012 at 2:33pm

Just a quick correction to my blog post. I have you used "9.8G" but I should have written "1G" or "9.81 m/s^2". And I think this pretty much sums up the problem with the approach too!

Thanks Marooned!

Comment by MHefny on October 24, 2012 at 9:05pm

I did used Z-ACC to monitor Throttle when rotating in my HefnyCopter2 ... I noticed the YAW change altitude disappeared or minimized based on the value.. I used a simple P value to be multiplied by ACC delta from 9.8 then to be added to Thr with negative sign...

I will study your model more closely.. Thanks for sharing.

Comment by Crashpilot1000 on October 25, 2012 at 11:56am

@leonardthall

"... HOWEVER in fast forward flight the drag force counters
the lifting force resulting in a reduced accel measurement..."

Thats the problem i encountered today. The main forumla in my code (wich is taken from Mwii forum/Mahowik, and wich i don't understand :) ) will produce a wrong velocity sum with tilted copter. Althold in one place ie good, but moving around will result in serious drop due to misreading. A throttle angle compensation can not compensate for that error. Because of my very limited understanding of mathematics, i did a workaround, wich minimizes the problem without eliminating it. I took the tiltangle (0.99 = Horizontal 0 = 180 degree) multiwii: "float  TiltAngle = EstG.V.Z/acc_1G;"  and multiplied the wrong accz projection result 4 times with it (don't know the correct english expression for "hoch 4"). So when tilting the copter the wrong readings are diminished in the sum. Besides this i used a small deadband for the resulting accz of "5". This solution is not perfect but def. ok to fly. I think a bigger deadband could stop wrong readings completely - didn't try today.

Here is the code i added after the accz "formula"

  float  TiltAngle = EstG.V.Z/acc_1G;
  accZ = accZ*(TiltAngle*TiltAngle*TiltAngle*TiltAngle);
  if (abs(accZ) < 5) accZ = 0;

velz = velz+accZ*accVelScale*ACCDeltaTime;

Sorry, that i am not able to present you a mathematically correct solution, but perhaps you can make some use of my findings.

So long

Kraut Rob

Comment by Hans Jakob Bosshard on November 10, 2012 at 3:55pm

Hi, I see you studied the alt_hold function in detail. Perhaps you can help me to solve my alt_hold problem with an APM 2 on a Storm Drone (www.helipal.com ). I tuned the attitude PID's with a simple testbench (see photo) with attaching the drone via cam holder. The motors were running approx. in a hover condition. The alt values from the MB 1200 sensor seem correct without much noise. So I am astonished that I did not succed to tune the alt PID parameters up to now. The best I can achieve up to now that the drone holds at low altitude (over short lawn) for some seconds (say 10 ... 20 s). Afterwards it climbs continously (somtetimes after going down nearly to ground) to 10 ... 20 m or more (I stop here switching to stabilize mode).

Thanks for your suggestions

Hans Jakob Bosshard

Developer Comment by leonardthall on November 11, 2012 at 4:47pm

Hi Hans,

The way I tune Alt hold is to start with the default parameters and go fly it. Make sure everything is working well in Stabilise mode before trying to tune Alt hold.

With the default parameters for the throttle switch to Alt hold a good altitude (20m or above) and see what it does. If it starts a slow oscillation up and down, reduce the Rate P on the throttle.

The problem with Alt hold is that there is a large delay in the altitude reading so it can be tricky to tune if you are starting from scratch.

Good luck and let me know how you go!

Comment

• ‹ Previous
• 1
• 2
• Next ›
• Page