Preparing for Autonomous Takeoff and Landing with TradHeli

[ChrisOlson]

@Leonardthall

This could be even more valuable to the multicopter aircraft as they don’t have the TPP feedback that heli does and long landing gear can be a real problem during take off and landing! Heli call it dynamic rollover I believe.

I’m not totally sure how dynamic rollover applies to multicopter. In helicopters it has nothing to do with the height of the landing gear. It has to do with outside forces causing the helicopter to tip beyond it’s critical roll angle, magnified by tail rotor thrust. When it gets to the critical angle main rotor thrust continues the roll and recovery by cyclic is impossible.

The autopilot cannot handle a dynamic rollover, and can actually cause it. Only a trained pilot knows how to recover once it goes past the critical angle, and recovery is only possible in Acro or Stabilize flight modes.

[Leonardthall (Leonard Hall)]

@ChrisOlson

In helicopters it has nothing to do with the height of the landing gear.

The height of the landing gear is one of the factors that defines the critical roll angle. Higher the landing gear the lower the angle for a given landing gear width. The higher the landing gear the more sensitive the aircraft is to wind initiating the dynamic roll over. Like full sized aircraft a major cause of dynamic roll over is from the landing gear being stuck or partially stuck in the ground (or still attached to one of the ground securing points).

[bnsgeyer (Bill Geyer)]

@Leonardthall

So the interesting question here is what can we learn from the leaky attitude approach being helpful on the ground to improve the transition from ground run to flight. Then get rid of it in the air so we have uncompromised attitude control (and teach heli pilots how to use input shaping).

I’m not sure that the control model in its current design can mimic a flybarred heli response. And truthfully, as long as it doesn’t affect the autopilot’s ability to fly the aircraft, then why does it matter for a manual mode.
I’m all in as far as improving the ground air transition using the techniques you employ in multi, we just have to find best way to tell the controller when to release the ghost and integrator. I’ve put some thought into it. It is much easier for multi’s because you don’t have power off flight capability so when the throttle is on the lower stop then you can clamp the ghost and integrator. Heli is going to have to rely on the land complete flag to make these decisions because it can still be flying if it loses an engine and then it really becomes important to retain the full control capability of the aircraft.

[ChrisOlson]

@Leonardthall

The height of the landing gear is one of the factors that defines the critical roll angle.

Static rollover is where the center of mass goes over the pivot point and is affected by the height of the landing gear.

The critical roll angle in helicopters is explained in your helicopter’s flight manual, and all training manuals. It is unique to every helicopter and is the maximum angle in slope operations where the rotor system can remain level (due to articulation of the rotor system). In other words it is the maximum blade flapping angle. On level ground the critical roll angle is the same as in slope operations. Once the helicopter exceeds the critical angle the thrust component from the rotor system goes off-vertical and cyclic will not bring it back.

Exaggerating the problem can be CG, or crosswind of sufficient force to cause the rotor to go into translational lift, which in turn causes rotor blowback to the downwind side.

Critical roll angle is 5-8 degrees for most semi-rigid (teetering) rotor systems, 13-17 degrees for most fully-articulated rotor systems.

For most fleet and training helicopters, static rollover critical angle is 30-35 degrees.

[Leonardthall (Leonard Hall)]

@bnsgeyer

I’m not sure that the control model in its current design can mimic a flybarred heli response.

Yeh I don’t know if it would or not, I would need to look at the flybared response in a lot more detail.

@bnsgeyer

And truthfully, as long as it doesn’t affect the autopilot’s ability to fly the aircraft, then why does it matter for a manual mode.

This is actually one of the more interesting parts. By the sounds of things we have a number of pilots who have the attitude controller feedforward turned on but have not set the input shaping parameters up properly. They may also have a few tuning issues, some fundamental to our controller design. There may be higher than optimal FF terms being used creating a nice direct feel despite the input shaping (this was one of the issues with Josh’s setup on yaw). So lots of hypothesizing and guess work here.

