test of autotune at the field:
autotune of the hexacopter:
very nice response of the autotune, very quiet hover - everything perfect
pixhawk causes battery failsafe, but there is plenty battery left.
battery fs means RTL what the copter does. climb 10m up, RTL, hover in Loiter… Then:
I cannot control anything via remote control radio ( but it is LOS 10m away from me - no radio Failsafe
i try to switch to althold, ekf failure, gps glitch, and unknown errors (see log) and the thing falls out of the sky…
Setup:
Airframe: Tarot 680 Pro Hexacopter 680mm ø
Motors: Tarot (ca 900 KV) Motors (the ones recommended by Tarot)
ESC: DYS BLHELI32 30A (overkill but it should work)
GPS: 2x ublox
Remote Datalink: Mavlink 900Mhz
Remote Controller:Taranis Frsky x8r 2.4ghz
FC: Pixhawk 2.4.8 Clone
Firmware Arducopter 3.5
Battery failsafe was triggered because of capacity used. You have BATT_CAPACITY = 4000 and FS_BATT_MAH = 400, which means the failsafe will trigger once you’ve used 3600 mAh. This condition was met and functioned as intended. If there was plenty of battery remaining as you say, then you need to change one of those parameters to match your battery capacity or desired headroom, or recalibrate your current sensor in case it is reading too high. Alternatively, you could use a voltage-based battery failsafe, which tends to be more reliable.
The copter was still receiving your commands from the radio. During the initial RTL sequence, the copter will fly itself home, and you won’t have control unless you switch modes. During the landing descent, you will have control of X and Y, but not altitude/descent rate.
It looks like the copter fell out of the sky because you switched to Stabilize mode while your throttle setting was 0. I guess you set your throttle down because the copter climbed unexpectedly to RTL.
The only thing that really looks odd to me is these position jumps:
They only happen twice, and the first one doesn’t affect anything because in you’re in AutoTune mode. But the second one happens in RTL mode and causes the drone to displace in order to meet the old position target. I couldn’t find any reason they occur: no GPS glitches or EKF inconsistencies. Anyways, they’re not the cause of the crash.
Thank you Anubis,
Thank you for your analysis:
to 3. Strange thing was: I pushed the throttle way up, with any other drone this should have helped, but I am 100% sure the motors stopped totally spinning .
to 1. : this seems to be my fault, as I read the params carefully I understood it as min maH to trigger Batt FS, not maH used since start …
I was after RTL triggering not able to control any axis, x, y, z, landing descent never started (it was just in pos hold or loiter)
after switching the mode to stabilized mode: my throttle was way up on the radio, I switched and it either disarmed, motor emergency stop or it just cut throttle power totally to the esc. As an experienced FPV pilot I can assure you that I tried throttle changing to stabilized mode, I am not 100% sure but I remembered the incident as trying to push throttle up while the drone fell, the log shows 0% throttle after RTL was initialized. Also the drone did not initialize the landing sequence
if throttle would have been down, should it not have triggered RC FS ? as my taranis is way down on throttle (under 1000)
Your radio failsafe is set to trigger when the PWM input is less than 975, set by FS_THR_VALUE = 975. In the log, it went as low as 997. Meanwhile, the other channels were still receiving commands, so your radio was still connected and didn’t trigger the failsafe, but I can’t say why the throttle channel didn’t respond like you remember.
Are you sure it never started its landing descent?
It looks like it started descending just before the fall, after the 5 second RTL loiter-above-home. You should have had XY control while it descended, although that weird position glitch definitely would have made it feel like it wasn’t doing what you told it, since the drone started moving when your sticks were centered, but afterwards it does seem to respond to your inputs.
In any case, the problem is of course the RC throttle input being 0 when you switch to Stabilize. I can’t find anything in the log that might indicate how that could have happened besides the obvious, which could point to a hardware issue. If you’re sure you had it throttled up, maybe try slamming your TX throttle stick around to see if you can get it to glitch out, or maybe that there isn’t some inversion setting somewhere (Autotune/CH8 switch? It was flipped soon after stabilize).
I found what those Unknown Event:67 are. They are caused by the flight controller switching between your two GPS modules. This is what caused those position glitches. Unfortunately I don’t have any experience using multiple GPSes, so I don’t have any suggestions for improving blending or preventing this.
Battery FS was triggered as programmed and as intended, although the measured voltages and maH after the flight/crash did indicate 3.8V per Cell (4000maH Battery, 4s) -> to my knowledge there would have been plenty of space down to 3.5 or 3.6 V per Cell as I calculated, as maH is depending on the variable Load/Resistor/Motors(total) it is, as you said much less reliable than the actual VBatt Voltage, that was my fault and I will enable Battery Voltage FS only, depending on my 4S setup
the throttle values from the taranis could have been an issue, but I use similar setups and can say that the taranis is very stable and never goes under 990.
I am quite sure that I tried to raise and lower the throttle during RTL (which made no sense as I learned now), I also tried in the Loiter mode phase throttle and pitch/roll, to my memory there was really no response at all.
could be that I lowered the throttle while switching with my other hand the mode
to my memory I let the throttle the whole RTL/Loiter/Landing Phase in mid Position except for my intends for raising throttle several times
in Landing phase I am definetly sure that I had no x/y control
I tried to balance the drone while falling in x/y and tried to push the throttle up
ch8 / autotune was deactivated soon as it did fall as I suspected this hindering me to take over control over the drone
what I learned further:
I have to change the gps setup to make one primary and the other just as backup (or remove altogheter) - I have to take another deep look at the compass variables (blending etc)
will test the throttle/hardware issue thoroughly, as I had already problems with the pixhawk 2.4.8 clones (which hardware would you recommend ? a linux based system with px4 and nuttx ?)
I did order another Tarot Frame and will rebuild next week, the pixhawk seems to look okay for reuse, so I will keep you updated on my build/testing progress
one more time: thank you so much for your look into the log file !
I only have experience with various Pixhawk 2.4.x and the Pixhawk 2.1/Cube. The Pixhawk 2.1 isn’t small or lightweight or cheap, but I can say that it is very capable and offers a great degree of flexibility and provisions for safety, and is certainly of higher quality than other boards I’ve used. It’s also quite well supported, and has a lot of third- and first-party hardware available and in development.
