This should be interesting

That’s what I would think too. But they twitch when they pass a waypoint instead of flying thru it smooth. If I knew how to fix it, I’d have it fixed already. Copter has done this since like day one. With DJI’s stuff you can set waypoints, and using the Litchi software you can set a radius on the turns, which is another nice feature that is far better than Ardu’s spline waypoints. DJI’s hardware sucks. But they have very good software for flying waypoints, although the Litchi software is third-party.

Chris,
I suppose a little deeper in I will have to investigate further. Is this just an issue pertinent to helis? I would imagine a plane naturally has smoother turns and a multi maybe as well? Although since I know nothing about it I could be way off base?
Because of the much faster control authority, I can see where having things not behave in a smooth manner would be quite detrimental?
I am wondering how this might affect say a gimbal? It’s already hard enough to get good video out of a gimbal on a heli, let alone fighting jerky movements navigating waypoints. When carrying the heavy gimbal for video work with the bigger cameras I will likely be flying in loiter, alt hold or stabilize so it doesn’t worry me as much there, but once I transition into mapping or site surveying I can see that being a problem?
I played around with loiter yesterday and flew as couple mock cable shots and the like, and I will say it seems pretty smooth and fluid.

When in stabilize though, the helicopter still seems too snappy for video work or photography. I really need to figure out what parameters to tweak to get it to act more like a UAS. It has very quick rates and I have a ton of expo in my radio as well, more than I have ever ran prior. It just reacts very quickly. I have a feeling that might be some of my bounce with pitch, I am likely correcting for the fast rates and not noticing it, so I overshoot and pull back?
Need to dumb it down substantially before it ever sees a gimbal. I would probably induce an oscillation that is coupled with the gimbal the way it sits now because of overshoot and bounce back.
Tim

No. It affects multi’s too.

After you get it tweaked sharp enough for the autopilot, then set the RC_FEEL param for you for stabilize.

Chris,
So the RC_FEEL parameter, is that equate able to the standard “rates” setting in your radio? I know with most FBLs I use I leave the rates in the radio at 100% and then set rotation rates in the FBL. Is that parameter setting rate of rotation, or is it something else?
Tim

Tim, I"m not sure exactly what it does? But I know it softens or crisp’s up the “feel” when flying with the sticks in Stabilize. It’s set at 50 by default. And I don’t know about all this filter stuff and that either, how it’s going to affect it. I just know the autopilot has to have the control response you need for auto flight to work right. With a helicopter that’s usually a bit snappy for most pilots. Setting that RC feel param can adjust that so you like it.

With my flybars running VFF of .25 to .28 they are VERY snappy. If the helicopter is a bit twitchy, then I’ll put some nuts on the flybar rod to add a few grams of weight. Or on the stock Align slotted paddles, put the flybar paddle stickers on to cover the slots in the paddles and put some pieces of brass brazing rod in the weight holders on the paddles. The paddle weight adjusts how twitchy the helicopter is and how much damping the flybar has. The RC Feel adjusts how crisp it responds for me, the pilot.

So I suppose it’s like adjusting rates in the radio. But instead of adjusting the rate globally it adjusts it just for you, so the autopilot can use a different rate that’s probably more aggressive than what you like. That’s why I think adjusting filters for your “feel” is detrimental to what the autopilot likes. Because by fiddling with the rate controller you are adjusting the rate globally, and what you like and the autopilot likes are two different things.

Bill disagrees with my method of tuning because I took the helicopter out and flew it repeatedly on auto flights, and tweaked it until the autopilot was really happy with it. I didn’t do it in hover or Stabilize. As it turned out for my DFC head, leaving the RC_FEEL at 50 was “good enough”. For my flybars they are WAAY too responsive with the VFF set to where the autopilot really likes it. So I turn RC_FEEL down on those.

I been fiddling with running I gain on my flybars with 3.4. It doesn’t work. I think the code is broken for flybar mode. The way Rob used to have it in 3.3, the rate integrator was frozen when flying with the sticks, and in hover it trimmed the heli. In 3.4 it tries to tip helicopter over on the ground even with the leak set to max. And it makes the helicopter really twitchy in the wind unless I turn off the rate integrator. The flybar is fighting the integrator and it shouldn’t do that. Vid of the phenomenon. Both pitch and roll are twitchy, I landed it and left the main rotor running and it started twitching the heli on the ground and sort of rocking it back and forth. Every time it tried to tip it over I had to fight it with the cyclic to keep it level or it would dig the blades into the grass.

