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:
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:
There are a number of problems we may also need to solve:
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
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.
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.
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
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!
Thanks for that Crashpilot! I will have a look.
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!
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.
"... 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
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
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!
628 members
275 members
3162 members
34 members
1123 members
© 2019 Created by Chris Anderson. Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones