trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #90 on: May 18, 2021, 03:38:03 am »
Tried it - qualified success! I did two test 5-6m flights today in moderate 10-15mph winds - launched vertically and entered VR mode- held position against wind reasonably well.
The details of the flight mode tests are in the below video description - did VR mode both in vertical wing and hrz wing mode (VTOL and FixedWing modes internally). Interestingly in the wind in FixedWing mode it pitched up and held power sufficiently to pretty much hover in place - just what I'd like it to do.
RTB also went smoothly - feature I hadn't noticed before thanks to new OSD code was the RTB timer that counts down time to base. Gets a bit wobbly in the turbulence today - not ideal but good test for windy, turbulent conditions.

Re: Bimode aircraft code changes
« Reply #91 on: May 18, 2021, 10:44:37 am »
Did you change the code as you had discussed?  Setting "Active Controller"?

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #92 on: May 18, 2021, 05:59:03 pm »
Yes, i used that exact code. Had to make "C" code references also, as the calling routines are in C, not C++

Still needs more testing but a big step forward.

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #93 on: May 21, 2021, 11:31:45 pm »
Updated firmware in 3 other planes, and tested another one today. M24 is a faster version of M1, with wider wingspan (5').
Windy day, not ideal for testing. 10-15mph some turbulence.
Tried hover takeoff aimed downwind - Hellaplanes can hold vertical wing mode easier with wind if pointed 90 degrees or 180 to wind. Not a great idea in this case - it lifted fine but drifted too fast downwind, and then transitioned to hrz wingmode, so didn't get a chance to test VR mode with vertical wings.
   VR mode in hrz wing mode worked fine - more pitch up than M1 to hold position, but plenty stable. Tested this several times - worked fine each time.
   Also tested RTB - the first time I had plane traveling 90 degrees to home - and although it rolled in the right direction, it didn't try to yaw and point back towards home, so it had trouble. It seems as long as I'm within +/- 30-40 degrees of the direction to home it works fine, but otherwise has trouble.
  In fixed wing mode shouldn't it try to yaw towards home? It seems like it ONLY does roll.
  Did several other tests of RTB pointed more towards home and those made it ok.

Re: Bimode aircraft code changes
« Reply #94 on: May 22, 2021, 05:59:18 am »
fixed wing RTB is effectively (shallow) bank and yank to turn
copter is yaw to turn and pitch forward to go

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #95 on: May 22, 2021, 06:50:06 am »
Ok. I'm thinking I could add a small amount of motor yaw on roll - I generally have to add rudder (motor yaw) to turn smoothly anyway. The motor yaw is VERY effective at flat turns.
On my xmtr I have a switch that adds rudder on roll if I want it. But that's useless for RTB.
Another area is the reverse - adding some roll when it yaws. One issue I've noticed is on dead stick unless it's perfectly balanced it will yaw one way or another in glide, since there's no motors to turn it. I can manually roll it and keep it straight, but it'd be nice to have the gyros control it.
  It'd be nice to be able to turn on or off these. For aerobatics you may want clean rolls - mixing yaw will upset that.
 

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #96 on: May 24, 2021, 12:40:38 am »
I tested today adding 25% of the roll input into the yaw on the motors. This didn't seem to either work or was insufficient to effect any yaw when using RTB.
  I'm looking at the code in FixedWingFlyController.cpp, and the code that sets stabDesired.Roll - shortly after it in the code was a note that at some point the yaw version was going to be added - but it currently is just set to 0.
  Why not just copy the same value into stabDesired.Yaw?
Then it would effect BOTH a roll and a yaw course correction - until it was lined up.
What do you think?

Re: Bimode aircraft code changes
« Reply #97 on: May 24, 2021, 07:33:09 am »
I suspect you know all about VtolPF and how it works.  Yaw to heading and forward pitch for speed.

I haven't looked at the FWPF code in a while, but I recall this is how it works.

First: Don't stabilize the rudder!!!  Fixed wing rudder/yaw should be manual, no rudder stabilization for any flight mode.  If you have rudder stabilized, set it to manual for all flight modes.  That may fix your problem.

Second: Scratch head about how Vtol configuration will have Rate stabilization on yaw and FW configuration will have manual on yaw/rudder.  Considering that this has a vertical stab which would limit yaw spinning in Vtol configuration, what do you think about flying Vtol with manual yaw?

The problem with stabilizing the rudder on FW is that when you go to make say a left banked turn with aileron and elevator (Attitude mode does this too), that you are yawing left in that left turn.  The stabilized rudder says "I see some left drift that I will correct" and applies right rudder, which badly messes up the turn.

After setting FW rudder stabilization to Manual, I suggest that you try to fly it in Attitude mode.  When you get it flying that way, FW RTB should work.

FYI: FWPF assumes that the airplane climbs when you add power and descends when you reduce power, that is how it controls altitude.

There is a "max bank angle" in FWPF called RollLimit.  To make a turn it banks the wings, that's all.  It banks a certain number of bank degrees per degree of course error (default is 0.2 per 1.0 as I recall).  It is flying in Attitude mode so when the nose drops, it automatically pulls some up elevator.

Airplanes (with dihedral) without ailerons, with rudder work fine with this.

Stabilization and control are generally the same thing inside the FC.  Think of the stick as simply saying where to stabilize it.

I don't think you should mix rudder and aileron.  To get what you need, you would need to do that at a low enough level so that when the FC stabilizes the bank, that it is applying rudder at the same time, and that gets back to what we were trying to avoid, especially when that mix needs to change based on whether it is currently a Vtol or a FW.  Your roll should be just a roll and nothing else.

FWPF by default makes very wide turns, to avoid steep banking, dropping the nose and recovering.  I wanted a tighter PostiionHold / RTB-at-base, so one of my changes is to automatically add some up when you bank, to avoid the nose drop and recovery.

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #98 on: May 24, 2021, 09:24:34 am »
I normally fly with roll & pitch set in attitude mode, and yaw in rate mode.
In fixedwingpathfollower.cpp,  function FixedWingFlyController::updateFixedDesiredAttitude seems to do most of the work, and it sets pitch and roll to attitude, and forces yaw to be manual mode - so no need to set it.
I have no "rudder" in the conventional sense of a vertical control surface moved laterally. There is however a big vertical stabilizer.
I do yaw primarily with differential thrust on the motors - which works very effectively - except when flying dead stick. Then I have to fall back on the elevons to roll it, and pitch to change direction. The Hellaplanes do very nice efficient flat turns with the differential thrust. But a side effect of no vertical control surface & a big vertical fixed surface is it tends to fly like an arrow - if you roll - you just roll - it doesn't yaw much.
That's why I'm having trouble with RTB.
  It appears that VTOL and FixedWing each have their own  separate defining functions - so I dont think I need to worry that a change in FixedWing will affect VTOL mode. At least now that the mode switching appears to flip states and controllers based on wing position.
  So it seems to make sense to me to just copy the roll course correction value to the yaw in FixedWing mode in function FixedWingFlyController::updateFixedDesiredAttitude instead of leaving it 0.
  Yes, the course correction is multiplied by FixedWinfgPathFollowerSettings CoursePI.Kp which defaults to 0.2. The same value for yaw would be in the ball park - that's why it seems like it should work.

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #99 on: May 25, 2021, 12:44:14 am »
Well, it didn't work. Not sure why. Looking deeper. Didn't seem to affect yaw at all in RTB.

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #100 on: May 25, 2021, 06:27:48 am »
In digging deeper in the code, I suspect I am not feeding the correct number type or mode to stabDesired.Yaw. It is set to Manual mode, whereas pitch and roll are in Attitude mode. Roll is in degrees of bank plus or minus from 0.
  In looking at the video with OSD when I initiate RTB - when the aircraft is pointed back towards home within some small difference of angle, it banks in the correct direction and stays banked until it gets close to home.
  If I initiate RTB with aircraft pointed outside some angle - maybe more than 30 degrees (I typically try worse case, flying away from home) it initially banks in the correct direction, but very quickly (a second or so) gives up and appears to go into position hold mode - it just goes into a hover - pitch up and hanging in place or drifting slowly forward. Is that the default error mode?
If I want to use yaw (makes sense to me), what mode would it make sense to use? Rate mode instead of Manual?
What range of numbers does it need? Do I need to compute the yaw angle relative or absolute?

Re: Bimode aircraft code changes
« Reply #101 on: May 27, 2021, 08:04:43 am »
If you can fly FW with bank and yank, just alieron and elevator, then I would guess that RTB should work.

I always get (Manual, then Rate, then) Attitude mode working before I try RTB.  What happens with Ail/Ele in Atti, rudder in manual (not RTB)?

"hover - pitch up" Are you saying that it is transitioning into Vtol configuration?

As I recall... The GPS flight mode code calculates the number of degrees of aileron bank, based on the error in the direction of flight.  That doesn't translate directly into yaw, unless you want to try maybe yaw rate and degrees per second instead of bank degrees.

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #102 on: May 27, 2021, 06:46:39 pm »
I've tested the plane in rate,rate,rate mode (roll,pitch,yaw) and it flies fine, although generally as I mentioned it tends to just fly in the direction pointed at - so roll, pitch doesn't turn very well at all - it needs yaw to turn.
  When it is flying in horz wing mode, I usually fly in att,att,rate mode (roll,pitch,yaw) - have not tried manual mode on yaw explicitly.
  When the plane is flying level and the direction is more than 30 or so degrees from a heading back at home, and I switch to RTB, it initially seems to try to bank to the correct direction, then seems to give up and the nose pitches up and it seems to be in position hold mode, but flying as a fixed wing aircraft. It hasn't - yet - done a transition of the wing to vtol mode by itself - but its getting close to the conditions needed to do that when it pitches up at a steep AOA.
  It seemed to me that the bank angle could be a proxy for the yaw degrees per second with appropriate scaling. I tried that and thought I saw a slight shift in yaw. I scaled it up by a factor of 10 and tried it again. But it still didn't work. I don't see any concrete evidence it is yawing at all.
   In a curious twist, in high wind in the last test, when flying away from home & switch to RTB, it pitched up far enough that it then started drifting back towards home - the right way but a wasteful way to get there.
  Are the polarities the same? If I bank to the right it is a positive angle. If I send yaw a positive angle/sec, should it not turn clockwise - turn to the right? The displays show it that way.

Re: Bimode aircraft code changes
« Reply #103 on: May 28, 2021, 01:12:35 am »
in rate,rate,rate mode (roll,pitch,yaw) and it flies fine, although generally as I mentioned it tends to just fly in the direction pointed at - so roll, pitch doesn't turn very well at all - it needs yaw to turn.
This is a description of what happens with a stabilized yaw, when you try to fly "bank and yank".  This is why I suggest that you fall back to testing "bank and yank" (no yaw stick in turns) Atti FW with yaw set to Manual, not Rate.

  Are the polarities the same? If I bank to the right it is a positive angle. If I send yaw a positive angle/sec, should it not turn clockwise - turn to the right? The displays show it that way.
Generally speaking, yes, but when you start throwing input and output reversing into the question, then it becomes a question of where you are measuring the polarity.

Get it flying in Atti,Atti,Manual "bank and yank" (no yaw stick in turns).  I would suggest trying it locked in FW configuration.  If that fixes the issue, then try it in Vtol.  The large vertical stab will limit the spin rate which might make it possible to trim the manual yaw well enough for it to be flyable.
« Last Edit: May 28, 2021, 01:17:42 am by TheOtherCliff »

trust

  • ****
  • 261
Re: Bimode aircraft code changes
« Reply #104 on: May 28, 2021, 02:38:33 am »
There isn't an issue with flying it either in VTOL or FW modes in one of the stabilized modes - either with yaw set to manual or rate. Its harder to fly with pitch and roll set to rate mode, but that's what I use for aerobatics.
Yes, in yaw rate mode it will stabilize and fly more like an arrow - but when I switch to FW RTB, according to the code it sets the yaw to manual mode - so its not using rate stabilization.
Here's the code that sets that in FixedWingFlyController::updateFixedDesiredAttitude:
    stabDesired.StabilizationMode.Roll   = STABILIZATIONDESIRED_STABILIZATIONMODE_ATTITUDE;
    stabDesired.StabilizationMode.Pitch  = STABILIZATIONDESIRED_STABILIZATIONMODE_ATTITUDE;
    stabDesired.StabilizationMode.Yaw    = STABILIZATIONDESIRED_STABILIZATIONMODE_MANUAL;
    stabDesired.StabilizationMode.Thrust = STABILIZATIONDESIRED_STABILIZATIONMODE_MANUAL;

    StabilizationDesiredSet(&stabDesired);

Yet if I feed it some yaw, it does nothing that I can tell. In manual mode yaw it should turn in the direction given by stabDesired.Yaw shouldn't it?