Tradheli 4.2 Beta Testing has started

Tradheli users,
ArduCopter version 4.2.0 beta testing has begun. Sorry that I haven’t written sooner about this.
Currently 4.2.0 beta 2 is out for testing which was announced here. I have been working hard to finish documentation for the autotune feature that will be released with this version of software which is why I delayed announcing it here.

Here are the features that version 4.2.0 contains

  • Autotune mode
  • Improved rotor governor (requires users to retune)
  • New Collective set up to ensure consistent setting of landed collective defaults (requires user setup before first flight)
  • Cool down timer added to rotor speed controller for internal combustion engines and turbines
  • Feedforward parameter name changed from VFF to FF
  • Attitude controller parameter defaults changed to improve new user initial set up

If you are a seasoned veteran of ardupilot and feel comfortable testing beta software, please take the time to test the new features and provide feedback either here on the tradheli topic or in Copter 4.2. Below are more details on each of these changes.

Autotune Mode
New to arducopter is an autotune feature for traditional helicopters. This mode offers many options to tune the rate controller FF and PID gains and attitude controller P gain. Please take the time to read through the wiki and watch the videos before attempting autotune. It is well worth your time to understand how the tuning is performed as it is very different from multicopter autotune. You can read up about it here. Start with the preparing for tuning wiki before moving on to the autotune wiki.

New Rotor Governor
The new governor is similar to the previous one in that it maintains desired rotor speed through a proportional controller adjusted through the droop compensator and a feedforward controller that uses the throttle curve to help respond to sudden loading and unloading of the rotor system. The new governor now handles changes in environmental conditions and even changes in the desired RPM from the nominal settings for which the throttle curve was originally tuned. This is accomplished through the torque compensator which adjusts the reference from the throttle curve to maintain the desired rotor speed. The governor is designed to maintain the desired RPM within the governor range. If the RPM falls outside this range for more than 0.5 seconds, the governor will declare a fault and the throttle output is reverted back to the throttle curve. Also new for this version is the use of a torque limiter to adjust the rise of torque during rotor spool up to smoothly engage the governor. Details of the new governor and setup can be found in the wiki.

Collective Setup
The collective setup has changed to improve the setting of the minimum landed collective. This is the collective setting that the autopilot cannot go below while landed when in a flight mode that uses altitude hold to control the collective. In 4.0 and 4.1, the H_COL_MID parameter was used to specify this setting and caused confusion and some in-flight motor shutdowns. So the minimum landed collective was brought back. However unlike before where it was specified in PWM, it is now specified in degrees. With the new collective setup, the user specifies the actual collective blade pitch in deg that corresponds to H_COL_MIN and H_COL_MAX. The zero thrust collective and minimum landed collective are specified in degrees and the autopilot determines these in PWM, instead of the user. It uses a linear interpolation to determine these settings. This is a big improvement because now the defaults are meaningful and the user doesn’t have to set them if they don’t want to. leave them at the defaults and the autopilot will take care of it. The collective setup page was modified to describe this new setup.

Cool Down Timer
A simple cool down timer was added to the rotor speed controller (RSC) logic. It sets the idle to 50% higher during the countdown of the cool down timer. For this to work in autonomous situations, the Runup timer has to be set longer so the aircraft remains in idle, otherwise the aircraft will be disarmed after the runup timer counts down.

Rate controller feedforward parameter changed from _VFF to _FF
Please be aware that the _VFF parameter name was changed to _FF to align with the multicopter codebase. The functionality of this parameter has not changed, just the parameter name. One thing to remember is that any parameter files that were saved from previous software versions will not load the feedforward parameter to this new name. Therefore the user will have to either modify the parameter file or enter the FF parameter values manually.

Attitude Controller Parameter Default changes
Certain Attitude Controller parameter defaults were changed as the original defaults I found to not provide a good initial tune. The parameters whose defaults have changed are listed below
ATC_RAT_RLL_FF, ATC_RAT_RLL_I, ATC_RAT_RLL_IMAX, ATC_RAT_RLL_ILMI, and ATC_RAT_RLL_FLTT
ATC_RAT_PIT_FF, ATC_RAT_PIT_I, ATC_RAT_PIT_IMAX, ATC_RAT_PIT_ILMI, and ATC_RAT_PIT_FLTT
ATC_RAT_YAW_IMAX and ATC_RAT_YAW_FLTT

3 Likes

Hello Bill,
Just tested this beta version and the new rotor governor is way much better then before. Its engaging exactly on the desired point and staying there during complete flight. Congratulations I am very happy with it :smiley:
I have a question: How the torque compensation is adjusting to different air densities, is it checking for altitude/barometer variation?
The collective setup is working perfectly. I am still digesting the Autotune and will test this in the next days with no wind. Thank you!
Cheers!

@Pedro_Claro Thanks for taking the time to test this beta.

I can’t take credit for that. @ChrisOlson developed that governor.

