@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. 
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.
It is only for the landing detector to disarm. Once it touches the ground and disarms it relaxes the pitch to full bottom with the rotor still spinning at rated speed (although slowing down now after disarm).
The reason for it was people failing to set it, and failing to set it properly. We had one very bad explosion because of it where the helicopter rolled over because it blew the EKF from trying to pull too much negative pitch and never disarmed. It blew the pitch links off, the helicopter launched like a rocket and mowed a 30 foot tree down. If somebody would’ve been in the way their life would’ve been discontinued.
I actually removed it from the ArduHeli builds over a year ago. I finally PR’d the removal to master after it was discussed on the Dev Call as being a safety issue.