Arducopter 4.0 Heli Testing Thread

Hello all,

Just wanted to start a thread where anybody helping out with the Ardupilot 4.0 testing of Heli can come to share info, and anybody else can follow along. I’d encourage anybody to help out that can. This is a pretty important release with the change from Nuttx to Chibios, and all the advantages that will bring. I’ll be doing a lot of testing using RealFlight which I have found to be really very good for simulating. Best part is crashing is free! Later on I’ll be moving to real systems.

So without further adieu:

  1. H_RSC settings have been rescaled from 0-1000(uS PWM) to 0-100(%). I generally think this is a fine idea although I do like a little more precision. I wouldn’t really want a float, in the past I have liked using fixed decimal point floats ie: 4-digits with a single decimal point. (ie: 100.0 represented by the integer 1000). But I digress. The issue I found was that there is no scaling check for users coming from an older revision. Two problems emerge. First, if you leave a large number like 800, the runup ramp happens REALLY fast. This could harm the heli. Second, H_RSC_Crit never goes above the (default) 500, and so you can never engage an auto-collective mode. We should do a pre-arm check to make sure these are in range.

  2. Initially I couldn’t get to the Heli setup page in MP. Later on I could. Not sure of the deal here.

  3. When doing a parameter reset, I couldn’t arm. I got a warning “RC9 Min is greater than Trim” for all channels 9-16. I had to go and fix them all individually. I believe this is not just a Heli thing, and might actually be more to do with MP. During the calibration process, it seems it set the RC9+ Min to a really high number, as I didn’t have a 9 channel radio to move these.

  4. Can’t arm in Auto. I think this has always been there. Though I now wonder why. But something that is definitely new, is you can’t take off in Auto at all. I used to arm in Stabilize, switch to Auto, start the rotor, and it would take off automatically after runup. This process doesn’t seem to work anymore. I have to arm in Stab, start the rotor, wait until runup is complete, then switch to Auto.

  5. I had one instance of disarming while still flying. I was coming in for a landing, and it disarmed. I believe there have been some changes to this logic recently? This is a surprisingly difficult thing to get right, we’ve been over this issue many times through the years.

@Rob_Lefebvre Thanks for kicking this off! There are a lot of changes and I will have to write a post to capture them so users know what to expect. I will address some of what you are seeing as well.

I have successfully passed the test flight of a complete multi-flight mode development version 4.0 firmware, using the T-rex 500 FBL helicopter and the flight control of Matek F765 wing, I uploaded the video for your reference.

I had coded pre-arm checks for these values but there was an override of that function in MotorsHeli_single in which I didn’t include a call to the function in MotorsHeli (which contains the ranges checks). I will get a PR in for that tonight.

Yeah I’m not sure about the arming in auto but there was a conscious decision made by Chris and I shortly after we became tradheli maintainers to not allow users to spool up in Auto. We also made it that you couldn’t switch to a non-manual throttle mode during spool up.

Lastly I want to WARN users that H_LAND_COL_MIN was removed and the parameter that is used instead for that functionality is H_COL_MID. Remember H_LAND_COL_MIN governs the minimum collective that a non-manual throttle mode (ALTHOLD, LOITER, AUTO to name a few. effectively all flight modes except ACRO and STABILIZE) can command. So if you have the H_COL_MIN set for -10 deg blade pitch, this setting stops the autopilot from commanding that blade pitch while the aircraft is on the ground. So it is VERY IMPORTANT that you set H_COL_MID to the blade collective pitch that corresponds to zero thrust and for most users this is 0 deg collective blade pitch. If you set H_COL_MID properly then this shouldn’t be an issue although I never did really like the name of this parameter.

Actually, we didn’t make that decision. Somebody else made it and it was changed in like 3.4. It applied to multicopters too. So we just decided to run with it.

The old procedure used to be start it up, switch to Auto and when it reached the runup timer it would take off. The new procedure is to start it, let it run up to the runup time, then switch to Auto and it takes off.

I’d have to look in the code history to see who changed that, but it wasn’t us.

I really doubt that. I’ve been doing auto take offs with multi copters for years on 3.5. I definitely agree that you can’t arm in auto. But once you are armed, with multi copters you can click on auto and it will immediately spool up and takeoff.

That’s because they instantly spool up and there’s no runup timer. Maybe the change was made only to helicopter, I don’t know, don’t remember. I don’t use it. But I remember when I was working with Thunder Tiger they could not get auto takeoff to work the way I described it to them. I had to investigate it myself and found out the behavior had been changed from what it was in 3.3.3. They were flying 3.5 at the time so I don’t know if it was changed in 3.5. or 3.4. But it was one of those. And I certainly don’t recall that we changed it. When the question came up we decided to leave it as-is, unless you can point out a PR that I probably forgot about where we changed that behavior.

