The YAPPU telemetry displays “Autotune: success” and in the next line below that is “Pilot override x4”. Unless you are really looking for it, it’s hard to see. I found you can hold a a very small amount of cyclic to reduce the drift without the pilot override kicking in) and the tune happens way faster. As Bill said, low wind day is best. Had one tune take 14 mins and then the next less than 5mins. The less input you do the faster it will tune.
I will look at YAPPU LUA and try to add aural annunciation for the Autotune stages, it was a bit hard on the sun with a light helicopter that needs attention dew to the wind and the tuning procedure to see the small notifications.
Checked your logs (better to upload the .BIN files, as they have the same data in a smaller volume)
found that the behavior is totally different, might be due to something wrong done by me,
or the difference in the target compilation ??? @bnsgeyer needs to check it out.
Wonder if once you bail out the autotune if you need to land and start all over again, or can continue by entering again the autotune mode (this might be the cause for the difference)
will try again in calmer day with the proper telemetry setup
It’s not the target compilation. I think in all of your axes, it never got past the VFF determination. Probably because of the windy conditions.
As for what would happen going out of autotune and then resuming autotune in the same flight, it shouldn’t start completely over but it might start over for the test that it was doing (ie VFF or Angle P). I would have to check that more closely to see.
@ZvikaF Just remember that only works for the second test (angle P test). For the first test (VFF) where it cycles once, if you touch the sticks it will stop the maneuver until you center the sticks again.
@bnsgeyer, had the impression that the test had shifted during the flight, it reminded me the autotune procedure I had done many years ago with my first APM multirotor.
Looked at the data, can see different induced oscillations, but can not deduce if the procedure was advancing.
What is the meaning of “Tune Step” ? it starts and stays at 4, while “Cmd” and “TRate” seems to change.
I see RFF (VFF?) change during the test, but RP and ACC remains zero, SP stays 4.5 on all tests.
Hello, tried today in almost no wind.
Heli:
500 size
Rotor 96cm
1700 rpm
Tail 18,5cm
Weight 1800g
It flew quite well even with the basic settings.
Then Althold and Autotune on roll.
It makes some stronger movements to the left and right. Then it made only very small movements, but did not stop.
I interrupted and made two more attempts, the same movements.
On the fourth flight, suddenly the motor was turned off. It came straight down and stayed intact.
Error message: “motor interlock errors 0 x 800”.
Then flew with new battery, in “acro” without autotune. after about 1 minute again motor off with the same error message. This time small damage.
Quickly repaired at home and hoovered a few minutes in stabilize and acro - all good, no error message.
I am now of course afraid that this will happen again.
Previously I had the motor not via “HeliRSC”, but via “passthru”, so something like this could not happen.
Holger,
I am sorry to hear about the trouble you were having with the firmware. The files that you provided are not the correct format. You need to send me the *.bin files. Please send me these files as soon as possible. I would like to determine what happened and why the motor suddenly turned off.
Hold off on flying this firmware until I can dig into @picoflug error causing his motors to shut off in flight. Hopefully he can get me the logs tomorrow.
@picoflug are you certain that this was the error message? I have searched the source code and can’t find this expression. The way your message is structured, could it have been something like this
Internal errors 0x00800
If you can get me the *.bin for a flight where the motors shut off then I can probably determine why.
Hallo Holger. Wenn ich mehrere Testfluege mache,wonach ich mir die .bin files anschauen moechte, schreibe ich mir nach jedem -disarm- die Uhrzeit auf und was ich spaeter sehen moechte. Ich kann das garnicht anders in meinem Kopf behalten. Mit der Uhrzeit finde ich dann sofort den richtigen file.
Dieses ist nur ein kurzer Hinweis, wie ich es mache. Ich hoffe, der Bill findet was dein Problem ist!
Viel Glueck.
Hi Holger,
It appears that your had a watchdog reset. I don’t have an answer as to why but hopefully I will find out soon.
Using passthru instead of HeliRSC would not have saved your heli. When a watchdog reset occurs that means the entire flight controller reboots just like rebooting your computer. So it takes a couple of seconds and you may not bee able to save your heli.
Could please send me your telemetry log files for that day. They would be in the same folder where your *.bin.log files were. These files would have *.tlog. Send me all of them for that day.
@picoflug I spent some time working with the other developers to determine what caused your in-flight shutdown. They think that the shutdown was most likely not a caused by the Autotune code. But they wanted you to do some additional testing to determine the cause of your in-flight shutdown. They think it could be caused by bad power because it has mostly occurred in flight. If there was a bug in the operating system then it would also occur on the bench.
So here is what we would like you to do.
reset your LOG_BITMASK so that the following are checked. if you look at the value for LOG_BITMASK it will say 176126.
ATTITUDE_MED
GPS
PM
CTUN
NTUN
RCIN
IMU
CMD
CURRENT
RCOUT
OPTFLOW
COMPASS
CAMERA
MOTBATT
remove the main rotor blades and tail rotor blades
Arm the heli and run motor as long as you can with your battery (this assumes your heli is electric powered) Please verify that it has an electric motor so I can pass that information to the developers.
While you are doing this test, check the case of the PH4-Mini to see if it is getting really hot (if you can’t keep your fingers on it then it is hotter than 60 deg C)
if your motor stops unexpectedly then it is probably caused by the same failure that occurred in-flight. cycle power to the controller and arm the heli again. Let it run for about 30 seconds and then disarm. Then post the *.log file where the engine shut off unexpectedly and the file after you cycled power and armed the controller again.
Hello Bill,
thank you, I will try it. Where the filies i sent not to use?
I have the PIX now longer than one jear in this Heli an had never a problem. At least with 4.1.0 - all was good.
As you say it could be a reboot, because in the second case additional to the “motor off” there was no stabilisation more: the tail runs away and the swashplate did’nt stabilize.
As I recognize I think in the first case it was only “motor off”, stabi was working an I could steer the throttle (in that 2 seconds…)
Hallo @FRED, guter Tip. Allerdings habe ich noch nie mit den logfiles gearbeitet, da müsste ich mich erstmal einarbeiten / before I never worked with logfiles.
Holger, the files you sent were useful however I think you misinterpreted my instructions or they just weren’t clear enough. I wanted you to add the PID and fast attitude logging to what was already being logged as defaults. You removed all of the data logging and only selected PID and fast attitude. So we weren’t able to do any additional analysis beyond determining that it was an error that occurred at the system level. Like I said previously, that error could have been caused by bad power.
Thank you for the additional information on what firmware was loaded prior to my firmware. That could be helpful.
When you post your log files from this test. If there are files that only have .bin as the last 3 letters of the file name, then only post those files. If not, then post the files that have .log as the last 3 letters of the file name.
Thanks!
Hello Bill,
I did as you say: LOG_BITMASK on 176126. Now there are no .bin - files, look at the picture what I have now. The files are in the DROPBox.
I runned it without blades for 25 minutes (1/3 of Accu). The PIX-case had absolut normal temperature, not a little bit warming. Then again for 30 seconds - same.
Then I hoovered for 5 minutes - all was right.
No messages in MP.
But when connecting the Heli to PC without Accu, only via USB, came the message: “board (4.2V) out of range 4.3 - 5.8V”
Holger’
Wenn du den Heli mit USB an den computer anschliesst, benutzt du Missionplaner um die Daten von dem microSD chip herunter zubekommen. Oder holst du den chip aus deinem Autopiloten und importierst du die log- files auf dieser Weise?
Du hast vorher mit LOG_Bitmask - 176126 bestimmt, was der Autopilot speichern soll waerend des Fluges. Nachdem testflug must du die daten vom Autopiloten in deinem PC importieren. Dabei wird dann der - BIN.File und text file in deine PC Datei gespeichert.
Wenn ich mir deinen Daten File oben ansehe, ist tatsaechlich kein BIN.File vorhanden. In der oberen Rubrik : Type, wuerdest du dann sehen welcher dieser oder diese BIN.Files sind. Warum ist in der Log datein oben kein BIN.File? Hast du nicht richtig importiert mit MissionPlanner oder der Autopilot hat keinen .BIN.File aufgenommen. Ich schreibe das in deutsch um sicher zugehen, dass es richtig von dir verstanden wird, Ich gebe dir noch einen extra Hinweis, benutze nicht das wort Akku. Es wird nie von uns english sprechenden in der Modelfliegerei benutzt. Wir reden nur von Batterien.
Ich schalte meinen PC jetzt aus, es ist hier nach Mitternacht. Viel Glueck.