No it just looks for the RPM long term changes and changes a reference accordingly. That’s why it is able to adjust for a desired RPM that is different than the RPM for which the throttle curve was tuned.

You’re Welcome! Look forward to your feedback on autotune.

Regards,
Bill

Today I was testing Autotune and it is excellent!
During the 1st step tunning the ff rates, the heli moved away a little but in the following steps, during the D&P tuning it stayed more close! The results are excellent and the heli is much smoother in the handling. I’ve been checking the tunning logs for issues and they seem to be correct as per video instructions. I’m pretty confident in this new Autotuning for now on. When I look back and count the amount of test flights I did to get the heli running acceptable, compared to now its a great leap. My congratulations, I think the Autotune will be a great revolution for Traditional Heli. :smiley:

2 Likes

@Pedro_Claro Thanks Pedro! I’m glad everything worked well. I would appreciate if you would tell me the size of your heli (450, 500, 600, 700?) and what modes that your fly it in (stabilize, alt hold or acro). Also, I would like to see your logs to see how it behaved and what choices it made for your tune. Thanks again for testing this and any comments on the documentation are also greatly appreciated.

Regards,
Bill

Its a 450 size (ALZRC 360)

Stabilize

Here you are:
Roll FF
Pitch FF
Pitch P&D
Roll P&D
R&P SP

During Roll FF was winding a bit and after a while I saw that he was repeating ( was saying to set it manually). I did set it manually.
Later during Pitch FF it finish succefully but I didnt land it in Autotune mode, so it did not record automatically, I inserted them manually after checking the logs also.
BTW during the autotunning for Pitch and Roll FF I forgot to set the P and D values to 0. Dont know if this could be an issue. In the next sequence steps for the P&D tuing I set the P and D values to 0 before starting.
The Pitch and Roll D&Ps and angular, they were recorded post landing after the tunning sucess.
My intention is to repeat the Autotune with no wind day and fully charged batteries.
Cheers
Pedro

@bnsgeyer @ChrisOlson
I’ve been exploring the new governor and noticed that when the battery is too low, it doesn’t hold the rpms. I played around with the governor settings and it seems that this phenomenon is still there. Is there any explanation for this?

holding rpms
not holding rpms at low voltage 1
not holding rpms at low voltage 2


Cheers!

Autotune experience with large helicopters

Hello,

Has anyone used autotune to tune a 700 or 800 size helicopter with more than 6 kg.

In the previous feedbacks (also already in the phase when Bill still tested with his own program version) was always reported only from 450er to 600er size.

Or did I read something over there?

I would be interested in experiences with autotune with larger and heavier helis.

Are there any?

BR

Heri

@Pedro_Claro

one question: The FC controls the PWM signal for your ESC, right?

Is it possible that the ESC can no longer adjust the speed sufficiently when the voltage drops?

Therefore not the FC is to blame for the control behavior, but the ESC?

Maybe.

BR

Heri

@heri hi Heri,
I had a user test a 700 size helicopter but corresponded with me privately. He didn’t mention anything specifically regarding issues he had because of the larger helicopter.
Is there anything in particular you would like to know?

Hallo Heribert,

Yes. When I use a 4s and setting the Governor to 2350 rpms, 15V is not sufficient to maintain that speed. If I use a 6s I dont see this issue anymore. Lowering the rpms ex:2200 or exchange the engine into higher KVs, this is not seen. Running at 1850KV is critical for a 4s. But this new Governor is really fine with the 6s and its really snappy :slightly_smiling_face:, In my case, its engaging at 2370 rpms and after 3 seconds, you can see on the screen, coming down to 2350rpms, this compensation is working. I am not certain but I think its also giving more stress to the tail mechanic parts. 2 weeks ago testing this beta in a 450, a screw in a tail part just went off, and by luck didnt destry it all. Today went out to test the Autotune during the Pitch the belt became loose and crashed (spindle shaft + blade) softly. At least the Autotune results are matching after repetition and close to my manual tuning which is great.

Liebe Grüße
Pedro

@bnsgeyer Today testing the Autotune, started by lifting off from Alt. Hold, when it was steady hovering turned the Autotune on, but it was not starting giving the “pilot overide” message.Could not understand the reason for that as I was not touching the controls. The throttle was just a little nothing above the center but steady hoovering, when I center the throtle then the Autotune start running. This is just to report this experience if someone faces the same alreay knows what to do !

Hi Pedro,
Yes, if you get a pilot override message when switch from althold to autotune, 99% of the time it is your collective that is not centered.