So the interesting part is that with the compromised controller setup the VBar acro controller provided a nice feel to the pilot.

So the question I pose to myself here is, can this leaky error term make our controller more forgiving to poor setups without compromising a well set up aircraft. Is there something we can apply more widely to make our system more robust and forgiving?

A follow on question is if we make things more robust, to poorly setup aircraft, will the community end up in a local minimum with bad tuning habits and never reach the full potential of their aircraft?

Maybe this is where taking Autotune to the next level is the solution. It will get the pilot into the ideal tuning minimum. Then we are at a point where the leaky error should have little effect and the only way to soften the aircraft will be to work with the input shaping as it was intended.

The VBar acro controller would probably lose the feel that the pilots like though and we would need to design a controller to specifically recreate that feel. The affection I have heard various heli pilots heap on the feel of a mechanical VBar system makes me think that an acro based on this would be well received by multi pilots too (maybe).

The human interface has been one of the most interesting parts of the controller development for me over the last 5 years or so.

[JoshW]

@Leonardthall

(this was one of the issues with Josh’s setup on yaw).

Yeah… pretty interesting vff would go one way and P and I terms would go the other way to reel Yaw back in to the configured rate. #mybad

[Leonardthall (Leonard Hall)]

It was particularly interesting because when we fixed the problem Josh hated the yaw response because it was doing what the input shaping was telling it to do rather than jumping forward as soon as he touched the sticks. So it felt slow and unresponsive. We had to increase the Accel Yaw by a factor of 2 or 3.

The other interesting thing was the asymmetry of the yaw response suggesting that the output was not linear with pwm output. (the main blade torque does not account for this problem).

I suspect to fix this problem I would have to do a full side thrust stand up to linearise thrust by adjusting the servo linkage or account for the normal servo arm trig in the code (as you did for the head).

[bnsgeyer (Bill Geyer)]

@Leonardthall

Yeh I don’t know if it would or not, I would need to look at the flybared response in a lot more detail.

I think the way you could model this response without using this attitude leak would be to put a low pass filter on the target attitude. I think this would accomplish the same thing as the leak in flight but it would not address the ground handling and ground/air transition issues which we could address in other ways.

Initially I was thinking more of a follow up trim concept and I am not sure that what I proposed above accomplishes that. Have to think about this more.

[JoshW]

So, a quick flight report… I did 3 missions today after changing some parameters as discussed so far in this thread:

ATC_RAT_PIT_ILMI from 0.03 to 0.08
ATC_RAT_RLL_ILMI from 0.04 to 0.07
H_LAND_COL_MIN from something_stupid_like_331 to 425 (just a little bit under 500)

Also, based on a conversation with Tridge during an unrelated engagement, I also changed this setting which is appropriate for all M8-based uBlox, and will auto-detect and auto-set in Master but not in release:
EK2_GPS_DELAY from 220 to 100 ms

In flight testing I also ended up changing the following:
LAND_ALT_LOW from 1000 to 800 (And I may drop to 600)
LAND_SPEED_HIGH from 0 to 225 (WPNAV_SPEED_DN is 350 but I didn’t like the way this looked for landing)

So, my normal waypoint mission I’ve been running received a TAKEOFF waypoint and a LAND waypoint at the appropriate parts of the mission. The DO_JUMP was changed from -1 to 5 for number of times to repeat. I uploaded this mission and set up to go.

I could not get the TAKEOFF command to process, more on this in a minute.The last waypoint in the mission somehow kept messing with the copter. The copter would come in to the waypoint and have to stop and hunt all around to find it. My first inclination was to look at my WPNAV_RADIUS and it was set to 60cm all this time! I have stepped this up to 500cm (am mission-ing at 25m/s) and while the hunting at that last waypoint is “better” it is still not flying through it like it was before; I suspected this is something to do with a combination of the updated EK2_GPS_DELAY parameter and maybe waypoint 7 was goofed. So I looked at a text-file export of the mission and waypoint 7 had nothing goofy set that I could see. I’m not really sure what was going on there, but each of the 3 flights would struggle there, and it isn’t a hard turn from there to waypoint1, which is where it would go to as a result of the DO_JUMP.
After the cycles were finished, the copter would move to waypoint 9 and then land, and each of the 3 auto landings were PERFECT! I didn’t like the initial descent speed on the first one, and this is when I decided to decouple the landing speed from WPNAV_SPEED_DN. Subsequent landings looked really nice.

