Holger,
Thanks for figuring that out and providing the logs.
Out of curiosity, would you go back to the log bitmask settings that you used when the motor stopped. Then do the same test on the ground with the rotor blades and tail rotor blades removed. I’m wondering if it had something to do with the unusual LOG_BITMASK value.
Thanks,
Bill
Hello Bill,
yes, I can do that. I will report.
Holger
Hello Bill @bnsgeyer
Decided to check again the autotune, knowing your advice to halt flights, but taking into account the failure possibility and the fact that i have another two 450 helicopter, decided to take the chance.
Weather was a bit better, less gustier, hopped we will get some data from this flight.
Heli Size: 450
Number of main rotor blades : 2
Main Rotor Diameter : 0.72 m
Tail Rotor Diameter : 0.16 m
Takeoff Weight : 0.98 kg
Rotor RPM : about 2500 that without me commending jumped to 1900 and back, check the RPM reading
had time checking only the pitch tune.
Stayed the whole flight in autotune mode, but due to the wind drift had to steer to keep flying on the safe zone
checked the data, looks similar to the previous flight, could you share the meaning of the parameters in AHR2 and ATDH ?
Tried to find the reason for the rotor RPM change, CH8 was not changed, using governor mode on the ESC… any idea ? it might be connected to Holger phenomena ? the only thing i have in mined (besides ESC misbehaving) is erroneous write that overlaps the channel PWM data without affecting the RC out CH8 parameter …
.bin file:
https://drive.google.com/file/d/1zaqHvy0sBGH5I3P1xXk9yHcJEJC9f16z/view?usp=sharing
best regards
Zvika
@ZvikaF I will be pretty busy this weekend and won’t be able to respond much. But thank you for continuing to test. If you look at Steve’s data. Look at the ATNH, that is more of summary of the autotune flight and you can just view in a table. The ATDH is the time history of the testing. For the first test it is angular rate and for the second test it is angle. So you see a bunch of single oscillations separated by a second or two of stabilizing. In the second test you will see it oscillating back and forth for about 10 oscillations at a magnitude of approx 5 deg. If you aren’t seeing that then the autotune is not finding a good VFF gain. I will look at it when I get back.
Thanks!
Hello Bill,
today with the “old” params testet, I hooverd 10 minutes in the garden, all was ok.
Then the params you want (176126 + fast + PID =180223) and flying in acro and stabi 12 minutes - all ok, too.
For autotune it was too windy - next time.
regards Holger
@picoflug and @ZvikaF I appreciate you both continuing to test. Holger I will not get to look at your data until next week. But it is interesting that you haven’t had anymore problems. One thing I learned when checking for the issue you had was that I was using an old compiler. Tridge said that it was unlikely the compiler had anything to do with this problem but I would like to make new versions of the firmware and distribute them. Again it will probably be early next week until i do.
I don’t know what the added risk is but if you want to wait until I distribute the firmware compiled with the updated compiler, I understand.
Hello Bill,
if I have time and no wind, I will test it again. When I’m flying low, there will be no damage, if the motor cuts off.
Of course I take then your new firmware.
Holger
@picoflug @Murdoch @Steve_Mitchell @ZvikaF @DrKnow65 @LoopZilla @JoshW
I am still investigating the cause of the motor shutdown for @picoflug. While I was consulting with Tridge, he told me that my compiler was old and I should update it. He felt it was very unlikely that an old compiler would cause this issue. However I felt it necessary to update my compiler and provide you firmware based on the updated compiler. So I have updated the github release page with firmware built with the updated compiler. Please be sure to update your firmware before testing.
Unfortunately, we have not narrowed down the cause of the motor shutdown. Tridge feels it is unlikely that the heli autotune changes caused the issue. The flight controller had a hard fault which caused a watchdog reset. With this reset, the watchdog places a string in the next log that allows developers to trace within lines of the object code when the hard fault occurred. So it was not within my new code when this happened which is why he doesn’t suspect the autotune code. So I will leave it up to you as to whether you choose to continue testing with this firmware. I will follow up with Tridge this week to look at the log files @picoflug provided to see if there are any additional clues. Holger has flown a few more flights since then with no issues (not in autotune though).
Just trying to give you all of the facts so you understand the risks.
Github says the source is new but the compiled code is eleven days old ???
I just uploaded the new firmware. So I am not sure why it is saying that
This might be unrelated to the autotune firmware, but I just had an intermittent motor shutdown in stabilize mode while running the autotune firmware. I’m posting the logs from the field, so I haven’t been able to confirm much other than the current went to 0 which suggests both the main rotor and tail rotor stopped. Log attached - shutdown was at 17:14:38 for about half a second. Both motors spun back up and I was able to land it without any damage.
This was probably the 3rd flight in stabilize flight mode running the autotune firmware.
[Edit] Link attached for real: https://drive.google.com/file/d/1UryxqcwtRvoOJEX1J_KZWuKZ8P-cYRrE/view?usp=sharing
@Murdoch sorry to hear about that. Glad you were able to land safely. Please provide the very next log where you armed the aircraft. If you didn’t fly again then power up and arm the vehicle for about 30 seconds. Then disarm and post that log too. That will contain the watchdog reset data.
Thanks
Bill
Disregard the request for the log immediately following the log where you had the motor stop momentarily. It does not look like you suffered any type of watchdog reset. At the code level, I’m still showing Servo8 out to be unchanged during your motor shutdown event. Not saying that it is not hardware related but at first look. I don’t see anything from the log that indicates the motor was shut down
I should correct my earlier post - I was in AltHold not stabilize when the motor shutdown.
There’s nothing I can see that would indicate it was a commanded shutdown or that there was some massive power system failure (battery voltage, board voltage, servo voltage, etc). I don’t have an RPM sensor so the only logged evidence of the motor shutdown is the current going to 0.
Just ran a bench spin up without blades and everything seems fine - no loose connectors or any obvious damage to power system hardware. There were no watchdog messages in the bench spin up log file (the first time it was armed since the incident flight).
I’ll try to get out again tomorrow. Either I come back with good autotune data or more data on what could be causing the motor shutdown 
Hi Bill @bnsgeyer
Update:
I am still running the original Auto-tune firmware on the 380 for a couple of weeks now (more than 2.5 hours of flying) and haven’t experience any shut downs or unexpected behavior.
My 770 gasser is ready for flight testing but the only thing holding it up is I can’t get the hall effect sensor to read/work. I will post in another RPM related post about the issue. I suspect it’s to do with 4.0 as I have it work on 3.6 with the same param’s.
Niall,
Thanks for checking it out further. I did make one mistake in my earlier post. If you would have a watchdog reset then another log is started after the controller reboots. So I was incorrect to say that you would have to arm the aircraft again to get the watchdog message. You should have two log files from the flight (the one up until the watchdog reset and then the one after the flight controller reboots from the reset). Just so you know if it ever happens to you.
Regards,
Bill
Hi Steve @Steve_Mitchell
Thanks for the update. Have you done anymore experiments with the autotune feature? I was wondering if you tuned your rate D gain for pitch and roll and then tried to the autotune again.
As for the RPM sensor, which sensor are you using? and what board is it being used on? Just want to make sure the port and pin are correct. I would have to ask Tridge to make sure there isn’t a conflict. I’m told 4.0 has more stringent criteria when it comes to the GPIO.
Sorry I can’t be more help.
Regards,
Bill
Bill,
No, I haven’t played with the autotune other than what was requested. I’m happy to a do a lot more test. I’ll try some D gain with the auotune this weekend. Anything else you would like me to try?
The RPM sensor is Align Beast X (The one Chris recommends) with Vcc and GND swapped and pull up 360ohm resistor between Vcc and signal. (As per this RPM Sensor Wiki thread. RPM Sensor Wiki - Knowledge Share). I have had it on the oscilloscope and works fine and it outputs 0 to 5v steps like this picture with a passing magnet.
Hex Cube black params V4.0.6
BRD_PWM_COUNT = 4
Relay_Pin = -1
RPM_Max = 10000
RPM_Min = 10
PRM_Min_Qual = 0.5
RPM_Pin = 54 (Sensor plugged into Aux 5)
RPM_Scaling= 1
RPM_Type = 2
RPM displays -1
I have had msg “RPM: failed to attach to Pin255” Not sure what that means.
If I can get the RPM sensor working, I"ll be able test the autotune on the 770 this weekend too.
Regards,
Steve
Update:
Got RPM hall sensor working tonight but still get warning message “RPM: failed to attach to Pin255”
Thanks for the update Steve. How did you manage to get it working? I’ll see if Tridge has any idea about what the error message means.