I run I gain no problem in 3.3.3 with flybar. Can’t do it with 3.4 with the new attitude controller. So I think you’re fighting a whole bunch of issues with 3.4 and later, compared to 3.3.3. There was some pretty major changes between those two versions of the firmware. I’m likely going to revert to 3.3.3 in this 600 electric flybar because 3.4 just doesn’t work right.

https://goo.gl/photos/ZaW6vGkHYo1JcK2H8

Tim, another thing to watch out for is the battery failsafe function. You may be not using it, as you have no PM for the FC to monitor it. But I had it kick in one day on the 600 electric and totally lost all servo response from the radio. The helicopter just started drifting away and I was in Stabilize flight mode. I had Land Reposition enabled, the helicopter had a solid 3D GPS lock, and it would’ve crashed into some trees. I tried switching flight modes and back to stablize, and still no control. I finally just shut the governor signal off and let it autorotate, which was one of the hardest and worst autos I had ever seen because I had no control.

I do not recommend using Battery Failsafe with a heli in 3.4. The ESC’s I got have their own battery failsafe and they just reduce power so the helicopter sinks, but at least you still got servo response to autorotate the helicopter if it kicks in.

I think that’s broken in 3.4 for trad heli too.And likely in 3.5 as well. I never tested it with 3.5

I don’t think it does exactly what the rates does in a transmitter. I’m not exactly sure but I agree with Chris that it offers a way to increase or decrease the sensitivity. However when I was playing with this feature and watching the swashplate response it reminded me of a lead filter where a lot of input was put in initially and then it washed out to your input. Im just not sure but I think starting with 50 is the best thing to do and then adjust as needed from there

I don’t disagree with your method. You were able to make it work. I was able to learn from what you did. Do I think that’s the optimum tuning values. I don’t know. I do know that I had my X3 tuned with high P gains 0.18 and relatively low I gain of 0.1 and I had no problem flying at 35 to 38 knots. Now I didn’t try an auto mode but the aircraft held pitch attitude to within a couple degrees. So I’m interested that with filtering, that the auto modes might work. This is a journey and I’m on a different path. We are all trying to get to the same place.

Oh, OK. Maybe I misunderstood. The whole idea, for me, using ArduPilot is to get the autopilot to fly the helicopter. To me, that’s what the tuning is all about. The helicopter gets way more miles and hours put on it flying auto (for me) than flying manually.

For Tim, this is how I do it - I set up an auto test flight circuit with several turns. This one is all spline waypoints to get rid of that confounded “jerk” you get using standard waypoints, or mixing regular with spline. This is a pretty tight 1/2 mile circuit I’m flying here, so only using a target speed of 15 mph. One waypoint from the end of the flight I put in a “Do Jump” command that repeats the circuit. You can set that “Do Jump” command to run as many “laps” as you want. After it flies the set number of “laps” it goes to the final waypoint and the flight is over. This flight, my warning timer set at 15 minutes went off and the heli completed 7 laps and came in with 21.8 volts after I shut down. Total 16 minute flight running 2,000 rpm headspeed.

The BIN log from this flight is also attached as a link so you can look at it. I remain confused about what is being tuned on a heli that has been flown at 65 mph with no issues. Flies fine in Stabilize. And holds position in Loiter. If the helicopter meets all the above requirements it’s not going to crash flying auto. It removes the human factor and gives you way more data to look at and analyze to figure out your wiggles or twitches instead of guessing.

https://drive.google.com/file/d/0B5oLpNzxih4tcjFtYTBWcEZPOFU/view?usp=drivesdk

