Hi All,

I have been thinking about the way we have implemented our throttle and the performance issues that we have observed. First of all I would like to say that I get great altitude hold. I can cruise around at 1 or 2 meters above the ground with no problems. It is only when I start to get aggressive with my pitch, roll and speed that I start to see areas that we could improve. So I started thinking about how we are doing things and why this might cause us problems.

So the problems I see are:

  1. The pwm input to the esc is not linear with respect to the lifting force generated by the motors. Randy improved this by adding a throttle curve, however this can only be truly accurate for a particular combination of esc, motor, and propeller AT HOVER. When we start to climb, descend or move forward, the curve changes and we are back to a non linear response.
  2. Boost throttle compensates for the angle that the copter is compared to the ground. But how much do we compensate? We don’t know because of point 1. We know what force we need but not how this translates to pwm. Hang on...... Force.... Acceleration.....

So I got thinking about how we could ensure we could get the correct acceleration from the props for any given situation. Then I thought we have a sensor to measure that!!! Why don’t we put the Z accelerometer in a pid loop to directly measure and calibrate the lifting force supplied by the motors and propellers. The Pid loop design I started thinking about is shown above and compared to our current design at the top of the figure.

This has a number of advantages over the current system:

  1. The last pid loop, running at 100 Hz, takes an acceleration request then uses the z-axis accelerometer to vary the motor pwm until the required acceleration is achieved.
  2. The last pid loop linearises the rest of the system making analysis and tuning simpler.
  3. The frame translation takes care of the angle boost function automatically.
  4. When at hover or in fast forward flight changes in pitch will cause much smaller variations in altitude because the last pid loop will be working to ensure the vertical acceleration (in the earth frame) will stay as close to 9.9g as possible. We no longer are waiting to detect a change in altitude, we are reacting when we feel that we are accelerating at the very beginning of the unwanted movement.
  5. This should also improve the rise on yaw problem. As the yaw command is entered we experience a positive acceleration body frame z axis. The final control loop should sense this very quickly and reduce the throttle to bring it back to 9.8G.

There are a number of problems we may also need to solve:

  1. The z accelerometer will have noise that may need to be filtered. A moving average filter is the best choice for this because it give the greatest noise reduction with the fastest step response. This filter will be one of the biggest contributors to the delay in the throttle control.
  2. When at rest on the ground the copter will experience an acceleration in the vertical direction of 9.8G provided the motors are going slower than that required to lift off. How do we ensure that the copter provides the user with the appropriate feedback to let them know that they are near hover or not? How does the user know when the copter is about to lift off? This could be a problem because the integrator could wind the motors down to minimum throttle. This may not increase until the requested G increases above 9.8 and then it could increase very quickly to make the copter take off as requested. I believe that these effects could be minimized by sensible selection of Imax in the final loop but only experience will say.

Ok, so that pretty much sums up my idea. I would really appreciate any feedback that people can give. Has this been tried before? Does anybody know if this is being done in other systems?

Thanks for taking the time to read this far,

Leonard

Views: 3321

Comment by Rob_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

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service