Blogs

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