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.
It dawned on me that RPM_MIN was set at 10. So, I wasn’t going to see anything by just tapping a magnet against the sensor. I then attached two magnets opposite each other on a small cordless drill and spun it up.
As you can see at the bottom of the screen grab. I got an RPM reading of 1338 with the cordless drill spinning the magnets. The warning message “RPM: failed to attach to Pin255” still appears though. I did try a few different versions of firmware on the same airframe to try and narrow down what might be causing it.
ArduCopter V3.6.8-L1Nav, RPM worked fine and did not display the warning message. 
Helipilot v21-beta-cubeBlack, RPM worked fine but got the warning msg “RPM: failed to attach to Pin255”
ArduCopter V4.0.6-ATNH-rc1, RPM worked fine but also got the warning message “RPM: failed to attach to Pin255” (see below and log file.)
https://drive.google.com/file/d/1woi2qMQ5JRahXcNtGdXfwZVsjnE8S4b9/view?usp=sharing
It looks like something in ArduCopter V4.0 is causing it. After Googling it. It would seem Matt @IAMMATT had a similar problem with SITL.
Hello Bill @bnsgeyer
Had the opportunity to try Autotune in pretty calm day, wind breeze of about 2-5 Kts.
Mishap on the second flight, do not know if it is autotune related ?!
First flight: had the heli pointing into the wind at upwind position Alt Hold mode, started the autotune, the first steps are really hard on this light model, as back sweep made the nose want to turn downwind and the movement was a bit rough, i suspect you have to take into consideration heli type (disk and weight) as the procedure was jerking the heli about 100 meters away and i had to regain control and fly it back.
YAPPU telemetry was beeping and calling status but had to land before finishing the procedure.
This time I see change in tune mode going up from 4.
following is the bin from the first flight:
https://drive.google.com/file/d/1WoZq7Hy5cj1hocXTuybnt238dS1te_lz/view?usp=sharing
The second flight was a bit awkward, moving to Alt mode made the heli unstable mostly on yaw.
tried few times and decided to return and land, close to the landing point. but still over the field the heli started to loose altitude, changing mode to stabilized did not help and had to semi autorotate to the high crop field. disarmed the motor after touching the crop, took me some time to fined the heli, luckily i could disarm and arm again and hear the beeps… otherwise i probably would have lost it
had some minor damage, snapped horn, clogged autorotation bearing, and swollen main gear.
suspected the motor or ESC, took off rotors and checked … all seems fine.
Checked the data and could not find the reason, all seems fine, RPM is a bit law, CH8 seems good, current looks stable… ???
following is the bin file:
https://drive.google.com/file/d/13Z-dtGwtACPlcld0DFLhPNOnSlDMyTbn/view?usp=sharing
The only thing that i can think off is memory overrun, programming nightmare
hopefully all will be fixed soon and flying again,
@ZvikaF I’m sorry to hear of your mishap. I agree that I don’t suspect this to be caused by the firmware.
I was looking at your logs and I noticed that your hovering collective is very high (around 0.75 or a little higher). Also it seems your rotor speed is low for this heli size. The rotor speed for your flights was around 1800 +/- 150 RPM. That is a very large variation in rotor speed especially if it was being governed by the ESC. Typically they can keep it pretty tight.
This is from your second flight. you can see the collective out (CTUN.ThO) bouncing off of the max collective. You will also notice the RCOU.C4 hitting its max value which is basically your servo running out of throw and probably why you thought the yaw control was unstable.
As for the unexpected landing or settling with power, I don’t know what caused that. One thing that I did see when looking at your swashplate set up is that you have a very unusual swashplate set up. I never intended for users to have the servo trim values as far from 1500 as you have them. And I don’t know how that affects your swashplate response. However, looking through my swashplate setup guide, I guess I don’t say that your trims should be all around 1500 PWM. The mechanical setup of your swashplate should start with servos being in their neutral position (1500 PWM) and the arms should be perpendicular to the linkages that are connected to the swashplate. It is assumed at that point that all of the linkages connecting the servos to the swashplate are the same length and so the swashplate should be nearly level. Then you would adjust the SERVOX_TRIM value to get the swashplate exactly level (i.e. perpendicular to the main shaft). Thus for most of my setups my swashplate servo trims range from 1480 to 1520. Next you would then adjust the H_COL_MIN and H_COL_MAX to obtain the desired collective pitch range. If your H_COL_MIN and H_COL_MAX don’t encompass 1500 PWM then you probably want to adjust the length of your linkages. I normally like the collective pitch for 1500 PWM to be nearly in the center of my collective pitch range. This ensures that I have a nice linear response for my cyclic pitch and roll with little coupling to collective pitch.
Hopefully this makes sense. Please make sure your swashplate setup is fixed before flying again. I really don’t know how your setup would affect swashplate behavior. I suspect you are seeing a lot of coupling from roll and pitch inputs into collective and vice versa. Also, I would recommend increasing your rotor speed until you are hovering with around 5 deg of collective pitch. Thinking about this more, if your hover collective pitch was too high (greater than 7-8 deg pitch) then you probably were settling with power especially if your descent was too vertical. It is very common for helicopters to get into vortex ring state which is essentially the rotor ingesting its own wake in a vertical descent.
2 Likes
Thanks a lot Bill for your elaborating answer @bnsgeyer
Can not figure out the governor ESC mode, RPM set it is commanded via RC8 channel, which is kept steady by the transmitter setup, but still getting RPM setpoint fluctuation from flight to flight, and sometimes setup point changes during the flight.
I had flown this heli setup eventless for some hours now, the only change done during the last flights is dialing down the gains according to your specifications.
opted out downwash vortex, as the sinking started on forward flying.
Agree with your thoughts that all came from low rotor RPM.
Trying to figure out how the governor mode works, peculiar, going to idle up 1 and 2 while hovering usually end up with lower RPM… as it happens with different ESC’s it seems to be inherent thing ?!
Mechanical and swash leveling was done per the basic instructions, and was tweaked a bit to compensate drift.
Thanks again for your work and help, will be up in the air shortly
What esc are you using? I assume you are using the RSC mode 1 so you can change rpm settings during the flight? And your esc is connected to servo output 8 on your pixhawk?
I highly doubt that the ATC gains that were changed had anything to do with your esc issue. Your esc governor relies only on the channel 8 output and that remained unchanged during the flight.
As I said, maybe the wiki isn’t explicit enough. Please set up your swashplate per my instructions above.
The ESC brand is YPG (might be YEP OEM) https://www.aliexpress.com/item/1583156481.html
RSC MODE 1 on channel 8.
I get the same behavior from the original Align ESC on the other two 450 helis,
You’re right, mentioned this for the lesser stability encountered flying.
will check again, to my best knowledge, setup procedure was done as you wrote above, my most strict part was mechanical, keeping 90 deg on mid servo point, horn position restriction moved it from 1500. during setup flight had to trim the swash a bit to stop lateral and longitude drifts, did it by changing servo mid point, instead of mechanical adjustments, in order to keep the movement coherent,
Well when I looked at your servo1 and servo2 trim, they were around 1100-1200. So not sure what is going on there. Did they somehow get unintentionally changed? Or do you remember having to set them that low to achieve the desired swashplate setup.
You are right, checked my earlier parameters again:
SERVO1_TRIM,1575
SERVO2_TRIM,1212
SERVO3_TRIM,1150
My other heli (#3) has better trims:
SERVO1_TRIM,1475
SERVO2_TRIM,1480
SERVO3_TRIM,1460
Excellent point, thanks
have to repeat alignment process due to servo horn breakage, might explain some discrepancy behavior
Completed the pitch/roll autotune successfully. I noticed the two pitch autotune flights converged to pretty different values of accel_max and ang_p so I’ve uploaded two samples. Will keep progressing with another roll, yaw, and into the autotune with rate P/D.
Heli Size: 280
Number of main rotor blades: 2
Main Rotor Diameter: 0.63m
Tail Rotor Diameter: 127 mm
Takeoff Weight: 1.2 kg
Rotor Speed (RPM): 3300-ish (55 hz peak on the FFT)
On a side note, just wanted to confirm the intended behaviour of the tuning maneuver during the VFF tuning. It’s pretty snappy at the exit of the pitch/roll maneuver - see attached image. The target pitch angle is held at +18 deg while the target pitch rate goes to -50 deg/s and the vehicle pitches down accordingly. When the constant rate portion of the maneuver completes, the target pitch rate snaps to +160 deg/s to bring the pitch angle (now at about -20 deg) back to the target pitch angle of +18 deg. Makes sense considering that you want a constant rate command.
Pitch (1) https://drive.google.com/file/d/1e83i4N_a0XOo9ukyMrJrKTNgiL_v48aL/view?usp=sharing
Pitch (2) https://drive.google.com/file/d/15RMf_cIEvF2COFwIas-cUozqfWXrraGW/view?usp=sharing
Roll: https://drive.google.com/file/d/1EzpuIB_M9Ai--toVBBtc1NCM2qCTnG1h/view?usp=sharing
Hello Bill,
tried today with the new FW. Was good and bad.
Unfortunately I had not looked more on LOG_BITMASK, I think there were the wrong parameters.
The first flight with Autotune was good (roll), he did everything and after landing immediately switched off the engine. And also saved the values.
On the second flight (pitch) it also started to oscillate, but then the motor switched off again ( =motor interlock).
Then flew again, after 10 sec. Motor off (= crash detector).
then I deactivated the crash detector.
Then flew again, without autotune, after about 30 sec. motor off again (=internal errors (0x800).
Fortunately only a small damage.
Maybe you can still do something with the files.
Holger
Holger,
I am sorry to hear of your problems. In order to completely rule out the autotune firmware, please load the stable version of 4.0.7 and see if you get a motor shutdown.
I will consult with @tridge with the data you provided. Maybe it will give us more answers.
Thanks again for your testing.
@Murdoch Thanks for the data. Yes, I know the return to level is pretty abrupt. It doesn’t look that bad on a 600 size but I’m sure it is pretty snappy on a 300 size. I can work to make that less abrupt. I have been working on another version that will identify the max rate D and rate P gains and tune rate D. The biggest issue with those tests is maintaining trim and not having the aircraft run away while it does the oscillations. It is easier with the angle P because I’m using stabilize commands to perform the dwell and I can just add the pilot command on top of it. With the max gain and rate D test, the inputs are rate commands and it is more difficult to superimpose pilot commands especially when it transitions from rate commands to attitude commands. So I have been working to have it hold trim attitudes better during the dwells. I hope to test that out this weekend. I will look at your data as well. Thanks for testing!!
@picoflug I had the log file analyzed by another developer. He thinks there may be an issue with the interrupt request handling. We need more information on how the RC receiver inputs are given to the flight controller. please provide the receiver manufacturer and model and which port on the flight controller it is plugged into. Also please let us know if you are using a PPM encoder between the receiver and flight controller or is your receiver providing SBUS or some other summed PPM signal.
I would recommend that you stop flying 4.0.X firmware in your PH4-mini. There is something about your setup that may be causing this issue. It seems like you don’t have any problems with 4.1-dev since you reported that you have flown many times on this firmware with no issues.
Thanks,
Bill