With the takeoff, I tried every combination I could think of from the TX to get Auto to spool up, and it never would. But if I went to STABILIZE and spooled up, I could click in to Auto from 1" off the ground or many feet off the ground and it would begin the mission immediately. Would appreciate thoughts on what I’m doing wrong there. Takeoff location was level and winds were calm to none.
Here are my RSC params:
H_RSC_CRITICAL 500
H_RSC_IDLE 0
H_RSC_MODE 3
H_RSC_RAMP_TIME 1
H_RSC_RUNUP_TIME 7

the RSC Mode is set to use the curve and all 5 curve points are 700.

What should the expectation be for Auto Takeoff, and what is the proper procedure between mode change, arming, and interlock? Also, I am curious what you guys are thinking WPNAV_RADIUS should be if a Heli is running 25m/s? Not too interested in making this 50m like I would in Plane, and I’m not running L1 so basic copter nav is in play.

Thanks again for the review and help!

Josh

[JoshW]

@Leonardthall

The other interesting thing was the asymmetry of the yaw response suggesting that the output was not linear with pwm output. (the main blade torque does not account for this problem).

Hmm, I thought we agreed the main blade torque does account for this problem because we found the tail rotor was essentially pre-loaded to compensate for torque, so the 50usec it needed to move to achieve yaw rate was easier than the 150usec need in the opposite direction to go the other way? Did I misunderstand where we left that one?

[bnsgeyer (Bill Geyer)]

@JoshW

With the takeoff, I tried every combination I could think of from the TX to get Auto to spool up, and it never would.

tradheli is not designed to allow the autopilot to enable motor interlock. The pilot must enable motor interlock and wait for the run up to complete before being able to switch to auto mode. Once the aircraft has completed the runup, then you should be able to switch to auto and raise the collective to tell the autopilot to initiate takeoff command. However I am not sure, so be at the ready once you hit auto. it may initiate the takeoff immediately.

Could you post your log file, I would be interested in seeing it. If you have the telemetry file, that would be nice as well. It is easier to see the mission replay and follow along.

Thanks for the flight report!!

[JoshW]

@bnsgeyer

tradheli is not designed to allow the autopilot to enable motor interlock.

Ok good, glad you confirmed that; I never expected it would enable the interlock itself, but if I tried Arming in Auto and then enabling the Interlock, the mode switch to Auto would be rejected due to interlock. If I enabled the interlock and then went to Auto and then armed, that would also be rejected. Basically the only thing I could do was Arm in Stab, enable the interlock, and then switch to Auto - which I wouldn’t do until the spool up was complete. At one point I’m hoping to figure out the smoother way to do this, otherwise why even have the RSC time parameters? I’ve got to be doing it wrong.

@bnsgeyer

Once the aircraft has completed the runup, then you should be able to switch to auto and raise the collective to tell the autopilot to initiate takeoff command.

I wonder if this is key for one of the things I saw… I swear I was armed in Auto with the interlock enabled once, but runup never occurred, but I don’t remember where my Collective input was. This should be represented in the first switch to Auto in the first log, so I’ll review as well.

That said:
First Log
Second Log
Third Log

First Telem Log
Second Telem Log

I only have two TM logs and I haven’t yet looked to see which flight is not included. Also, I noticed that I lost TM during these flights and at one point Mission Planner gave up and just seemed to disconnect. I didn’t think that would happen, so it makes me wonder if the laptop got bumped causing a loss of connection to the radio, but whatever.

[bnsgeyer (Bill Geyer)]

@JoshW

I wonder if this is key for one of the things I saw… I swear I was armed in Auto with the interlock enabled once, but runup never occurred, but I don’t remember where my Collective input was.