Chris,
So thinking back to my initial push for higher P gain, I think I was trying to tune in the blind without seeking any assistance. Based on my knowledge of flight control system which are mainly manned helicopters and are mostly rate command based. I knew that rate feedback (P gain for a rate controller) was key to a system that would perform well. I had played with the I gain in tuning but I seemed to remember not liking it because of the lag in response and the low frequency oscillations but I didn’t pump up the I gain but more than 0.2 at most. Knowing that I liked the idea of having acro available and others that showed interest in having acro, my intent was to use techniques used in manned flight control systems to deal with instabilities. For some of the modern helicopters, they are using filtering to deal with the feedback instabilities. I work with a variable stability helicopter where we notch the frequency of the main rotor speed. But we also deal with lead lag instabilities of the rotor as well which we have to tune around. I found that this is not so much an issue with small UAVs because the lead lag frequency is so high, well above the response feedback of the servos.
I figured that users must have found settings that worked or were able to set up their heli that they didn’t see these feedback instabilities. Otherwise there would be more users posting problems. If users want to try my technique I am open to that. The more data I can collect the better I can determine whether this is an alternative solution to tuning. I get that you are of the adage that if it ain’t broken why fix it. But I think the difference is that I do this for a hobby and educational challenge and you do this for a living and need something that works and is dependable. So I’ll start pushing users to your tuning method but if they show interest in what I’m doing then I’m open to it.

Bill, the thing with full sized heli’s is that they run WAAY higher disc loading and blade tip speeds than these RC heli’s. 2.5 lbs/ft^2 and 700 fps is a light utility helicopter in full-size. That is going to be an inherently more stable machine. Rob’s heli was deisgned by an engineer (him) for UAV use. And I believe is flying at 1 lb/ft^2 disc loading with no payload. Most folks are using repurposed 3D helicopters which are neither designed for longevity, or being stable.

So this makes them very hard to tune. And two different pilots may have two totally different ideas of how that heli should act. The autopilot, however, is very finicky and way more accurate than any human pilot. There is no way a human pilot could fly that course in my video above with the accuracy of the autopilot, even standing in the middle of the course. So that autopilot, she’s the one you want to make happy. If she’s happy, you’re happy because the helicopter once tuned to her liking will have all the wiggles and twitches gone and you get lots of data from one of those flights to look at and figure out what is going on. All you need to do it is a basically flyable heli in Stabilize, can be flown around and put thru its paces without anything bad happening, and holds position well in Loiter.

Remember I made that mistake? I tuned my DFC helicopter to what I thought was good, felt like a flybar and was stable. I let the autopilot have it and was instantly back to square one because she didn’t like what I liked at ALL. I had to abort that first auto flight because it was horrible. The autopilot removes the human factor once you have a basically flyable heli.

And yes, I’m pretty sure that autopilot is female because it has to be done her way or it won’t work. :confused:

How this affects Acro with a FBL, I don’t know. I don’t see Acro being useful except for flybar. The ArduPilot system I see more as a SAS with a Flight Directior in a full-size helicopter, which is required for IFR in the US because no human pilot can fly the helicopter without it in instrument flight conditions. The ArduPilot system is a true autopilot, not a FBL unit, which only does the SAS part.

Bill, as far as acro and the interest in it, we all know it’s broken in 3.4 and later for trad heli. It was written for multi’s. Helicopters, even a big 800, are capable of rotation rates that will self-destruct the helicopter, and that no multi can ever hope to achieve. And the archilles heel of the system is the EKF. FBL totally depends on it. You can blow the EKF up simply doing a compass calibration, gently tumbling the aircraft thru all its attitudes. If somebody were to try fancy 3D moves with it, the EKF will leave the scene and come back later to visit at the crash site.

Only flybar does not depend on the EKF in Acro.

The people putting FBL units downstream of their Pixhawk are probably not so dumb. Properly set up it provides the redundancy of flybar. If I was actually going to fly a FBL helicopter on the primary flightline a downstream FBL unit is definitely the way I’d go. Even though Pixhawk technically does not need it, I’d do it for the redundancy, just because of the EKF. All it takes to set the EKF off is a mechanical failure in your heli that starts a severe vibration that requires an emergency landing and you are done with FBL. Having a blade delam in flight would do it. Even though the heli is still flyable and can make a safe landing, the way the system is designed at present it would just crash.

The software needs some auto mode autorotation code way worse than it needs acro “fixed” for FBL. If it had that, the Canberra team would not have lost their helicopter due to an engine failure. You know that in pilot training one of the things you have to learn before you can solo is how to land your aircraft with no power, or how to fly it to a safe landing with partial loss of power. And yet that basic safety concept of flight has escaped the designers of the ArduPilot system for aircraft that are fully capable of making a safe landing with no power?

Autonomous autorotations have already been done with the ArduPilot system but their code was never shared or released