I had a chance to review your logs. The FF tuning didn’t look like what the code expected. it really never achieved a steady state rate in the maneuver. So it looks like the pitch axis FF gain was not tuned well. It appears to be too low. The roll axis FF gain seemed to be tuned well even though the aircraft never got to steady state. I saw in the logs that you did not use zero rate P and rate D gains for the FF tuning. I would be interested to see how the FF tuning goes if you used zero values for rate P and rate D. I’ve seen that these smaller heli’s do have a tendency not to reach steady state. The other way I could see that your FF gain was not high enough for the pitch axis was looking at the Rate P and D tuning. In the second sweep that it does, you can see that the output is not equal to the input at the low frequencies


You can see in the plot that the response peaks (green) are not equal in magnitude to the input peaks (red) at low frequencies. The ATSH.gain (blue) also shows that. it is an important check for the second sweep to see that the response and input are pretty close at low frequencies. Here is roll axis and you can see that they are nearly equal at low frequency which tells me that the FF tuning was pretty good.

For the rate P and Rate D tuning, again it looks like you had some rate P and Rate D gains already set and that affected the roll tuning. The pitch tuning still was able to tune the gains even though there were some non-zero values for rate P. The reason the roll axis tuning did not work is due to the fact that your Rate D gain was higher than the recommended value. The autotune only increases the gain for rate D tuning and when it saw that the value was already high enough it stopped tuning rate D and went on to tune rate P.

So I think that I want you to retry the FF tuning with zero Rate P and Rate D gains. Please be sure to reset your Angle P gains as well to your original values. Look at the values autotune determines for the FF gains. I think both pitch and roll FF gains should be about 0.17. If pitch FF gain is not at least 0.16 then I would just set it to 0.16 and move on to the pitch rate P and Rate D tuning. I would like to see if the FF gain changes the outcome of the Rate P and D tuning. I don’t think it will.

For roll axis, make sure it determines the FF gain to be around 0.17 +/- 0.01. Make it 0.17 if it doesn’t. Then perform the rate P and rate D tuning with the rate P and rate D gains set to zero.

please post the logs so I can take a look.

Thanks!

2 Likes

@bnsgeyer Hi Bill,

Yes, I would be interested to know what his values are for

"Maximum Response Gain,
“Minimum Test Frequency”
“Maximum Test Frequency”
“Velocity P Gain”

he has taken.

I would also be interested to know whether it was a light 700 sport helicopter or a heavy scale helicopter.

At the moment I am faced with the task of flying in a 750 scale helicopter with 9.5 kg. I have already made two manual tuning flights. Therefore, I have not come far yet. The helicopter is almost fullscale and built with much effort. It is an Agusta 109 with a four-blade rotor head. My hands are already shaking.

I’m thinking about waiting for the “stable” version of 4.2. and then use the autotune. I would like to have a few tips from pilots who have flown a similar helicopter.

BR

Heri

He followed the wiki recommended values. The default min and max frequencies should be fine for your heli.

It was a light sport heli.

Let me see a param file for this heli. Probably the best thing to do is let the autotune determine your FF gains for pitch and roll. Then you can do a max gain only test for pitch and roll. That will give me more info on how to set the AUTOTUNE_GN_MAX param.

As for waiting for the stable version, that is not always a bad idea. I have a small change going into -rc2 to provide better handling of certain situations. From my standpoint, there are no major issues that were reported on heli autotune.

Hi Bill,

On the other day before stating with the Autotune, I did a minor adjustment in the Heli belt tension, making it more loose. By executing the Autotune for the Roll FF it ended successfully, (0.16 is what I use for manual tunning) but after during the Pitch FF something severe happen, and it crashed (minor damage). At the moment I thought it was related to the belt, just today when I was reviewing the logs I noticed per RPM log that it abruptly ended. The last message was recorded at 17:17:25 then apparently reboots and the new messages appear in the next log ~2 seconds later at 17:17:27.

Can we say that Ardupilot during the Autotune halted and the watchdog forced a reboot?

Roll FF finish
Autotune Pitch + Crash
After Crash reboot

BR,
Pedro

@Pedro_Claro That is my first inclination. I will check it out tonight and let you know. I assume this was firmware loaded from mission planner and not firmware that you modified.

Regards,
Bill

Exactly this was straight forward upgrading from the stable to the 4.2 beta since the announcement. Thank you in advance!
Cheers, Pedro

@Pedro_Claro First of all, thank you for testing and I am sorry that you had this issue but glad it was only minor damage.

I was lucky enough to have @andyp1per quickly respond to my request for help on this issue. The watchdog did not reveal anything regarding the issue but Andy noticed that you were running 4.2 beta 3 and were using H743 Matek board with flash storage. There was a bug that affected the H743 using flash storage. This bug was fixed in 4.2.0-rc1. Here is the excerpt from the release notes.
c) STM32 H7 flash storage bug fixed that caused re-init on overflow
d) @SYS file logging fixed
e) Timer bug fixed that could cause a watchdog on boards using flash storage

I assume it was either c or e that was the issue with your board.

Recommend you upgrade to 4.2.0-rc1 and continue with your autotuning. If you have any questions, don’t hesitate to post. thanks again!

Bill