Oddly, I cannot seem to find log files for either of these flights. I know I did not delete them, the copter must have just dropped them.
I can attach the telemetry logs for each of these. In each test, I raise the hex in the air several meters then with a very small gust of wind, the copter nearly loses control tilting > 30 degrees on the pitch and roll axis.
I am thinking it is not a PID issue since the copter handles so well until this dramatic change. It flies like a slow giant normally.
Additionally, I am also facing the common (but new to me) issue of the Pix losing its mind when I request files over mavlink. It just overloads I am guessing. I don’t know if this would be relevant but I felt I’d share.
Look around 70% through on this log. This time it was triggered when I tried to gently yaw. I originally thought it was under-loaded, but I experienced the same thing on the second flight fully loaded so I ruled that out.
Unfortunately I couldn’t really tell anything from the tlog. Is your FC creating any new dataflash logs at all? I’ve had a couple drones stop writing dataflash logs until I erased all logs or reformatted the SD card before.
Yeah, any heavy file I/O or UART communication load can cause this, such as downloading a log, requesting log list, etc.
Yes so the cube does still make logs. Even when disabled. But both times it’s been in the air it has had this issue which means both of the most informative logs weren’t recorded.
I can make a new topic if thats appropriate, but my logging params were set to log while disarmed and had a very inclusive bitmask of what to log. Knowing there are issues with the cube getting too overwhelmed while doing something with logs, is there a possibility that this extra logging is part of what caused the issue?
Sorry to keep bumping the post, but I was able to find the dataflash logs of the second flight (the one yesterday on 3.6.10). I disabled logging while disarmed and reduced the bitmask back to the default value. However, if anyone has a few moments, please look over this log file and see if you can see any correlation to the loiter issue.
You can see the pitch attitude diverging from the target (red, green lines) just after motor 5 bottoms out. The copter is having trouble maintaining attitude because one of its motors does not have control authority below that throttle setting. Also you can see motor 6 flatlining - the motor mixing in ArduCopter is preventing it from throttling down because its diametrically opposed motor has reached its lower limit.
There’s a couple things you can do about this:
It seems your motors are not level. Your copter is constantly commanding a yaw left, which means you have a mechanical right-yaw bias. This explains why motor 5 is always running slower than motor 6. Fixing this will level out the throttles on your motors, so they are less likely to bottom out.
Lower your minimum throttle setting. This is controlled by MOT_PWM_MIN. Lowering this will give your motors more room on the bottom end for control. Knowing how low you can set this requires some testing: keep incrementally lowering MOT_SPIN_ARM and arming the drone until you find a value where the motors always start up without issues - this is your lower limit. You can set MOT_SPIN_MIN to be equal or slightly higher than MOT_SPIN_ARM. Your current settings of 25% and 30% are quite high.
(Optional) Add weight. You are hovering at ~15% overall throttle, which is quite overpowered. If you are planning on adding a payload, then that will help. Otherwise, a bigger battery will increase the overall throttle and get you farther away from the motors’ bottom limit. Other options include smaller propellers or lower voltage battery. This shouldn’t be strictly necessary if you make progress with points 1. and 2.
I appreciate the input from both of y’all. Each of you saved me a headache and probably a copter.
So Foxtech gives a “flight and tuning” line item in what they deliver for this drone. I think they did fly it (and softened the feel of the sticks maybe). But as far as PIDs are concerned, it was completely default even down to the filters which seem very important in flying large copters.
So basically it is completely my fault that I didn’t look into their tuning parameters before taking this thing off.
That being said, I spent a few flights tuning the parameters. It now holds position very well, but still shows symptoms of underloading. I added a 5.5 pound payload and tuned it with the payload attached. But while AUTO mode descending, I see oscillations as some of the motors are still close to bottoming out.
So maybe I can tune the PIDs a bit more to get that out, but the most pressing issue to me seems to be the mechanical yaw bias causing every other motor to spin slower. However, this GAIA frame from Foxtech seems designed well and very level. The motors aren’t really given wiggle room to point off-axis. So what else could be causing a mechanical yaw bias?
I’ll attach my logs of the most recent flight just in case some one wants to sanity check my ideas on what to do next to get this flying near-perfectly.
The oscillations have a period of 1 second, so it’s very likely an I term tuning issue. Besides PIDs, there’s two things you can do to improve your tune:
Set MOT_BAT_VOLT_MAX and _MIN to the highest and lowest battery voltages you’ll see in flight. Arducopter will scale control effort based on voltage levels. This helps keep the copter tuned for all voltage levels.
Change your MOT_THST_EXPO from .8 to 0.2. T-Motor ESCs linearize their PWM-thrust curve, so a lower expo of 0.15-0.25 is generally measured to be appropriate for these ESCs. This helps keep it tuned at all throttle levels. Interestingly, the default is 0.65, so maybe Foxtech changed it to 0.8? Not sure why they would do that. Then again, they also increased the min throttle to 30%, so who knows what they were thinking.
As for the yaw bias:
Well, it’s almost always caused by un-level motors. A small deflection of 1 or 2 degrees is enough to create a noticeable bias. Besides that…
Maybe check your props - a prop that generates a lot of drag could also do this, I suppose. Not sure what else.
Your yaw controller oscillates a bit as well, so once the bias is fixed, some tuning might be in order.
From what I understand T-motor no longer linearizes their ESCs, they did on older ESCs, but no more. In that case the MOT_THST_EXPO value of 0.8 would be more appropriate, or at least that is what I am running on my large hex with T-motor Alpha 60A ESCs and it performs great.
Interesting. These are Flame ESC’s, which have been measured in the past. I wouldn’t be surprised if the Alpha series was different, but I would be if Flame ESCs had different curves depending on manufacture date.
Thanks for the info, though, I have a set of Alphas that I was about to start using, and I assumed I’d have to use a lower expo for them. Guess I’ll have to look into it.
