Hello ArduPilot community. Your help is always invaluable. This incident happened yesterday, while flying at 5000 mts above sea level. In a routine loiter test, the 1400mm coaxilal quad (26" propellers and 22mAh battery) suffered a sudden drop of alitude which ended up breaking the landing gear.
The following was the message that I received from telemetry while the error happened:
In the image, it can be seen that the drone looses confidence on its vertical measurement, and tries to change EKF mid-flight. Also, the following can be seen in the barometric altitude vs the EKF estimated altitude (from the log CTUN column):
It appears as if the main barometer spikes and causes the drone to descend, but id did so in an uncontrolled matter. In the barometer comparison, it seems like BARO0 has a very different reading when compared to the other two barometers. I have to also add that I am using a Here2 connected through CAN port and with the barometer enabled (Thus ending with 3 measurements):
In the image above, its clear that Baro0 is much noisier and has a very different reading when compared to the other 2.
The internal barometers show that indeed something happened, but I dont understand why the EKF did not reject that measurement. Is there anything else I am missing?
(possible miss-tuning, compass, power,âŚ)
An additional detail found is that, close to 2000m of altitude, the IMU mismatch is close to acceptable levels (0.26-0.5) but when I went to 5000m of altitude, the IMU mismatch is more prominent (1.1-1.45) when the Mission Planner Automatic Log analysis is engaged.
Can you tell me if you made any changes to the tuning at altitude?
How did you determine your Mot_Expo?
This doesnât look like an EKF problem to me. It looks like you Expo is low and the high altitude meant you were running at a higher throttle and the aircraft started to oscillate. We do compensate for altitude but it does rely on correct settings for Expo. The combination of low expo and high altitude and throttle may have caused the problem. However I would need to compare the low and high altitude logs.
Hello Leonard, thank you for your time and for replying to this post.
The tuning used at this takeoff site was product of an autotune our team did at 3600 metres of altitude, which proved to be quite sound and stable at 4000m and at 5000m of altitude. But as soon as we add 1.5kg of extra weight at 5000m, it happened the issue reported in this post. Perhaps the further increment in weight and altitude to 5000m proved to need a different tuning, and we are expected to tune the drone at such altitude early tomorrow.
In terms of the MOT_EXPO, we derived a value of 0.55 from thrust tables that we generated from experiments in Bogota. Our drone is a coaxial quad (x8) with T-Motor FLAME ESC. It is important to notice that the thrust tables was obtained at 2600 m with 28â prop⌠right now we are at 5000 m with 26â props (and as we said, a set of tune params from an autotune at 3600m).
Leonard, for you to review, in the same link I had the accident log, I also included:
The table used to calculate the MOT_EXPO
Log at 2000m with the usual payload (+1.5kg)
Log at 5000m of manual flight with no payload
Log at 5000m of auto mission with no payload
Log at 5000m of accident with payload (+1.5kg)
You canât generate a decent trust curve from that data. This is why you have got a funny value. You need data points through the whole range. Also you have not set up your MOT parameters properly. I think you are suffering from a incomplete tuning process.
From that last time, we corrected some of our parameters such as MOT_BAT_VOLT_MIN MOT_BAT_VOLT_MAX. We did not change the pwm settings of our escâs since the manufacturer recommended to leave the default rc calibration settings, and MOT_PWM_TYPE is 0 (normal).
With these settings, we decided to do a alt-hold pre-test of the drone at the altitude giving pitch, roll and yaw inputs that were large enough to se the response of the drone (see Manual_agresivo_dummy.log in same folder as the remaining logs).
Since we saw that the drone was handling the inputs well, we decided to perform autotune on the site for pitch and roll, but we had a very unexpected turn of events, where the drone out of nowhere started oscillating without any appartent input (no changes in desired roll visible, just a zero line):
This case the pilot was able to land the craft, but it was very strange event, since there is no apparent âkickâ as we were used to when tuning the craft at lower altitudes (this same craft was tuned with no issues at 3600m of altitude)
This same craft was able to traverse much tougher missions afterwards with no apparent problems that same day ( see DIA2_MISSION1.log DIA2_MISSION2.log), but I have no clue why autotune had this issue that did not show in either the manual or the automated flight.
I would be interested to know how the esc manufacture justified telling the developers they donât know what they are talking about. In particular why you should leave your PWM range unspecified and instead set them based on the transmitter you happened to use to set the aircraft up with initially.
All this is consistent with bad expo value and an on the edge tune. The right set of events caused by your pwm settings could also cause this (but I donât think that is the case here but the point stands).
I checked your log and you have not made any correction to your expo value. I canât help you if you wonât listen.
Hello Leonard,
Ok, lets talk about changing MOT_THST_EXPO. The issue I have with the change is that the drone in question has 26" coaxial propellers. I dont have the tools to change the settings at the site by thrust measurements (I would have to create a big thrust stand and I dont have the means right now).
However, following the guide, it suggest to use about 0.78 for 26 inch props. Should I change the value to that? Does it work for coaxial builds as well? Also, in other post you mentioned that âCoax propellers also seem to be lower so I use 0.5 for most coaxial designs if I donât have measure thrust characteristicsâ, which is close to the value we have (0.55), and to be fair after autotune we have not had issues at lower altitudes (from 700 all the way to 3600).
So, for MOT_THST_EXPO, what is the best way to proceed?
Change to 0.78 as the plot suggest
Change to 0.5
Find the way to measure its thrust (I think we found a way up there with increasing weight on the copter progressively, but its a tad risky) all the way to 100% (2000 pwm) and calculate exactly.
Thank you for your time.
(Edit) After talking to them over email, they send me a manual of the escâs and found the range of their throttle signal pwm to be between 1100 and 1940 micro seconds. I will change those values immediately and test the craft through all its battery range, on MOT_PWM_MIN and MOT_PWM_MAX.
Exactly! And do you realise what you had it set to? Your range was set to 982 to 2002. This is why you donât just go with the random values from whatever receiver you have connected to the aircraft at the time. This is even more important if you are using something like the Alpha or hobbywing escâs that have a fixed pwm range.
So the operational range you were using is: 1135 to 2002. That means you have very high risk of causing exactly your issue from just the PWM range. You have a massive dead band at the top and a you are getting into the current limited torque hole at the bottom.
Now I look at these parameters, were the motors even spinning at minimum throttle?
Hello Leonard,
Having had time to re-configure the drone I may be able to explain why it was somehow working (of couse not optimally) with those âfaultyâ PWMs. For example, it was spinning at min throttle, at the throttle percentage calibrated with MOT_SPIN_ARM.
Having set the PWMs to the receiverâs default, and then making the esc calibration, and finally doing the motor spin test to set MOT_SPIN_ARM and MOT_SPIN_MIN meant that somehow that wider range was mapped at least to the minimum pwm that was alright to run the motors.
For instance, after changing the PWM range, our MOT_SPIN_ARM and MOT_SPIN_MIN went down about 3%, which is OK to us. The deadband at the top was still problematic, and I am glad it was caught.
The biggest impact that we detected upon further testing was the difference on MOT_BAT_VOLT_MIN, which was using 3.5V per cell instead of your recommended 3.3V per cell, since there were times going up the hill where the voltage will sag beyond or close to 3.5V per cell, for example when coming back up the hill after hitting failsafe (which was 3.6V per cell), thus creating opportunities for risky and perhaps catastrophic power losses and hard landings.
Hey @Leonardthall
We should really try and document some of the ESCs which use fixed PWM(atleast known ones). Add it somewhere in the documentation. Probably in ESC calibration page?
I have seen lot of people messing up with FOC ESCs.
Ok, a brief update:
After changing voltage ranges and PWMâs, and redoing tuning the drone has not had any issues so far (20+ missions and going strong at 5000m+).
Thank you all (and Leonard as well) for all the help provided.