Are you saying the rotor never started turning or that the aircraft wouldn’t initiate takeoff in auto. If you were in stabilize, you should be able to sit on the ground rotors turning with the collective stick on the bottom stop. In 3.6, it requires collective stick full down for the land complete flag. So if your collective stick was not on the bottom stop then I could see it possibly not going into auto.

@JoshW

At one point I’m hoping to figure out the smoother way to do this, otherwise why even have the RSC time parameters? I’ve got to be doing it wrong.

To keep the novice user from trying to launch their aircraft on an auto mission before it completes the rotor runup.

[JoshW]

Turns out the second telemetry log is worthless, I never even got armed in that log, so, disregard.

@bnsgeyer

Are you saying the rotor never started turning or that the aircraft wouldn’t initiate takeoff in auto.

For the attempt where I felt like I was successfully in Auto on the ground, and the mode change was not rejected, the rotor would not spin up. For all the others, Auto was rejected for one reason or another. I have Yaapu on the radio so I hear the different tones for when things are errored out or not, and also the copter sounded the sad-tone when I tried to go to Auto when the other conditions were not met.

[Leonardthall (Leonard Hall)]

@JoshW

I thought we agreed the main blade torque does account for this problem because we found the tail rotor was essentially pre-loaded to compensate for torque

No, if the tail rotor is pre loaded then an extra newton of force to the right is still the same as an extra newton of force to the left. The only way this is not the case is if the tail blades are not moving the same amount in each direction, the lift curve of those blades is not linear, or the servo linkage is resulting in a non-linear movement. We checked to make sure we were not hitting any limits on the tail rotor.

This one would require some serious experiments and examination to work out what is going on.

@JoshW

Also, I am curious what you guys are thinking WPNAV_SPEED should be if a Heli is running 25m/s?

That would be 25 m/s Josh… I am very tempted to leave that there but I suspect you were talking about the waypoint radius.

@bnsgeyer

I think the way you could model this response

I probably need to fly one. Is there a good representation of flybar vs flybarless in RealFlight?

[Leonardthall (Leonard Hall)]

I suspect that your waypoint radius is getting too small and it is just missing it on approach and needs to back up. Maybe try 100cm.

[JoshW]

@Leonardthall

That would be 25 m/s Josh… I am very tempted to leave that there but I suspect you were talking about the waypoint radius.

GAH! Yeah, WPNAV_RADIUS is what I was referring to. Thanks. But now since you’re having fun, it’s my turn: I mentioned above that I upped this to 500cm.

@JoshW

My first inclination was to look at my WPNAV_RADIUS and it was set to 60cm all this time! I have stepped this up to 500cm

Something I found very interesting here is that today, the heli was missing the track on that leg, check this out:

It is slightly off track there. I wonder if this is related to the updated EK2_GPS_DELAY that @tridge gave me for M8-based GPS. It must be since we’ve been running this mission before, but I would suspect that now with a more accurate position estimate that the copter would hold to the track better? But you can see in those images it is clearly cheating a bit to get around the track quicker. Clearly something Leonard made it do without telling me…

[JoshW]

@bnsgeyer

At one point I’m hoping to figure out the smoother way to do this, otherwise why even have the RSC time parameters? I’ve got to be doing it wrong.

To keep the novice user from trying to launch their aircraft on an auto mission before it completes the rotor runup.

Ok so that seems to confirm for me I’m doing this wrong. Will try again in the next day or two.

[Leonardthall (Leonard Hall)]

I think it is justs moving back and forth over the track as it recovers from the fast corner before where it overshoots a little.

There is probably some position controller tuning we could do. You are also running 5m/s/s accelerations so we are getting up there as far as the navigation aggressiveness goes.

[JoshW]

@Leonardthall

There is probably some position controller tuning we could do.

Let’s.

@Leonardthall

You are also running 5m/s/s accelerations so we are getting up there as far as the navigation aggressiveness goes.

I bet we could go higher