Tradheli Autotune RC2 - Alpha level testing

Tradheli users,
I am prepared to start testing my next release of tradheli autotune. This will include feedforward, Rate P, Rate D, and Angle P tuning. Just a reminder that this is higher risk testing due to the developmental nature of the code. I have completed extensive simulation and some actual flight test of this firmware. It is based on Arducopter 4.1.0 rc 7 which is not a stable release of 4.1.0 but it is very close to being complete with beta testing. I will understand if you have concerns about testing this since it is not based on a stable version of Arducopter.

I have created testing procedures and am creating a guide on log analysis. This version should provide the tools necessary to achieve a good tune. After we learn a little more about what is considered a good tune. I can modify the code so there is not so much analysis on your/my part.

Please respond to this thread if you are willing to test this and let me know what board you are using. I hope to have everything ready to go later this week and will provide a link to obtain the firmware and testing procedures.

Pinging the users that were interested and conducted testing in the first round
@JoshW @picoflug @Murdoch @Steve_Mitchell @ZvikaF @DrKnow65 @LoopZilla
@picoflug

3 Likes

Color me interested.

Great news Bill @bnsgeyer

I will participate, Pixhawk FC

Hey that’s great to hear, thanks for keeping this going! Count me in. Still using the cube black. Looking forward to seeing the results.

Hey Bill,

That is great news. Count me in.

FC board: Fmuv3 and Cube Black

SM380

@JoshW, @ZvikaF, @Steve_Mitchell, @Murdoch Autotune Testers,
here is the link for the release of the heli autotune. Please be sure to follow the instruction. I have added some autotune parameters to this version and upgrading from the previous autotune test version, even if you have loaded a stable version since then, could cause the default values to be overwritten by what is in the eeprom. PLEASE SET AUTOTUNE PARAMETERS IN ACCORDANCE WITH INSTRUCTIONS.

I will follow up tonight and provide a log analysis guide.

Look forward to your feedback!

Regards,
Bill

Great news, will be checked soon when wind is calm.

I have on all my helis
ATC_RAT_XXX_FLTE 20
ATC_RAT_XXX_FLTT 10

was i wrong ?

Thanks for your hard work @bnsgeyer :slight_smile:

I have been advocating for minimizing the use of filters especially those ones and also ATC_RAT_XXX_FLTD. They cause time delay and are only meant to be used to reduce the noise in the control signals. So if the notch filter removes most of the noise then don’t use these except FLTT. That I recommend to keep and set at 20 or 50 hz.

Thanks!

OK, thanks for the prompt answer, time delay is a good reason, will change all as advised.

Hello @bnsgeyer
looks like there is a slight Typo error in the Autotune document.
Third page, line before the last one, i suspect you meant ATC_RAT_YAW_ILMI :slight_smile:

@ZvikaF thanks for sanity checking that. I will take a look later and make the correction.

@ZvikaF Are you sure you aren’t looking at the previous document. That was an error I made in the original version of the first document for the ATNH-rc1 version. I checked my links and they point to the correct release and document.

Testers @JoshW, @ZvikaF, @Steve_Mitchell, @Murdoch
Although I put ATC_ACCEL_Y_MAX as 27000 in my instructions, I think we could multiply that by 4 for your initial testing. I don’t know where this original value came from but I think it was derived from multicopters who have a much lower yaw acceleration capability than tradheli’s. At a minimum I would suggest at least doubling it.

It won’t affect the rate P and rate D tuning. It will make a big difference in the angle P tuning

EDIT: I added the analysis guide to the release page.

@bnsgeyer You are right, I was looking in the old doc, now I recall I have seen this before, sorry. :frowning:
I will try ATC_ACCEL_Y_MAX = 108000. ( gets out of limits error on MP)

Great job on the analysis guide (Power Point) :slight_smile:

As for the autotune procedure: do you want us to clear the resulted saved parameters from the previous tuning step / Axe ?

No, let it save the tuning values and continue with the next step. And you can keep tuning values as you tune the other axes too. That is why I removed he statement from the tuning instructions. I think this will be able to provide a full tune. But it has to be done in steps for now.

OK. will do … a bit later than scheduled …

Had some mishap today, probably not connected to the autotune.
installed the new FW, checked hoovering on my confined garden, all seemed well, then decided to see how the heli handles on alt hold takeoff, had some jump up at the previous flights, checked again H_COL_MIN / MID / MAX and fine tuned them.
at the following takeoff had a nasty jump, succeeded evading the house roof but ended up hitting nearby tree shade, needs new main gear, blades, main shaft, LG… horns… nothing special :slight_smile:

it is probably something wrong i did, can not find it.
stabilized mode is ok and controllable, checked altitude command and could not figure it out.

here is the link to the bin file
https://drive.google.com/file/d/1Odg4LMHhEI8Xvz8RQab3p5T4wM1PMXfZ/view?usp=sharing

@ZvikaF I am sorry to hear of your crash. hopefully you’ll be able to get back into the air soon.
I reviewed the log and it appears that this was a vibration issue that caused problems with vertical rate and altitude estimations. This was not an issue with the Autotune firmware. I have flown this firmware multiple times and on every flight have used althold. I have had no issues with takeoff, hover or landing in althold.

You can see where the two z accel traces from the two IMUs have a bias between them and then the EKF error. After that the altitude grows as you begin your takeoff which lift off isn’t until when the desired and actual altitude separate between time 17:13 and 17:14.


In this plot you can see the vertical vibrations are shown to increase quite dramatically at the same time you get the EKF error. I think above 40 for the vibe signal is considered unacceptable for EKF.

So I am not sure what caused the IMU z accel measurements to diverge. Again sorry to hear about the crash and hope you can get back in the air soon.

@Leonardthall could you look at this and make sure I am not missing something with the position controller. I know that you had made some changes to it in 4.1.

Regards,
Bill

Thanks a lot Bill @bnsgeyer
Almost back to air, found more problematic parts (crooked tail rotor axle, bad tail servo…) it’s a part of the hobby.
As I noted before, I did not think it was autotune firmware related, but could not find the crash reason.
Out of the 3 450 helis I have, this one was making trouble from the beginning. (bought it second hand in bad shape).
I thought that I’m repeating an error and wanted another opinion.
Might be, that the tail rotor axle was crooked from the beginning and i have not noticed that.

Sorry to see you crash mate, I am glad you were not hurt. I think Bill is correct in his assessment. It is a good idea to keep an eye on your VIBE outputs on mission planner before testing Alt Hold for the first time, or have a look at the dataflash log to make sure everything is going well.

Both EKF are getting completly different values for height and the baro is also suffering from the ground effect.

Very large amounts of noise:


Thanks mate, another important point to check in the future, i usually checked it once at the beginning.
is it a good practice to takeoff on Alt Hold mode ?