Check this spreadsheet and use it to set your Q* parameters.
I would probably halve the ATC_ACCEL_x_MAX values that it gives you, but I’d leave the gyro and filter values at defaults (unless you already came up with useful values) since they will affect both VTOL and forward-flight modes.
Hi Shawn,
Thanks for sending the spreadsheet. But it does not seem to work for my setup. Specifically it does not allow for larger than 16S batteries, whereas I am using a 28S battery for the back motor.
Actually my setup is a little more complicated. I am developing a 200 lb tricopter with 2 tilt motors in front and one stationary motor in back. The motors in front are 10kW/ 32in 2 blade prop motors and the motor in back is a 17kW/32in 4 blade prop (made from 2 of the front motor props). Each front motor uses a separate 14S 22Ah battery mounted in front of each of the vehicle’s side panels, and the back motor uses the 2 batteries connected in series to form a 28S 22Ah battery.
Do you have any idea how we can modify the spreadsheet for my case?
Thanks William
Similarly, I am not able to linearize my ESCs because the setup in Ardupilot requires the bat max voltage to be less than 14S. If the ESC/motors are not linear, could this be the source of my instability about set point?
William
There appears to be another way to do it using just ESC/Motor Thrust vs Throttle curves and adjusting the Ardupilot params to linearize the curve. Ref spreadsheet in following link:
https://ardupilot.org/copter/docs/motor-thrust-scaling.html
This could work, but how do you input separate parameters for each motor, since the front an back motors in my case are completely different?
William
You will need to change the ardupilot source code to support motor dependent linerization curves.
I don’t see any FFT data in that flight log, but the vibration levels don’t appear to be high enough to cause serious problems.
Which log did those FFT graphs come from?
Hi Mark,
I created the FFT plots in Mission Planner by hitting Fn F and selecting FFT, selecting Run all imus, and selecting the file 189.bin, which corresponds to the good flight video and log file I posted above. Perhaps the problem is that there are several flights in the log and I am taking the FFT of all the flights.
Again could the problem be nonlinear ESC/ motor thrust curves, which I have not been able to linearize yet, because my configuration is more complicated than ArduPilot permits.
William
Hi Amilcarlucas,
How do you do this?
So, do you agree that nonlinear ESC/motors can be the source of my instability about the set point?
Thanks, William
I had suggested you follow these instructions:
https://ardupilot.org/plane/docs/common-imu-batchsampling.html#common-imu-batchsampling
to use the batch sampler to log at the full sample rate.
We use a motor stand to characterize the motor curves. All our motors are the same.
Hi Mark,
Thanks for info. While I make this test, do you know the Nyquist limit of the Pixhawk Cube? In other words at what frequency will the noise signals start wrapping around and appear as lower frequencies. It is a function of the gyro.sampling freq, over sampling rate, and the digital antialiasing filter. So it is not clear to me. But, according to the FFT I showed you above, the limit appears to be 150Hz, which is not much and some of the noise is seen there and could be amplified by the system oscillation.
But if knowone can tell me the Nyquist frequency of my FC, perhaps I will simply put the FC on a bass speaker, while collecting gyro data, and input a low freq oscillator and sweep it from 10Hz - 1kHz and see at what frequency the signal wraps around and appears as a lower frequency signal in the gyro FFT
William
The fast loop runs at 400Hz by default. So unless you change that, the Nyquist limit is 200Hz
Hi, Thank you. This is helpful!
By the way, we tested the vehicle using Plane 4.2 Beta after having a successful hover flight using Plane 4.0.9 and it crashed due to a large oscillation in pitch (~7 deg pp), whereas with the old software it was only (~1 deg pp). After the crash, we tried tuning the vehicle on the bench using the same pivot on CG method as before, but the drift about the setpoint was a lot larger (~factor 5) and we could not reduce it no matter what PID parameters we tried. Do you know what was changed in the PID loop controller? Are there block diagrams to compare the configuration before and after the change? We would like to use the newest software to take advantage of the latest features, but can’t get the vehicle to stabalize well after the above software change.
Thanks, William
is there any reason your using such a powerful motor on the back? if it was the same as the front motors it would probably make tuning far simpler.
Yes, the vehicle is much heavier in the back and needs more thrust to lift the back end. As you can see in the pictures there is a lot of structure in the back, compared to the front, and because it is also an airplane, the CG is at ~25% from the leading edge in the wing. In the pictures you can see a plywood spar that goes through the wing and out the side panel at the vehicles CG.
We tried using 2 coaxial prop motors in the back (motors and props the same as the front), which were run off the same batteries, but the back end would not lift. I guess there was just too much efficiency loss in the coaxial setup. We need ~100 lbs thrust to lift the back end and each motor generated about 70 lbs thrust, and the efficiency loss was about 25%. So we ordered a larger motor from China, but larger motors use higher voltages to limit their currents. So this has created the setup we have now. We also had to increase the blades used in the back motor to 4 using two of the same 32in props used in the front to get more thrust to go through the 34imnhole in the wing. Once we did all this, the vehicle started to lift. Then we had to tune the PIDs to stabalize the vehicle. We had luck using the pivot on CG bench test I developed and the vehicle hovered very well. But when we tried to update the Arduplane firmware to Beta 4.2 (from ver 4.0.9), the vehicle developed a serious pitch oscillation and crashed several times. We then tried tuning the PIDs again using the same bench test, and got rid of the pitch oscillation, but the setpoint drift was a lot larger (~factor 5) and we could not get rid of it no matter what PID values we used. So we have been trying to understand where the setpoint drift is coming from to try to minimize it. It is clear that there were some changes to how then PID controller operates and this has created the problem, and there may have been other changes as well. Then setpoint drift was always there and is even seen in the roll axis, but the affects in flight were not noticible until the software change.
William
its such an unusual setup, I havent seen anyone with such a large difference in the lift motors, I belive the current ardupilot code expects all the lift motors to be the same, I think your issues are stemming from the fact that your front and rear motors have very different thrust profiles, i believe that’s why it’s a pitch oscillation you’re getting because the thrust response from the front and rear motors are so different that the best your going to get is a tune thats somewhere in the middle of the 2 motors rather than an ideal tune for each. the simplest option would be for all the motors to be the same that would correct the thrust response missmatch, otherwise you would need to modify source code to give you per motor thrust curves like @amilcarlucas suggested.
Essentially your rear motor can respond much faster than the front motors causing it to pitch forward, the flight controller is then detecting the pitch forward and is throttling up the front motors and reducing power to the rear motor more to compensate, then when it pitches too far back it just repeats resulting in the oscillation.
Hi GeoMuir, I am seeing the same type of setpoint drift in Roll, but it is less noticeable since the vehicle is longer than it is wide. Both the Pitch and Roll have ~1 deg pp setpoint drift. But the difference is that the 2 motors in front stabalizing the Roll are the same and we are seeing the same drift problem there. So I dont think this is the problem.
I suspect that this setpoint drift problem is common in all drones and we are just seeing it because of our unique sensitive experimental setup, where we pivot the vehicle at its CG and observe how it stabalizes. Here is a link to a similar 2D drone test setup. Notice the drift about the setpoint when the PIDs are tuned properly (ref 15:32 min into video at the end). This is what I am seeing and want to know what it is due to and how to minimize it?
Thanks, William
Take a closer look at the description for batch sampling. It says that the gyro sampling rate is typically 8KHz on a modern FC.
Here’s an extract from your log 252:
1969-12-31 17:25:17.752 ArduPlane V4.2.0dev (a86536ae)
1969-12-31 17:25:17.752 ChibiOS: 93e6e03d
1969-12-31 17:25:17.752 CubeOrange 00300024 30305114 35333339
1969-12-31 17:25:17.752 RCOut: PWM:1-14
1969-12-31 17:25:17.752 IMU0: fast sampling enabled 8.0kHz/2.0kHz
1969-12-31 17:25:17.752 IMU1: fast sampling enabled 9.0kHz/2.3kHz
1969-12-31 17:25:17.752 IMU2: fast sampling enabled 9.0kHz/2.3kHz
showing you have a Cube Orange with 3 IMUs with sampling rate >=8KHz and backend rate >=2KHz.
Regarding your control issues, I don’t think you have ruled out ground effect as a major contributing factor.
William is using Plane firmware with quadplane Q_FRAME_CLASS=7 (tricopter).
The default loop rate for quadplane is 300Hz, a bit slower than for copter since the dynamics for a plane are usually much slower.
Hi Mark,
Thanks for update on the sampling rate. This helps a lot. That explains why the FFT plot maxes out at 150Hz , which is the Nyquist freq of a 300Hz sampled system. So any noise above 150Hz will get wrapped around and appear as lower frequency noise. I am organizing the FFT gyro noise test you suggested and will get back to you with the results.
In the meantime, I am starting to see that this setpoint drift is common to all drones and the reason we are seeing it so clearly is that our vehicle is so large, which magnifies the effect, since the arc of an angle increases as the radius gets larger. You can see the setpoint drift in the following video (ref 15:32 min into video) which tests a 2D drone setup similar to my setup:
And in the following video you can see the setpoint drift as real drone hovers (15:20 min into video)
In responce to your ground effect comment, I mounted the vehicle on saw horses which lifted the vehicle about 1.5 ft. I did not see any real difference in the setpoint drift. So I think it is coming from somewhere else. I suspect it is the motor noise coupling through the gyro sensors and being down converted to lower frequencies due to the 150 Hz Nyquist limit in the gyro sampling. Some of it can also be due to nonlinearities in the ESC/motor thrust curves.
The back motor is seriously imbalanced since there is no center post for the props and I can visually see that one of the two props has shifted several mills off center after all this testing. I will try to fix this next week. In the meantime, I have another well balanced 3 blade prop that I can try. If I see less setpoint drift then I know the prop imbalance of the 4 blade prop is causing a problem.
William