We recently had a tricopter running arducopter 4.0.7 firmware that shortly after takeoff climbed over 800 meters until the message EKF primary changed: 1 showed up on the log. The operator commanded zero throttle input on and off which seemed to slow it down very slightly from looking at the current draw. They were also able to make small roll and pitch adjustments to move it closer to a large field but it would not stop climbing even switching between flight modes. Once it switched EKFs, the operator was able to slowly bring it back for a landing.
I’ve attached a link to the .bin file below. I haven’t seen anything like this before, but I was wondering if any of you have maybe seen something similar?
It helps you, your users and us developers, if you update the FW to the latest stable version.
The bug you have found (if a bug) has probably been solved already.
Take a look at you vibration levels, they are probably above the limit. If that is the case you need to fix the hardware as well.
Based on the attached log, the vibration levels were small enough (well under 3 for X, under 10 for Y and Z) for the whole skyrocketing part. So vibrations are not much of a problem.
The funny thing is, I am also coping with “skyrocketing” with my ArduWhoop, which runs the latest firmware. Flying in Stabilize is kind of OK, although gyros drift somewhat, but switching to AltHolt forces it rising with maximum thrust. I have not found what causes the issue, except that it reports ridiculously high vertical speeds (something like -300 m/s), whereas the barometer seems to be pretty much OK.
I, too, have no idea for what exactly is happening. The log is attached, just in case.
The real problem is the craft was doing as it was told - the altitude was increasing because of RCin3 Throttle - so you might have a mixing problem in your transmitter. I couldnt relate that throttle channel going to maximum, or going back to minimum, to any other RCinput so it could be related to some switch or other action on your transmitter that is not sent as a channel output of its own.
You only have Loiter (and Brake) set up as a flight mode - you really need Stabilise and probably AltHold too. With Stabilise you would have been able to bring the craft down quite easily if it really was doing a fly-away. In this case you would still have a problem though.
Move Brake to a separate switch maybe.
Also please configure the BAT and MOT_BAT params via the Initial Parameters section in MissionPlanner by entering your battery cells and chemistry. There will be a bunch of params generated, but you only need to accept the battery related params.
You might be able to lower MOT_SPIN_ARM to 0.12 or less, and raise MOT_SPIN_MIN to 0.15 - but this is not critical, just me being pedantic.
Maxim, your problem is totally different.
I would seriously consider resetting all params to defaults and starting over, just change the absolute minimum number of params using the Initial Params in MissionPlanner and the Tuning Guide.
Maybe even load Rover or Plane firmware, then reload latest Copter firmware.
CTUN.Alt is going crazy, I dont know what that is caused by, and all other altitudes start changing (some as they should), along with Throttle Out, when you switch flight modes.
Yes, this one does not have a GPS, since this is a 60g whoop (including a 850mAh battery and a HD recording camera), and it really struggles. (Since that crash apparently killed the camera, I will be switching to a lighter FPV setup without recording 4k, but still…)
I wonder what can be the source of such a mess. The barometer reports sane values. One can think of vibrations as well, but they are also not too large (until you switch to AltHold and your throttle goes to eleven). In-house testing resulted in the same behaviour (so no wind messes with the craft).
Since the target is new (JHEMCU-GSF405A), may that be some low-level code-related problem that manifests only on rare chips? The F405A processor is not new, however.
Time ago with obviously an old version I had a copter climbing fast, which I stopped. The rangefinder had a cable broken, and essentially (as appeared on log) it was telling the FC that it was at 0m height, so it climbed. Possibly the barometer and GPS would later inform of the correct altitude, but I stopped it before. So at times there are simple reasons for failures like these (and the software improves to cover them).
I haven’t emulated the failure (disconnect cable) with new software; it would be an interesting test to do, as well as what would happen it the cable breaks after takeoff.