But that’s all just my opinion. Looking at it from a UAV standpoint that requires the aircraft be insurable and safe vs a general purpose “do everything” heli that can do some basic sport aerobatics in acro.

I agree that for a UAV, that stabilize makes sense but there is nothing wrong for user that is comfortable with a rate command flight mode that acro isn’t out of the question. I think the name implies that you’ll want to do acrobatics but I agree there is no reason for a UAV to do acrobatics. Call it rate command or something else to get rid of the stigma. it is possible that this mode could offer some safety from an EKF blowup but there’s some flying to be done to check it out.
The auto mode for auto rotations sounds like a cool project. And would be a great feature.
We can argue about this all day. I have my priorities and you have yours. Let’s leave it at that.

I agree. I think it would be better to be called “manual flight mode” for helicopers instead of “acro”. In fact, “acro” doesn’t even really apply to multi’s because they can’t do 3D or even fly inverted without reversible motors. And even then, without cyclic pitch, they’re really bad at it :grin:

Chris,
Way off topic but did you see that quad rotor drone that had variable pitch on all 4 rotors? I believe it was by Curtiss Youngblood, the “stingray 500” if im not mistaken.
Im sure its a treat to pilot. :confused:
I thought it was a different idea as many people tout the mechanical simplicity of multirotors when compared to helicopters and this changes that metric a bit. Lol
Tim

Bill,
Exactly! From the outside looking in it took me awhile to understand what “acro” was based on the naming nomenclature. I agree if it was called something a bit different it would help in understanding what it offers. It is weird having it named based on acrobatic flight when its seems its marketed to the aerial robitics/UAS crowd.
Also if it could be used in a manner that affords relative safety of having a pure FBL mode as a backup should the EKF take a dive, that would be awesome in my book.
I mean, i suppose that requires a bit more in the way of pilot skill as there would be no helping hands from the accels etc, but I personally would be happy with the option. Im sure it would still mean bad things for an auto mission? But say im sitting there a couple hundred feet up shooting video and its really windy and the EKF blows, it would be a huge benifet having the ability to flip a switch and manually pilot it down using just gyros.
I have a couple FBL units that have both accels and gyros. They use the accels for stability and rescue functions but if the accels get saturated it automanically dis allows rescue mode and stops the stability loop, at which point you either finish your flight without the accels as normal, or land and see whats going on, usually vibration issues.
Tim

Yes, I’ve seen those. I’m not sure how practical they are though for anything useful

Agreed, it seems like a product that was made just because you can. I dont see where it adds stability, manuaverablilty, speed or endurance to the equation against a standard multi rotor or helicopter.
Its like the unicycle, not better than a bicycle or a trike but done simply becuse you can and its different.
Tim

Chris,
Thats impressive, autorotaion with ardupilot! I wonder, did they have a sensor involved so the system knew the speed of the rotor? Autos seem to be one of those “done by feel” things, and once the electrical system of the motor is taken out of the equation the autopilot would have no way of knowing how fast the rotor was spinning and if it was losing or gaining energy?
I wonder how they did it?
Tim

No. You don’t need to know anything about rotor speed for an auto. I think they engaged it manually to test the basic functionality. And it just used the barometric altimeter to flare. In real world, the autopilot can’t do a full auto because the terrain you’re flying over is likely different elevation from where you took off from. The main thing is to notify the pilot that power has been lost and set up a routine that will feather the rotor, get forward cyclic into it, and use the GPS/compass to turn the heli to a heading that is pointing the heli back towards home, then hand control over to the pilot.

All the autopilot does right now is increase collective to max to try to hold altitude and stall the main rotor. In that first second of power loss you’re only going to lose 16 feet of altitude. If you stall the main rotor, in the next second you’ve lost 65 feet. If the autopilot was smart it would only lose another 15 feet in that next second. And by that time set off a warning on the ground station that power has been lost and you now have the aircraft. That would be all that’s needed.

@bnsgeyer
Bill,
Unfortunately the holiday weekend was busy, but not with Arducopter… That being said i was gifted a day off tomorrow so ill be spending some time uploading your code and testing. Ive been dying to see if the filter helps like I hope it does, weather permitting ill get a chance to see. I intend on being as thorough and scientific about this as i can for the sake of good data.
Thanks again,
Tim