[TheOtherCliff]

One of the VtolPF options tells it how to treat yaw.  Basically, you can set this mode to manual and in RTB or other VtolPF mode, you can control the yaw as it executes e.g. RTB... you can spin it around so it is flying sideways or backwards and it still makes steady progress toward base.  As I recall in FW RTB, basically the sticks are unused (I don't recall whether zero throttle might stop the motors).

To avoid questions about what options to enable or what the code is doing, I would do a bank and yank test in Atti, Atti, Manual in FW configuration to answer the question as to whether the aircraft can fly like that.  If it can, then it will easily fly RTB correctly no matter what the initial direction is, and you just need to find out why yaw is doing what it is doing.  ...If it works fine, as I suspect it will, we know what the issue is.

[trust]

After examining tail cam videos, and testing VR and RTB in FW mode - such that the code thinks it's flying in FW mode, but the mixer is set to VTOL wing mode - I noticed that both VR & RTB work. It has the characteristic roll wobble oscillation, but it works. As I've pointed out before, for years we flew Hellaplanes using only one set of mixer settings - what we now use as the VTOL mixer setting. Not perfect but usable.
  In the fail videos, where the mixer is set for FW mode, I noticed the plane pitches up, then as it rolls, it also yaws - but in the opposite direction. Adverse yaw and aileron stall - telltale signs. With huge elevons in the rear, adverse yaw is an issue. The pitching up exacerbates the yaw in an aileron stall.
   So I decided to try adding a lot of motor yaw when roll is input - setting the left and right motors to respond to roll with yaw.
I tried this - when rolling, now it also yawed. I needed to also use the rudder - otherwise it would counteract the yaw itself.
When I switched to RTB, now it didn't pitch up, roll and yaw in the opposite direction. It seemed like it was going to work, but the the pitch kept increasing, and as it was somewhat windy (I could penetrate if I flew in STB2 mode level), it began to drift backwards. I must have let it go too long, because when I tried to switch it back to STB2, it wouldn't respond. My video OSD showed it was still in RTB - the default that the receiver goes into when signal is lost. Nothing I did would get it back. The plane drifted at what seem like the correct RTB altitude downwind until I lost video feed. I could still see it, until soon thereafter it dropped from sight.
  I did a search of the area, but no luck finding it. Hopefully - and likely - it landed softly as the battery failed.
Bummer.
  Part 2
  I took my 450 quad with 4k camera to the area to look for it. First, I couldn't get rid of the mag warning, although I was plenty far from any metal. When I tried to fire up my laptop to recalibrate, it needed to do a system update. After I did the recalibrate, I took off, got about 5 feet up and the quad tilted severely to one side and angled in and crashed. I thought I could tape it back together, but the flight controller lost its settings. And somehow I didn't have that version firmware on my laptop. Gave up, brought it back, rebuild and re-epoxied parts that had shifted, and swapped the UBLX GPS for the combo DJI/mag GPS, and a different receiver. Spent the day today on all the rebuilding and reconfiguring & retesting.
  Just not my week.

it would seem that would I should have set is the FW pitch lower (the landing pitch setting is used in RTB) - it was set for 7.5 degrees, but should likely be set to 0. What puzzles me is why it held such a high AOA - a lot more than that 7.5 degrees.

[TheOtherCliff]

... then as it rolls, it also yaws - but in the opposite direction.

This is the reason why I recommended to disable FW yaw stabilization for GPS flight.  Adverse yaw control.  In a bank and yank left turn you are getting significant left yaw (the banked turn is half way between a loop and a flat "yaw only" turn), but with the yaw stick centered.  Yaw stabilization applies right rudder to counteract what it sees as an undesired left yaw.

A test in Atti, Atti, Manual should prove that it can be flown in FW bank and yank.

=================

The lockout could be a radio problem or it could be a code issue.  If that radio is fairly well proven. . .

[trust]

I think I pointed out that in FW GPS mode, yaw IS in Manual mode. Here is the relevent code in pathfollower:
    stabDesired.StabilizationMode.Roll   = STABILIZATIONDESIRED_STABILIZATIONMODE_ATTITUDE;
    stabDesired.StabilizationMode.Pitch  = STABILIZATIONDESIRED_STABILIZATIONMODE_ATTITUDE;
    stabDesired.StabilizationMode.Yaw    = STABILIZATIONDESIRED_STABILIZATIONMODE_MANUAL;
     stabDesired.StabilizationMode.Thrust = STABILIZATIONDESIRED_STABILIZATIONMODE_MANUAL;
 And yaw is set to 0 - so does nothing.

Correct me if I'm wrong, but adverse yaw from ailerons is in the OPPOSITE direction as the roll. So a left bank produces a right yaw - and pitching up adds aileron stall potential to it which adds even MORE yaw in the opposite direction.

In the video I was watching with the OSD, I was surprised how far downwind the aircraft had traveled in a short time (or perhaps it just seemed short) - at any rate, not 100% certain but fairly likely signal loss was a range issue. I had been using this same code on several flights, and I was always able to switch back and forth flight modes when things were going wrong (or right).
  I have flown aircraft out to where the signal drops - but usually I can get it back by reorienting xmtr - often the issue is the xmtr antenna is pointed at the aircraft - which is the min xmtr signal condition. But not in this case. Sadly, though I usually record the video with the DVR rcvr, I forgot to press record.

[TheOtherCliff]

I think I pointed out that in FW GPS mode, yaw IS in Manual mode. Here is the relevent code in pathfollower:
    stabDesired.StabilizationMode.Roll   = STABILIZATIONDESIRED_STABILIZATIONMODE_ATTITUDE;
    stabDesired.StabilizationMode.Pitch  = STABILIZATIONDESIRED_STABILIZATIONMODE_ATTITUDE;
    stabDesired.StabilizationMode.Yaw    = STABILIZATIONDESIRED_STABILIZATIONMODE_MANUAL;
     stabDesired.StabilizationMode.Thrust = STABILIZATIONDESIRED_STABILIZATIONMODE_MANUAL;
 And yaw is set to 0 - so does nothing.

Correct me if I'm wrong, but adverse yaw from ailerons is in the OPPOSITE direction as the roll. So a left bank produces a right yaw - and pitching up adds aileron stall potential to it which adds even MORE yaw in the opposite direction.

I used the term adverse yaw control to emphasize that I was talking about the actual yaw control, not the "drooping aileron has more drag than the raised one and thus you get adverse yaw".

Opposite yaw control is what you get when you do simple bank and yank with a stabilized yaw.

Indeed, disabling yaw may be the intent of that code in the flight modes you are in.  I haven't verified.  I trust empirical evidence.  Questions are whether it is executed when you think it is and whether it is undone by some other code, etc.

For normal airplanes where normal adverse yaw is a factor, simple differential throw of putting the aileron linkage on the servo wheel at 45 degrees instead of 90 (to limit the down aileron direction) will usually help and/or you can trim both ailerons up.  Modern transmitters often have a differential aileron function, but of course this needs to be done in the FC if not on the servo wheels.  There is already a mixerSettings.RollDifferential setting (flight/modules/Actuator/actuator.c) that looks like it does what you need, it subtracts a proportion ... from only one direction of each aileron servo.

Aside: I recommend ailerons as spoilers (up) instead of as flaps (down) when using the single surface for both functions and you really feel you need it.  I personally don't use flaps/spoilers on anything, but I don't fly anything with a glide ratio of 25:1 where I might start to want them ... but then I enjoy flying around shooting touch and goes while leaving the throttle at 25% the whole time. 

Just saying what I would test next if it were me.  Either fly Atti, Atti, Manual (maybe even with stock firmware) and try bank and yank, looking for the issue; or set up telemetry to watch something late in the chain like ActuatorCommand as you fly your GPS flight mode where you see the adverse yaw issue.  ActuatorDesired would seem better (IMO it's not in this case) (it has a yaw element instead of watching a pair of motor power settings), but there is the mixer table stuff between ActuatorDesired and ActuatorCommand, and that might throw a curve ball.

[TheOtherCliff]

Another possibility that strikes me is that it doesn't fully transition from "vtol controller" code to "fw controller".  A test for that would be locking it into fw, powering it on that way, testing your failing GPS flight mode that way... maybe with stock firmware?

[trust]

Ported the latest code over to M24, a rebuilt version of M2.
I changed a few items - set the landing pitch (which FWpathfollower uses for initial pitch setting) to 0.5 degrees instead of 7.5. Changed the pitch neutral position to 0 degrees. Changed the throttle neutral to 0.4 (instead of 0.5). I changed these as I realized the Hellaplanes prefer the body to be level - the wings have a small positive AOA when in horz mode.
Set the TypeSwitchEnable flag false - this is a flag I use to enable the dynamic switching of aircraft type - so when off, it uses the original code, which loads whatever is set as the Customcraft (which I have set as FW).  That way the wing position has no effect on the autonomous functions. Bimode Mixers & wing position sensor still operate.
 This had a much better initial result - when I switched to RTB, the aircraft banked and yawed, and headed back towards home. It was high, so it pitched down some, and unfortunately, sped up. I didn't need it to come all the way back, so I switched it back to STB2, normal attitude controlled flight. But the shallow dive steepened, and perhaps I tried to pull up too hard and it stalled, but the dive deepened, it went inverted, tried to roll back, but crashed. Since repaired.
  This particular model has some issues with high speed - it tends to want to dive as speed increases, due to the larger wing area on the back wing. I have camber compensation in the front wing, but as its elevon is half the area of the rear, it seems its sometime not enough. I need to dial the speed/pitch on this model in better. Perhaps a bigger elevon in front. M3 is built with same size elevon in front - I'll test with it later.

[TheOtherCliff]

Ouch! ... 

You may know...  My understanding is that the FW throttle/pitch code assumes positive pitch stability (where an increase in airspeed causes airplane to pitch up) (this aircraft may have negative pitch stability ... outside of normal flight speed anyway).  The code climbs by adding power, and when the speed increases it (slowly?) adds up elevator (if needed) to maintain a more consistent airspeed.  There are throttle/pitch timing settings that are set to respond slowly to avoid throttle/pitch oscillations.

My understanding is that (assuming the airspeed sensor is working correctly) there was probably an increase in airspeed and it should have been slowly adding up elevator, but probably not quick enough to counteract the ?negative? pitch stability that was giving the equivalent of down elevator.

This throttle/pitch control is counter intuitive, but it's main advantage is that it doesn't stall if the motor fails or looses power, like on an autonomous mission, when you aren't there to handle the issue.  One disadvantage is that it is very slow to change climb angle on aircraft that could otherwise climb very quickly.  There are "cross trims" that I haven't played with to try to understand better.

[trust]

Been quite a while since last posting - back at work pretty non-stop so haven't had much time to work on the planes.
I've since rebuilt M24 with a larger front elevon - this significantly improved overall pitch stability.
Had a number of nice easy flights with it, so tried RTB again just recently. 3 test flights with 9 tests of RTB and all went pretty smoothly. Tried various positions, altitudes, angles to see how well it acted. Video links at end of this post.
Noticed a few things:
Perhaps this is due to its relatively fast flying speed, but there was very little altitude change from start of RTB to reaching point over home. I thought it was supposed to seek a fixed point defined in setup altitude over home.
The throttle display in the OSD doesn't seem to reflect the real throttle setting while in RTB - the value seems to stay the same as when it entered RTB. jdl know why this is?
Once or twice aircraft began a turn in the correct direction towards home, but then suddenly changed direction away from home, but then changed back. At 1:17 on part 2, it turns away for quite a while, turns back, then turns away again. Eventually gets back on track and returns. Bit of a nail biter there.
For the most part throttle would initially increase on initiating RTB, but then would back off. There was some surging in the whole process. Any thoughts on tuning to smooth the surging?
Here is a two part video with OSD from the Runcam on the first test flight.

[TheOtherCliff]

My past testing of RTB generally started fairly high and I was satisfied that it maintained the desired altitude, but it's been a while, and I did tune my throttle / altitude settings before I was happy with it.  Also my attitude limits to get it to turn sharper.

There is an altitude PID and thrust limits.  In one case the throttle was oscillating with a period of many seconds and I just hacked the thrust limits min/neutral/max to get a reasonable flying speed.  This is not the right way to do it.

Throttle increasing in the beginning and then backing off sounds like it has achieved the desired altitude.  Fixed Wing adds throttle (not elevator, at least not directly) to climb.

I would suggest telemetry.  Record telemetry during a bad flight, and play it back while watching appropriate scopes to see what is happening.  Enable different telemetry or change reporting periods as needed and fly again.  Watch out to not send too much telemetry data and swamp the link.

Is it possible that it changed from FW to VTOL?  And maybe there are other code tweaks that need to be made to make the switch work well.  To narrow it down, I would mechanically lock it in either FW or VTOL and fly stock firmware to see if it has the same issue.

Do I recall there were some bank and yank questions with this?  Is your ST2 mode set up as ATTI, ATTI, MANUAL and working well in that it feels good when you bank and yank?

I think that having both aileron and rudder stabilized in FW could cause issues.  If you bank and yank without rudder, the rudder will fight you.  RTB does bank and yank without rudder.  This is why I leave rudder set to manual in fixed wing autonomous flight (I haven't examined the code to see if this does what I hope it does).  I would mechanically lock it into FW, disable rudder stabilization and see if the bounce back is gone.

In VTOL mode it doesn't yaw to point forward.  It just flies sideways if that is how it starts out.

Don't know why OSD throttle doesn't change.

You may want to message @JDL.  He may miss the reference if he doesn't read the post carefully.

Good luck!

[trust]

Thanks for the suggestions.
I too hacked the throttle min/neutral/max settings along with the pitch min/neutral/max settings to get to this point. These actually were crucial in getting reasonably stable flight.
I have telemetry set up, so I can try taking some logs.
No, I don't think it is switched out of FW mode.
ST2 mode is ATT/ATT/Rate mode and works well now with the bigger front elevon. You definitely can bank to turn.
In reviewing the video again, I noticed that in all the times the plane turned away from the desired direction, it was after it had significantly pitched up - likely due to thermals or other lift. After the nose leveled out, it turned back in the desired direction. These might just be external forces trying to fight the turning. Fortunately it seems like the controls keep trying to move it in the right direction.
I checked the FW code- yaw is set to manual mode. I can tell its not changing in the videos sound - yawing is done with throttle differential and you can hear the combined up/down pitch shifts if a yaw control is happening at all.
I'm still puzzled as to why it seems to stay at the same altitude. The RTBAltitudeOffset is 10m - so it should be going to a point only 30 ft over takeoff.

[TheOtherCliff]

At the 1:17 time in video 2 I thought I heard throttle changes, from differential throttle?  Telemetry of either/both of:
- StabilizationDesired Yaw (easiest to interpret) and
- individual output channels
will tell if you are getting adverse yaw, but if the code sets FW yaw to manual then this is not the issue.

Now that you mention it, my recollection of the RTB altitude is that it stays at the higher of:
- current altitude (altitude when RTB was engaged)
- RTB altitude
so that would explain why it does not come down during RTB.  This is done so you can fly a long way up a gentle slope, do RTB, and not have it dive into the trees. 

I discussed the opinion that (if above RTB altitude) it should descend diagonally from current altitude to get to RTB altitude just as it arrives at base.  At least this should be an option.  Your RC signal will generally not work without line of sight, and this is safe as long as you have line of sight.  Else if you fly up a very steep mountain to great height, and then do RTB, you may not even see it or hear it when it gets to base (over head and way up high), and at least it will take a very long time to come down (dead battery?) if you have it switch to landing mode then.  If descending diagonally, the code could descend much more quickly than the default 0.5-0.7 m/s of landing vertical speed, and do it more safely because it has good forward speed too and doesn't get in it's own downwash so much as coming straight down.  Of course the current "landing mode at end of RTB" could descend faster than the landing speed until it got down to RTB altitude, but again, then you would be coming fast straight down in VTOL and that is often not so good.

When doing sharp banked turns in ATTI, ATTI, MANUAL (to mimic RTB), does it do fairly steep banked 360 turns well (without using the rudder control, to mimic the way RTB does it) in both directions, left 360 and right 360?

Does it turn better one way than the other?  Cross trimming is often necessary to get it to turn equally left vs. right.  Trim any left - right difference out with the rudder trim, then use opposite aileron trim to make it fly level after that.  Example: If it always tucks the nose in and dives in left turns but levels out / rolls out of the turn when banking right then you need right rudder trim to stop that and probably some left aileron trim to offset the new rudder trim.

[trust]

Ah, good to know its doing what it's supposed to!
In the last test flight of the day, I tried going up as high as I could see and then RTB - it came back, but was so high I could still barely see it.
I checked the code - you have it almost right - here's the relevant statement:
   destDown = MIN(positionStateDown, takeoffLocation.Down) - destDown;
 Since the Z axis is negative, min is really max, and the - destDown ADDS the offset distance to the end point. So it ends up coming back to a point offset distance ABOVE the point where RTB as initiated.
I have offset set at 10m and sure enough - the plane climbed to a point 10m above the point of RTB start in every case.
That also explains why the motor would accelerate just after initiating - it needed to climb.
I suppose you could set the offset to a negative value, then it would come back lower, but that seems risky if you start too low. Better to go a little high.
What I was referring to about the yaw sound is when yawing right for example, right side motors go down in pitch, left side goes up. Easily discerned from just increasing/decreasing - like chords vs simple notes.
I've done very little flying with yaw set in manual mode (other than autonomous modes). Most of the time turns are done with mostly yaw so as to be flat and more efficient. No difference turning left or right that I can tell. Even sharp turns are usually done with just yaw, but if taken to an extreme (max "rudder", or max differential thrust), one wing tends to stall and drop - there you DO need to bank as well to prevent that. Having props on 4 wings tends to keep airflow and keep wings flying except in extreme cases.I have a switch on the xmtr which mixes some rudder when rolling which I normally keep on, so it generally always does some "rudder" when banking, but I almost always add rudder too.
  I also have my rcvr set to switch to RTB mode if it loses signal - haven't actually tested in the field but goal was if it got out of range then RTB would bring it back into range.
  One goal is to plan flights to go high spiraling up, then mostly glide back down, using the aircraft for wx sounding or mapping. I suppose this could be accomplished just as well with waypoints. But if it goes out of range, RTB would just make it hover way up high out of range till the battery depleted - not good. I guess the rcvr would have to be programmed to fly the waypoints if signal lost, or make a new RTB option mode that flies it back to home+offset.

[jdl]

The throttle display in the OSD doesn't seem to reflect the real throttle setting while in RTB - the value seems to stay the same as when it entered RTB. jdl know why this is?

OSD displays value taken from manualcontrolcommand_throttle (throttle channel from RC remote), this is how it was coded in original MinOPOSD. In autonomous modes it still reflects the Throttle stick position.

We would like to see actuatordesired_thrust (the FC computed and then applied thrust) instead, while flying automomous modes.

I've made the necessary code changes but had not tested them yet.

Give me the firmware number (or build options) you are interested in. I'll compile and upload the firmware.

[trust]

Thanks for looking at this.
I've been compiling custom firmware versions of this, so it's more useful to me to have the code changes so I can recompile.
My main change was to include the call sign text in the display - I just hard coded it - the menu system didn't seen to work for this.
I've been making extensive use of the OSD to debug flight issues along with my multiple cameras onboard. I do have separate telemetry but the OSD is quick and easy to use.