Re: Bimode aircraft code changes
« Reply #105 on: May 28, 2021, 04:20:07 am »
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.
« Last Edit: May 29, 2021, 09:52:00 am by TheOtherCliff »

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #106 on: June 07, 2021, 10:15:51 am »
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.

Re: Bimode aircraft code changes
« Reply #107 on: June 07, 2021, 10:55:26 am »
... 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

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #108 on: June 08, 2021, 03:14:04 am »
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.

Re: Bimode aircraft code changes
« Reply #109 on: June 08, 2021, 07:57:33 am »
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.
« Last Edit: June 08, 2021, 08:25:50 pm by TheOtherCliff »

Re: Bimode aircraft code changes
« Reply #110 on: June 14, 2021, 04:12:07 am »
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

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #111 on: June 30, 2021, 06:21:28 pm »
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.

Re: Bimode aircraft code changes
« Reply #112 on: July 01, 2021, 04:14:59 am »
Ouch! ...  :o

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.