Modes like Loiter or Alt Hold were always locked out until the runup completes. But that was broken in 3.4 because I crashed a Trex 600 because of it. Took off in Stabilize, switched to Alt Hold and it proceeded to smash itself into the dirt because the runup hadn’t completed, and the lockout that worked in 3.3.3 was busted in 3.4. I think Randy fixed that after it was found.

@Rob_Lefebvre I was mistaken in my earlier reply. here

the pre-arm check of RSC_CRITICAL and RSC_SETPOINT and RSC_IDLE all checks out. So what you are saying is that you updated your firmware from a previous version of master? Even if you did, you should have still got the pre-arm messages. So I’m not sure how that is happening. Please give me more details so I can reproduce the issue.

So what I did was using RF. I took Tridge’s parameter file for the Raptor 720 from some older version of the firmware (3.6?) and I loaded that into SITL. It would have brought in the RSC_Setpoint of 800 I think, and also the RSC_Crit of 500.

Which caused two problems. Well first there was no pre-arm warning. So first the Runup happened way too fast. 10 times faster than it should I imagine. And then I could never switch to any auto-collective mode. Ever. Because RSC_Crit was never achieved.

Can we reconsider this?

We need to move in the direction of allowing helicopters the same autonomy that multirotors enjoy. To the point that, and this is going to blow your mind, I would like to make it possible to set up a helicopter such that it doesn’t even use Ch8 anymore. You arm it, and it starts the runnup right away.

I get the fear. Believe me. Heck I created the motor interlock in the first place, and it brought it to multirotors. It has a place, and should remain the default. But advanced users should be able to set these up for full autonomy. Otherwise helicopters will remain in a technological backwater. I’m going to reiterate the words of Tridge “there’s so many other ways that people can crash their aircraft, why are we worried about just this one?”

Absolutely, users should not be able to switch from manual collective to auto collective while in an intermediate spool-up state. It was actually me that did that years ago, after I had a crash or two.

But we should be able to do an auto flight without having to go through Stabilize. So like we did before, Arm in Stabilize, Switch to Auto, then start the rotor.

Why can’t we arm in Auto anyway? Can Multirotors? I don’t recall the reason for this.

So How did you run the SITL? Did you just run it from Mission Planner using the simulation tab or did you run it from Cygwin or Ubuntu running the latest version of master?

Was straight from MP using simulation tab. My understand is this always grabs the latest?

I’m going to be moving to Cygwin shortly. Just getting my feet wet again.

Oh, and what was the cause of all this? Land Col Min had a pretty important function. Simply limiting the collective to Mid can cause problems. Actually, Tridge and I noticed it, and were thinking it’s a bug. Now I understand what’s going on.

The old parameter file that I was using had a Col Mid that was too high. The result is the copter climbs uncontrollably in all auto-collective modes. I suppose the same sort of issue could afflict somebody who had the Land Col Min set inappropriately so…

But the point of Land Col Min was to allow a moderate degree of negative collective when landing and/or hovering. This is enough to stick it on the ground, but not damage the mechanics.

However if you are now limiting the collective to neutral pitch, I think it’s going to cause problems in high performance auto flight. ie: Alt Hold, if you’re doing 20+ m/s and yank back on the stick, you need access to negative collective to avoid rising. Same for any sort of fast descent, etc. Descending while stopping, etc.

It will have access to negative collective pitch because at that speed the aircraft will still be in dynamic flight and the landing collective flag will be false.

it was to simplify the number of parameters. Both Chris and I felt that mid collective set for zero thrust was sufficient to allow vertical control in non-manual throttle modes.

1 Like

Oh, so the dynamic flight thing is still going on? That’s good at least. I’ll give this a shot. Though in my experience some downward push on the ground is beneficial and I may add it back in to my branch. For sure it’s needed for landing on boats and other moving vehicles.

We have about 400 parameters. This seemed like a pretty important one. I’d rather get rid of external gyro, etc. :wink:

Any chance something happened to Col_Yaw rescaling? In the Sim I’m finding a value like 1.2, but in the past in real life, I was using more like 5. Could just be a sim thing, but I’m finding most things pretty representative so far.

Also, I can get to the Heli setup page now, but everything is greyed out?

While we’re rescaling everything I wonder if H_Stab_Cols should be rescaled?

I wonder if we could get Tridge to set up a H_Advanced group and move some of these into it (including re-adding Land Col Min). There’s a lot of these most won’t touch, and might be a good way to slimplify things?

What do you mean by this?

Not that I know of. I’m not sure why it would have changed

I assume you are talking about IM_STAB_COL? I suppose. I haven’t heard of anyone being that picky about setting these that they need 3 significant figure resolution.

What is a H_Advanced group? Are you saying to move parameters into a new group called H_ADVANCED? I’m not sure I want to do that.

So how easy is it to get things changed for that page. I don’t recommend that we use it because there are a lot of parameters that changed and may not be set correctly from that page. We need to add the 5 pt throttle curve and the governor settings

So arming in auto is not allowed for Heli’s and Multi’s. As long as I can remember, neither frame could arm in auto.