Tradheli Autotune - Alpha level testing

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. :+1:

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 :slight_smile:
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 :slight_smile:

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 :slight_smile:

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 :slight_smile:
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

Hello Bill,
I re-installed the autotune-FW and made two flights today in ALTHOLD, 10 minutes and 15 minutes.
all was right, no messages in MP.
For autotune it was too stormy today - next.

my receiver is FrSky R-XSR, connected via S-BUS to the PIXHAWK 4 mini. I have the same constellation in two other Hubis, no problems.

regards Holger

Hi Bill,
today i did the autotune, all was running, no problems, no messages. I think there must be a bug in the first installation of the firmware.
first nick, then roll and then yaw.

Than adding nick and adding roll. And than a flight.

It is flying good, but it could be a litlle bit harder, especially in yaw.

with regards

Holger

@bnsgeyer
Bill,

during the past few days I have found several entries from beginners like myself who have problems with tuning their helicopters.

I am very tech and data affine, but I still have problems understanding the log files and drawing the right conclusions from them.

Again and again we beginners have to burden the experts in the forum with our questions and log files. Your patience with us is to be admired.

It is therefore twice as good if your autotune works and is soon available as a stable version.

If spring and nice weather weren’t around the corner, I would wait until your autotune is done before flying FC any more.

BR

Heri

@Steve_Mitchell I was looking through your 380 logs again. Your VFF requirements are pretty low compared to larger heli’s. I had asked that you start off with an I gain of 0.1 for these tests but realized that during the Angle P test, I don’t modify the gain to 1/2 your VFF. I think it could be why I’m seeing larger response gains at lower frequencies (<1 hz). So please conduct the pitch and roll autotune again except have your pitch and roll I gains set to 0.05. It will be much closer to 1/2 the calculated VFF gain.
Thanks
Bill

All axes tuned using stock autotune. Created/updated a share folder so I’m not spamming with individual links. There’s a google sheet in there which summarizes everything.

https://drive.google.com/drive/folders/1JZOkg4DFMECFiycaZPwPlEtyfjQNsoXv?usp=sharing

Pitch tuning with a non-zero pitch rate D went well. Converged to different values, but went well. I stopped the autotune flight with non-zero rate pitch P and D. I wasn’t 100% sure how to decipher the messages to see which ANG_P or ACCEL_MAX values it was on when I stopped, but the log is in the share folder. I didn’t try with the roll axis since the rate roll D is already zero

Interesting point with the I tune being set to 0.05 for the smaller heli. The stock autotune generally converged to 0.05 in pitch and roll.

Next time out I’ll see what info I can get in roll. Rate Roll D was tuned with ATC_RAT_RLL_FILTD set to zero, so I might be able to work on that. I’ll try set the starting I term to 0.05 as well.

Niall @Murdoch,
Thanks for the additional testing. Last night I was looking at your flights that you provided previously. Your aircraft responded in pitch and roll similar to what I have seen with my 626. So I was contemplating how to address the response seen in Steve’s aircraft.
I am glad to see that you added some rate d gain and re-ran the autotune. I will look at your data when I get a chance and give you feedback.

@picoflug thanks for continuing to test despite the FC issues you have been having. I will look at your data too.

@bnsgeyer Okay, I’ve give it a try this weekend. We have had two weeks of atrocious weather, so haven’t done any D testing for you.