Tried 3.4-rc1 out on a 260mm quad that I use as sort of a test machine. Took off in stabilize, switched to loiter, but then it wouldn’t come back out of loiter to stabilize. The logs said Err: FLIGHT_MODE-0. Any idea of what I did wrong? Or maybe the drop in satellites prevented mode change? Attached is the .bin of the flight. Thanks for looking! 20.BIN (350.3 KB)
Took off, switched to althold. Tried doing an autotune, but it wouldn’t start. Gave Err: FLIGHT_MODE-15. Then when I hit a switch on my transmitter for land and instantly the motors just stopped like motor interlock mode and the craft dropped from the sky, smashed into the ground
and broke apart. Not sure what went wrong. Here’s the log of the flight 21.BIN (740.0 KB)
Just by looking at these two logs, one thing I noticed was the pressure measurement appeared to be really low (about half of what it is supposed to be at sea level). Is the Barometer OK? With this pressure it is almost 5km above sea level.
Second, the DAlt was not holding flat in either alt_hold or loiter mode, though the RC input didn’t seem to correlate with DAlt variations. Looking at the RCIN, throttle c3 varied quite a bit in alt_hold and loiter modes. Did you change altitude when switching these two modes?
I don’t think GPS status can cause issues when switching from loiter to stabilize, it would rather do the other way around.
Things may be checked are barometer health and RC stick drifts (mainly on throttle stick in this case)
The first log, 20.bin, the craft seemed to not respond to inputs in pitch/roll once it went into loiter, it just slowly floated in one direction and the only control I had was bringing the throttle down.
The second log, it seemed to be flying ok, but when I hit land, the motors just stopped mid-air. Does some sort of baro issue seems possible? Could the strange pressure readings be caused by the sun warming the flight controller (looking at 21.bin)? Logs show it was seeing about 44C or 111F. It was a warm sunny day and it sat in the sun for a few minutes (to gain sats).
The craft was destroyed, one of the arms broke off the frame (Kingkong260) but the frame was only $10 so its not a big loss. I have another frame coming that I can continue testing in a week or two.
Is there a way to test the baro without flying?
Sometime I cheked connecting the FC to Mplanner, check Tunning box down the map in the flight page (first one) then check baro ALT and you can see a dynamic baro graph; not shure if it’s the best way.
What FC are you using? I mostly use rasperberry pi so I can run the baro example separately from the main flight code. In your log the pressure reference appears to be off. I am not sure if there is any easy way to check barometer on pixhawk (you can do this in 3.3 and check relative altitude from mission planner telemetry).
The symptom in the first flight where you lost pitch and roll, try to calibrate accelerometer and compass again and reboot FC. I had similar issues before but usually this would fix it. In the second flight it is possible accelerometer/compass/barometer had issues that confused EKF so the crash landing.
Have you had any issues with earlier 3.4 dev, say about a couple of months ago? I had good experience with older 3.4 dev.
Using a chinese pixhawk 2.4.6. Now that you mention the baro, I see from missionplanner the altitude just stays at 0.00 preflight. Usually its bouncing up and down a few tenths, and while its warming up it drifts up to about 7 feet, but its staying at 0.00. Not sure how to further diagnose, any ideas? I loaded 3.3.3 back on and the baro seems to work, altitude in missionplanner is updating like it usually does (right now watching it go from -1.31ft to -2.05ft).
I did have issues with 3.4dev, the copter was oscillating terribly (I compiled it myself). I thought it was bad p gains, but I tried all the way from 0.05 to 0.40 and it did the same thing. The oscillation happened on 3 different multirotors on 3 different FC (2 pixhawks and one px4lite). But I’m not sure this is related, as the release candidate did not oscillate. I read somewhere someone thought this was a compilation issue.
Thanks very much for testing. We’ve seen this kind of issue a bit with the very small but powerful copters.
I think the underlying issue is that the the copter is incredibly over powered or at least it seems to be getting off the ground at perhaps 10% throttle but the THR_MID parameter is set to 432 (i.e. about 43%). The issues comes because we assume the copter cannot be taking off with less than 1/2 of mid throttle (i.e. 21%). So the various things you’re seeing: no roll, pitch or yaw control in Loiter, the inability to switch back to stabilize (because the throttle is too high while the vehicle is “landed”) and the sudden drop in Land mode are all caused by this.
In Copter-3.4-rc2 we’re thinking of adding learning of THR_MID but in any case, I recommend:
- reduce THR_MID down to 300 (it’s minimum)
- reduce THR_MIN - it’s at it’s default of 130 but I suspect you’ll find your motors start spinning at a much lower level. Maybe try 80.
- reduce MOT_SPIN_ARMED to a value a little lower than THR_MIN (maybe try 70).
- reduce the power of the vehicle if the above doesn’t help.
Hi Randy, thank you for taking the time to look at the logs and reply. That makes a lot of sense, wasn’t something I’ve thought about up until now. I’ll try the recommendations and report back in a week or two. Thanks again!