LibrePilot Forum

Users => Vehicles - Other => Topic started by: trust on February 13, 2021, 05:57:53 pm

Title: Bimode aircraft code changes
Post by: trust on February 13, 2021, 05:57:53 pm
I've successfully compiled the next version firmware and GCS code, and have been pouring over the source files and documentation to understand the process better.
  Several friends and I have developed a tilting wing aircraft we call Hellaplanes, capable of vertical takeoff and hover, transition to horizontal flight, and then back again for landing.
  My initial goal is to add a switch mode capability that will flip between VTOL and FixedWing flight modes.
Initially, this is to allow control over the behavior in autonomous modes so it does the more appropriate action depending on the wing mode.
  But additionally I'd like to control the mixer behavior and PID settings for each of the flight modes - so the switch would also be used to switch between two sets of mixers and PIDs.

  Steps:
1) Add xml file to uavobjectdefinitions with defines for bimodeflag - setting if true, enables bimode operation, false- normal op
   bimodeswitch - which accessory switch used for bimode
2) Add filename to uabovjects.inc - in all versions or just ones we anticipate using (CC3D, Revolution)
How do variables show up in the Data set? Important to see what state things are in.
3) add conditional code in getcurrentframetype that returns the aircraft type based on the mode and switch

This first part should allow testing of the switch mode enabled bimode.
Then the harder part - setting up a second set of mixers and PIDs controlled by the switch.
Does this make sense? Am I missing steps?

Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 14, 2021, 04:52:48 am
What you suggest is closer to a real enhancement.  What I was talking about was much simpler.

Use the single current mixer.
I assume you only need 6 mixers of 12.  If more needed, start by doubling what you need and increasing current channels to that (say 14 or 16).
Have an offset per flight mode (basically 0 or 6) that is stored like the AssistedMode (for instance) is stored.
Hard code or decide a way to decide what offset is what vehicle type (e.g. fixedwing or VTOL)
Find all the places that access the vehicle type.  There are several and not all have the TreatCustomCraftAs override.  Write a function to replace this duplicate code.  That code will also be modified to look at the new offset to vehicle type setting (know what vehicle type e.g. FW or VTOL, it is by the FMS position).
Modify the mixer / actuator code to know what the offset is (based on switch position) and use that when accessing the mixer to determine e.g. whether to use mixer[0] or mixer[6]
and thus which output channel to use e.g. when code calls for roll (e.g. when moving the roll stick or when FC stabilizes in the roll axis)

No new UAVO's and all the stuff that needs to be (understood and) done for that such as
  *SettingsInitialize();
  *ConnectCallback();
not to mention a LOT of learning curve stuff.

Use banks to allow different PIDs for the different flight modes.

Aircraft will know it is VTOL in one mode and FW in another mode.

I know the code well enough that this is a 1 day code, 1 day test enhancement.

A later enhancement would move RotateVirtual to the bank settings so that for instance a tail sitter could have two different angles for "aircraft is level".  Tail sitting hover (nose up) and fixed wing flight (nose out), and you could do attitude mode or GPS modes in either configuration.  An enhancement of that could have a tail sitter airplane take off vertically as a VTOL, fly a mission in FW, and land in VTOL.

This fuller version enhancement would be usable for flying a quad as X or + in flight.  That is how I would test it.

The complete enhancement would include the following that allows smooth timed transition from one mode to another, like if a slow servo controls the wing tilt.  Whether the aircraft is stable or flyable when between modes is a subject for discussion and if generally not, then this part of the enhancement is not useful.  This section contains some coding comments I wanted to document while they were in mind:
- "Gated control" where gate=-1 copies inverted input to output, gate=+1 copies non-inverted input to output, -1 <= gate <= +1
- Gated control could be implemented as a smooth "parametric equation" of two mixers (or two sections of one mixer) where at t=0 you are using one mixer, at t=1/2 you are using a mixture of the two mixers, and at t=1 you are using the other mixer.  But I wonder if there are simple cases that need a "gated control" rather than the whole "mixed mixers"
- Each change of the mixer parameterization ... outputs to a temporary mixer that is used for flight, but is not stored anywhere.
- Gated control SHOULD be implemented as a smooth "parametric equation" of two mixers and not as individual gated controls.  That allows each new temporary mixer parameterization to be calculated at low priority with very little change to the code that uses the mixer to output real time variations in stabilization.  No new large number of gated controls to be calculated in the high priority output tasks.
- PIDs from initial and final PID banks would be mixed into "current PIDs" this way as well.
- The VTOL / FW status (e.g. how to hover with GPS) would be switched at some point in the transition...
- Timed signal which runs the signal output from X to Y in Z seconds.  This would cause the slow, smooth configuration change from first mixer to second mixer.
- Connections FROM RC inputs and stabilization outputs
- Connections TO actuators, mixer tables, PIDs, config state (FW / VTOL)
- Fixed value signals?

With that, a flight mode switch or accessory switch could do an instant or timed flight configuration change, or a pot could allow you to fly at any flight configuration even halfway between the two normal modes.
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 06:49:30 pm
Ah, I see you meant to use the switch position to just offset the mixer use into another area of the EXISTING mixer banks.
Since I only use 6 (possibly 8) and only two(possibly 3) are really needed for this, that should work using the existing 12 mixers.

I'm not too concerned about blending - the transitions are generally quite fast - (fractions of a second) - so aircraft doesn't have much time to make changes anyway.

Just using the flight mode switch could work as well especially if combined with a second switch to get 6 possible modes.
3 PID banks is skinny but might be ok - right now we use only one for both, but have an "aerobatic" mode which just uses rate mode for everything (primarily used in hrz flight mode) and "attitude" mode for hover and simpler hrz flight (works surprisingly well). These both have different PID values.

It seemed that the function getcurrentframetype - is used almost everywhere to determine modes, so adding the code there to select dynamically made sense to me.

But I'm still trying to understand the code environment - how is information defined that goes in the Data Objects set under System? That seems like a simple way to monitor what is happening inside FC.
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 07:03:11 pm
Not sure why it used an emoji instead of the number eight - but in reflecting I need at least 12 mixers (6 for VTOL mode, 6 for FW mode), and on Chris aircraft 16 (he uses 8 output channels, although now we just use a second FC and it is only used for simple hardware mixing - but we may want to change that).
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 07:41:33 pm
Looking through the code again, I can't but help to think it would be easier to just make an xml file MixerSettings2 - exactly the same as the base version but just another copy.
I don't need to change it through the GUI if I can change it in the System tab settings.
Then all I need to switch is pointers to the different data sets.
Other than more data space needed is this a problem?
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 09:07:43 pm
I created xml bimode.xml:
<xml>
    <object name="BiModeSettings" singleinstance="true" settings="true" category="Control">
        <description>Settings for the @ref BiModeModule</description>
   <field name="BiModeSet" units="" type="enum" elements="1" options="False,True" defaultvalue="False"/>
   <field name="BiModeMixerOffset" units="" type="uint8" elements="1" defaultvalue="6"/>
   <field name="BiModeSwitch" units="" type="enum" elements="1" defaultvalue="Accessory1">
      <options>
              <option>Accessory0</option>
              <option>Accessory1</option>
              <option>Accessory2</option>
              <option>Accessory3</option>
              <option>Accessory4</option>
              <option>Accessory5</option>
      </options>
    </field>
       <access gcs="readwrite" flight="readwrite"/>
        <telemetrygcs acked="true" updatemode="onchange" period="0"/>
        <telemetryflight acked="true" updatemode="onchange" period="0"/>
        <logging updatemode="manual" period="0"/>
    </object>
</xml>

Added this to the directory with all the xml files.
I also added the name to the list in flight/targets/boards/revolution/firmware/UAVObjects.inc

It gets through the UAVobjectgenerator, and compiles many files, but gens this error:
mingw32-make[1]: *** No rule to make target 'E:/librepilot/hellaplane/build/firmware/uavobjects/bimode.c', needed by 'E:/librepilot/hellaplane/build/firmware/fw_revolution/bimode.o'.  Stop.

Am I missing some setup?
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 10:43:23 pm
I found the issue with the uavobject generator, and now it's generating & compiling. It appeared to also generate firmware.
I tried compiling the GCS - and it did, but when I try to run it there are .dll's missing, so it doesn't work.

I'm having issues with the build environment.
When I clean, it doesn't clean the directories. All the firmware is still there.
Is there some absolute directory structure it is looking for?
I get this:
 CLEAN      build
rm: fts_read failed: No such file or directory
mingw32-make: *** [Makefile:187: all_clean] Error 1

I am running it in the top level directory where the makefile is.
Frustrating.
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 10:51:15 pm
Ah, well never mind.
I ran the separate firmware and gcs clean functions - those seem to do the trick.
Title: Re: Bimode aircraft code changes
Post by: trust on February 14, 2021, 11:02:20 pm
I did find what seems to be the cause of some of these build errors.
The directory starting from needs to be 2 levels down.
Ie: e:/librepilot/xxx
NOT
e:/librepilot/something/xxx
For some reason it has trouble backing up one level somewhere in the makefile code.
When I do seperate firmware and gcs cleans they work cleanly now.
Title: Re: Bimode aircraft code changes
Post by: trust on February 15, 2021, 12:09:35 am
I'm able to compile and link firmware, and compile & run the GCS successfully, but I can't see my bimode data set anywhere in the Settings or Data Objects. I haven't changed any firmware yet, only added the .xml files.
   The doc pages don't seem to provide correct info now on where to add this.
?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 15, 2021, 09:31:21 am
It seemed that the function getcurrentframetype - is used almost everywhere to determine modes, so adding the code there to select dynamically made sense to me.
But not every place also checks TreatCustomCraftAs.  I thought to put that test and the new "switch position defines aircraft type" all inside GetCurrentFrameType

But I'm still trying to understand the code environment - how is information defined that goes in the Data Objects set under System? That seems like a simple way to monitor what is happening inside FC.
The Data Objects are set by the running code.  Things like current measured aircraft roll angle and the like.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 15, 2021, 09:36:32 am
Not sure why it used an emoji instead of the number eight - but in reflecting I need at least 12 mixers (6 for VTOL mode, 6 for FW mode), and on Chris aircraft 16 (he uses 8 output channels, although now we just use a second FC and it is only used for simple hardware mixing - but we may want to change that).
8 followed by ) is the sunglasses emoji

Do all those 8 output channels all come from the 4 control stick functions and all go through the mixer?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 15, 2021, 09:42:36 am
Looking through the code again, I can't but help to think it would be easier to just make an xml file
You should watch the OpenPilot Webinar (youtube / vimeo) for more insight into creating a new UAVO.
There is way less to learn to add to existing UAVO's than to create a new one.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 15, 2021, 09:50:28 am
I'm able to compile and link firmware, and compile & run the GCS successfully, but I can't see my bimode data set anywhere in the Settings or Data Objects. I haven't changed any firmware yet, only added the .xml files.
   The doc pages don't seem to provide correct info now on where to add this.
?
IIRC if you start with a copy of a current Settings xml file and modify it to be what you want, then simply cleaning and building the GCS should show it in System -> Settings.  Wrong: It needs to be in uavobjects.pro too.
It will be grayed out until you get firmware changed to init the new UAVO.  It becomes active when the GCS sees the firmware talking about the new UAVO.
Title: Re: Bimode aircraft code changes
Post by: trust on February 15, 2021, 11:47:46 pm
No, I am adding a bimode.xml file. Not the wisest move I'm starting to think, but there it is. I might as well try to understand more of the underlying mechanics in setting up modules.

I've been watching the vimeo openpilot 2+ hr video. I'm creating a bimode module to add. I'm following the guidelines as best I understand from the video.
  What is still unclear is how/where the data for settings gets added. Is it in Initialize? Or Start? Do I have to allocate the memory for it explicitly or is there functions which do it?
  Same for Data Objects.
Attached is what I have so far.
Title: Re: Bimode aircraft code changes
Post by: trust on February 16, 2021, 12:01:08 am
If I add bimode.xml to the .pro file:
ground/gcs/src/plugins/uavobjects/uavobjects.pro
When I make the gcs, it gives me an error
bimode.cpp not found.
But its a .c file in Module bimode.
?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 16, 2021, 07:43:54 am
  What is still unclear is how/where the data for settings gets added. Is it in Initialize? Or Start? Do I have to allocate the memory for it explicitly or is there functions which do it?
  Same for Data Objects.

The default value for settings is part of the xml file, from there, either GCS or firmware can change them.

I suggest you examine the source to find examples of code to set up and run a UAVO.  I wouldn't remember all the details.

If I add bimode.xml to the .pro file:
ground/gcs/src/plugins/uavobjects/uavobjects.pro
When I make the gcs, it gives me an error
bimode.cpp not found.
But its a .c file in Module bimode.
The GCS source files are cpp  The firmware source files are c
Title: Re: Bimode aircraft code changes
Post by: trust on February 16, 2021, 09:41:54 am
I've been going over examples, the docs, and the webinar.

The bimode.xml file generates the .c and .o files from the UAVobjectgenerator for the firmware fine. I see it creates the BimodeInitialize routines and the defaultset functions. I don't see any Start function autogenerated.

I don't see any evidence that it has made the complementary files for the GCS - the .cpp files - shouldn't it be making them too? Without them how does the GCS know where to read the Settings?

The docs seems to refer to directories that don't exist, or are in different places than in the docs.

I found by poking around that I add Modules compiling for firmware in a Makefile.
The .c & .h code generates to build/firmware/uavobjects
The compiled .o & .lst files go in /build/firmware/fw_revolution (or whatever board)
The GCS  .cpp & .h files generate to /build/librepilot-gcs_release/src/plugins/uavobjects

Implication is bimode.xml should have GCS files generated, but there is no evidence they exist.
How do I get it to generate it?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 16, 2021, 12:37:32 pm
It's been a while since I created a UAVO from scratch.  I would do the following to find all the places touched when I added the uniquely named "systemident" UAVO settings and data object.  Skip past all the files you find in the build/* tree since they are all auto-generated.

   grep -ir systemident *

that generates a list:
flight/modules/AutoTune/autotune.c
flight/targets/boards/revolution/firmware/UAVObjects.inc  (and other boards)
ground/gcs/src/share/qml/js/uav.js
ground/gcs/src/plugins/uavobjects/uavobjects.pro
(xml file(s))
(flight side .c files to implement the UAVO)
(other flight side changes where it interacts with other stuff)

Or I would research the git revision where it was added for the first time using gitk.  That would give you a list of files and their diffs.
Title: Re: Bimode aircraft code changes
Post by: trust on February 16, 2021, 09:00:06 pm
It was adding the xml file to ground/gcs/src/plugins/uavobjects/uavobjects.pro that was needed.
Now I see the entries showing up in the System Settings.
I was still having trouble creating the bimode module - when I tried to generate the GCS, it kept asking for a bimode.cpp file which didnt exist.
But I changed the filename to bimodefun.xml, and tried again.
Now it generates both firmware and GCS. I had to change the field name of Switch also - conflicts with use of switch in c!
Progress.
Title: Re: Bimode aircraft code changes
Post by: trust on February 16, 2021, 09:39:24 pm
I was trying to understand what the difference was in a data block for Settings, vs the Data Objects under System tab.
It seems the telemetrygcs acked="true" puts it in settings, "false" puts it in Data Objects.
Maybe the other telemetry parameters affect it also - at any rate I'm able to put a status object there so I can check to make sure the code is changing the state.
Title: Re: Bimode aircraft code changes
Post by: trust on February 18, 2021, 08:52:39 am
Made a great deal of progress.
I ended up creating a second xml file MixerSettings2 - a duplicate of MixerSettings, which contains the settings for the alternate flight mode.
I enabled the mixerstatus for debugging - so I can see the output of the mixers.
I set up the 7th mixer as an Accessory0 channel for the mode switch. I have a BiModeStatus flag in Data Output I can also check to make sure what state it is, but I can also see it in the Mixer7 output.

I can enable/disable the bimode mixer with the flag in BiMode, and select which channel is used.

I set up some real world values, armed it and increased throttle - I can see values in Mixers1-6 change as they should.
But when I set mode to the alternate mode, they all go to 0.
The way I alternate is in ProcessMixer there is a pointer, mixer, that points to the mixer data set.
If I switch to the alternate, I simply overwrite mixer with a pointer to the alternate data set. Since it looks like the code in ProcessMixer all uses that pointer, it should work.

Another question - my settings don't seem to save from one session to another - although I can export the new version settings and import them and get them all back. How do I save them to Flash? Normally I just use the up arrow green button and that saves it to Flash - it uploads it but doesn't save it after power off.
I can save into Flash with the normal versions of GCS I use - just doesn't seem to work here.
?

Other than the xml files, so far all the code is in Actuator_Bimode.c - modifications to Actuator.c
If others want to look at the code, how should I upload it? I can do it here as attachments, but if it gets to be a bunch of files...
Title: Re: Bimode aircraft code changes
Post by: trust on February 18, 2021, 09:46:55 am
Whoa. Think I got it working! I needed to add the     MixerSettings2ConnectCallback(MixerSettings2UpdatedCb);
function in ActuatorInitialize so it updated the second mixer.

I can now toggle the state switch and see the changes in the mixer output based on the second mixer.
Cool!
Haven't tested in real aircraft yet, just debugging.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 18, 2021, 11:12:26 am
Press the red up arrow "Save"

and sounds like you have got a lot done!

To save confusion, I would get it tuned and working on a stock version, then just copy the settings to the test version, and try it in both normal mixer and alternate mixer modes.  This way, if anything goes wrong, you know that it is code and not tuning etc.   ;)
Title: Re: Bimode aircraft code changes
Post by: trust on February 18, 2021, 09:02:58 pm
Pressing the red arrow doesn't save it. If I power down, all the settings on the new modules are lost.
?
Title: Re: Bimode aircraft code changes
Post by: trust on February 19, 2021, 07:45:59 am
If after importing the UAV file, I press the Save to Flash tab on the import window (and wait for it to complete) - it DOES save the settings - including the new ones I created - to Flash, and they are there after power cycling. Not sure why the red arrow doesn't work.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 19, 2021, 12:15:02 pm
Red arrow on System page to be clear...

and the item to be updated MUST first be highlighted by clicking on it once.
Title: Re: Bimode aircraft code changes
Post by: trust on February 19, 2021, 08:26:51 pm
How can I tell if I'm running out of available space on the FC?
I usually look at .map files output from the linker, but I'm unfamiliar with these processors size limits.
We're using the mini Revolution and Atom FCs.
Title: Re: Bimode aircraft code changes
Post by: trust on February 19, 2021, 08:38:34 pm
I tried changing one of the bimode flags, highlighted and hit red arrow. There was some activity - but when I powered off and rebooted, processor went into lost its mind mode - booting and rebooting.
I did a rescue, reload & flash firrmware, erase settings, import settings and flash, and got it back working.
Title: Re: Bimode aircraft code changes
Post by: trust on February 21, 2021, 05:56:11 pm
I use the OPLINK MINI Air and the OSD devices when I'm testing as they make it much easier to save & load data, plus do calibration, and keep an eye on the battery status.
  I used mingw32-make -j4 oplinkmini (had to add the bimode files to the make file, but then it linked ok)
 & mingw32-make -j4 osd
to make the firmware for these - do I need to add the -j4 reference?
  On the OSD, what device is this for? Is it the miniOSD or something else?
I tested the OPLINK Mini Air with the new firmware - it seems to work ok.
But the OSD battery monitor is acting odd - voltage is fluctuating up and down. Attitude looks ok.
I suspect it needs a different firmware applied - this is the version JDL made, so I suspect it needs an update.
Title: Re: Bimode aircraft code changes
Post by: trust on February 22, 2021, 07:52:15 am
Did flight testing of bimode code today - bit windy 10-12mph but nice clear day. Some turbulence.
Successful 2 flights - first one most of the flight was in hrz wing mode with switch set to alternate mixer - and functioned pretty much as expected. Eliminated the mild roll oscillations that have been an annoyance. Seemed solid and smooth. All flight in roll & pitch attitude mode, yaw in rate mode. Take off in VTOL mode (vertical wing mode), rotated to hrz wing mode then flipped switch to alternate mixer. That switch also adds some front wing camber so it pitches up slightly (I adjusted it down some in flight). With too much wind doing the transition back to vertical wing mode is difficult, so went around - then noticed very low on battery so landed bit too abruptly.
  Next will test all rate mode, then test internal switching of aircraft type via switch (applies mainly to GPS special modes - RTB, VH, etc).
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 22, 2021, 09:26:22 am
-j 4 is -jobs 4
This is what you want if your computer has a quad core CPU.  It compiles 4 files at a time, so the build is quicker.

OP/LP OSD is some code for old stuff that is not helpful for you.

You want the @JDL code.  If you modified any UAVOs that are read by the JDL OSD telemetry you will have to rebuild and reflash @JDL after possibly making some code changes to add the new fields (still needed as space holders if not used) and identify with new magic numbers.

Sounds like you have gotten over the hump and into the place where the aircraft is doing the technically correct thing.  Great going!  If I were you I would have a big satisfied grin on my face.   8)  ;)
Title: Re: Bimode aircraft code changes
Post by: trust on February 22, 2021, 10:17:19 am
Celebrations were had earlier! Still, best to get more tests in - and on other aircraft. Also testing with the GPS modes.
Oddly the OSD did not have the same odd voltage variations during the tests today. I downloaded the 2.57 version of the JDL OSD code. Can I compile it within the same OSD framework? Compile help appreciated.

Another variation I'd like to set up with the mixers is a "always manual" mode. There are a lot of unused mixer channels, and I'd like to allocate some to do just straight mixing without the PIDs & attitude modes affecting the roll/pitch/yaw axis data & just use the receiver data. Maybe I'm missing something - does this already exist? Right now I use 2 channels on the receiver to output the front elevon data mixing a knob (for camber/reflex) with a switch (to enable/disable - which right now is also my V/H mode switch). I could regain one of those with onboard mixers.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 22, 2021, 11:44:29 am
@JDL is OSD man...  :)

PID is applied to signal before the mixer because the mixer may e.g. affect four actuators for e.g. X quad roll function.

PIDs only affect roll/pitch/yaw, so they don't affect anything like e.g. accessory #2.  You map a transmitter channel straight to an output channel on Vehicle page Accessory setup.  Then you tweak that accessory channel for e.g. servo max, min, neutral on the Output page.  This allows you to use a single wire carrying all channels from receiver e.g. SBus and connect some of those channels to servos.

There isn't any generic mixing other than for the 5 flight functions (a/e/r plus a pair of throttles) that go through the mixer table.
Title: Re: Bimode aircraft code changes
Post by: trust on February 22, 2021, 10:47:01 pm
How do I compile just the code for the Atom FC? Is it coptercontrol? Do I need to re-make the GCS to also use the Atom FC?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 22, 2021, 10:58:55 pm
How do I compile just the code for the Atom FC? Is it coptercontrol?
Atom == CopterControl3D
Electrically the same.

Do I need to re-make the GCS to also use the Atom FC?
No.  You only need to remake GCS if you change GCS code or UAVOs or add a new FC that was not supported before.
Title: Re: Bimode aircraft code changes
Post by: trust on February 24, 2021, 05:40:47 am
I've generated the Atom firmware using coptercontrol as the firmware parameter.

For the most part it looks like it works except for one major problem. The receiver channel 1 is being corrupted somehow - when I look at inputs it is constantly changing from neutral to max value - even when no control inputs are applied to the transmitter.
Even if Ch 1 is not selected as an active input for any control function, Receiver activity indicates channel 1 is active. Ch 1 is active even when the transmitter & receiver are off!
As a result it won't arm & input flag remains orange.
All the other channels seemed to work fine.
I also tried configuring the Atom FC in PPM mode to simplify the hookup - but here I could not get any received data at all, although the receiver being tested was tested with a Revo FC in PPM mode and worked fine.
  I wonder if there is some configuration parameters that are not being set up properly for this FC.
Any ideas? Where is the receiver set up code? Its not in receiver.c

Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 24, 2021, 10:58:57 am


The receiver channel 1 is being corrupted somehow - when I look at inputs it is constantly changing from neutral to max value - even when no control inputs are applied to the transmitter.
Even if Ch 1 is not selected as an active input for any control function, Receiver activity indicates channel 1 is active. Ch 1 is active even when the transmitter & receiver are off!
As a result it won't arm & input flag remains orange.
All the other channels seemed to work fine.
The fact that it changes even when disconnected is very suspicious.

multiple stacks to overflow (there is a stack scope and MEM health to look at), memory corruption (hardware debugging to see how it is being written on), priority issue, hardware

If you can write a function to detect the corruption and "print corrupt", you can write it to "print" the return address of the caller only the first time it detects corruption, and scatter it through suspect code sections and finally bisect to narrow down.

This is multi-tasking, so you can't sit in a loop waiting for something, you must wait for an event.

I would start by flashing stock firmware with stock GCS to see if it is a hardware issue.

I also tried configuring the Atom FC in PPM mode to simplify the hookup - but here I could not get any received data at all, although the receiver being tested was tested with a Revo FC in PPM mode and worked fine.
  I wonder if there is some configuration parameters that are not being set up properly for this FC.
Any ideas? Where is the receiver set up code? Its not in receiver.c
The startup at flight/targets/boards/coptercontrol/firmware/pios_board.c sets up all the ports.  Again, I would start by setting up the stock code.  That proves the hardware works and that you know how to configure it.  :)

CopterControl is very tight on memory.  You may want to remove some unused stuff or switch to Revo for a test.
Title: Re: Bimode aircraft code changes
Post by: trust on February 24, 2021, 10:03:16 pm
Under SystemStats, SystemModStackRemaining indicates only 20 bytes - seems far too little to work.
I haven't tried testing the normal compile codes, but this remaining space seems far too small.
May not be useful to continue to try to make this work on this platform.
We have plenty of the mini Revos for now we'll just test on those.
Title: Re: Bimode aircraft code changes
Post by: jdl on February 25, 2021, 09:47:37 am
.... I downloaded the 2.57 version of the JDL OSD code. Can I compile it within the same OSD framework? Compile help appreciated.

Arduino 1.0.5 package is used to compile to OSD source. Can be downloaded from: https://www.arduino.cc/en/main/OldSoftwareReleases (https://www.arduino.cc/en/main/OldSoftwareReleases)

Additionally, some extra library files are required. Extract into Arduino "libraries" folder.
https://github.com/jdlilov/MinOPOSD-JDL/tree/main/Sources/Arduino%20libraries (https://github.com/jdlilov/MinOPOSD-JDL/tree/main/Sources/Arduino%20libraries)

Don't forget to select in OSD_Config.h your desired build options!
Title: Re: Bimode aircraft code changes
Post by: trust on February 25, 2021, 05:51:48 pm
I'm not familiar with the arduino build make process.
Is there a command line entry that does that compile & link for your modified code?
Thanks
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 26, 2021, 07:26:10 am
With Arduino and similar you run the PC program which is an editor/IDE.  You connect the board via serial or USB depending on the board.  You load the source code from the disk into the IDE and you see it there in the IDE editor.  You press a button and it compiles the code and loads it into the board.  Make a change.  Press the button again, and see the changed code run.

It really is that simple.  It was designed to be easy to use so beginners could enter a few lines of LED blinker code, run it, and see an LED blink on the board.

Don't forget to extract those extra @JDL library files as he said.
Title: Re: Bimode aircraft code changes
Post by: jdl on February 26, 2021, 09:10:20 am
A hint: Easiest way to open the source in Arduino IDE is to just double-click on ArduCAM_OSD.ino file in Windows Explorer. This opens the associated program (Arduino IDE) and loads the source.

In Tools | Board select Arduino Pro or Pro Mini (5V, 16MHz) w/ Atmega328.

In Tools | Serial Port select the COM port your programmer is connected to.

This is all. Just Verify/Compile with the left-most button or Compile/Upload with the second one.

In case you don't have a programmer / RS232-TTL converter board, you can find the output HEX file in:

C:\Users\YOUR_USER_NAME\AppData\Local\Temp\buildXXXXXXXXXXXXXX.tmp\ArduCAM_OSD.cpp.hex

and upload it to the MicroMinimOSD board using OSD_JDL_Config.exe.
Title: Re: Bimode aircraft code changes
Post by: trust on February 26, 2021, 09:40:27 pm
Ok, figured out some, compiled the code, output hex file.
I only change one item in the OSD_config.h - uncommented #define NEXT_UAVO
// JDL: LP16.09 or "next" r.735+ UAVOs
#define NEXT_UAVO
Set the target processor & compiled successfully.

I havent uploaded the hex files to the boards yet - but I'm wondering how they know which version I am using?
I have new code - not the same NEXT version.
On the boards in the systems now, they boot up and display everything, but after a few seconds everything disappears except the status line - DISARMED.

So something needs to be updated - but where?
Is there some set of automatically generated defines from my build I need to be including?
I'm using a Revo board, so I want to make sure its generating for that.
Title: Re: Bimode aircraft code changes
Post by: trust on February 26, 2021, 09:45:51 pm
Its exactly 10 seconds after boot that it cuts out the main display - based on the OSD clock.
?
Title: Re: Bimode aircraft code changes
Post by: trust on February 26, 2021, 09:55:56 pm
Arg. I know what the problem is, not sure how to fix it.
JDL has hard coded channel 7 is OSD display toggle - which I now use as my arming switch!
How can I disable that?
Must be somewhere in the OSD code...
Title: Re: Bimode aircraft code changes
Post by: jdl on February 26, 2021, 10:00:24 pm
Unless you have changed existing UAVO IDs, nothing should be updated in OSD code.

I guess the FC firmware switches/commands the OSD to display Panel3 - the empty one, only warnings are displayed there. This will happen when Output Channel 7 is set to some high value... OSD monitors Cannel 7 to switch between OSD Panels.
Title: Re: Bimode aircraft code changes
Post by: jdl on February 26, 2021, 10:08:03 pm
Arg. I know what the problem is, not sure how to fix it.
JDL has hard coded channel 7 is OSD display toggle - which I now use as my arming switch!
How can I disable that?
Must be somewhere in the OSD code...

Look at line 505 in UavTalk.ino:

Code: [Select]
osd_chan7_raw = uavtalk_get_int16(&msg, MANUALCONTROLCOMMAND_OBJ_CHANNEL_7);

Also in OSD_Panels.ino:

Code: [Select]
void switchPanels()
Title: Re: Bimode aircraft code changes
Post by: trust on February 26, 2021, 11:44:52 pm
Yeh, I found that, and modified the code such that swithPanels ignores the code there for checking switch 7, and instead
sets panel=0 (which I assume is the main panel) and setup_menu_active = false; - which I assume if true enables the setup panel.

Now it ignores the channel 7, but it still seems to jump to panel 1 after 10 seconds.
There must be a timer somewhere that is doing this but where?
Title: Re: Bimode aircraft code changes
Post by: trust on February 27, 2021, 12:43:51 am
As a temporary "workaround", I set up everything in panel 1 the same as panel 0 - but then discovered that any attempt to enable the Horizon, gets a -1 index value and crashes the setup tool. It works fine on the first panel, but not the second panel.
So there is no artificial horizon (which is very useful), but everything else.
Title: Re: Bimode aircraft code changes
Post by: trust on February 27, 2021, 01:20:42 am
Aiiieee..
I discovered the Arduino compiler-
1) Does not check the files to see if they have been changed from another editor -so I have to exit and restart every time I make a change
2) Generates a new build directory EVERY time I make a change & recompile. I was using what I THOUGHT was the current version of the code when it was a previous build.

Now the code I modified- setting panel=0 - works fine - I can see panel 0 with the horizon.
"FIXED" LMFAO
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 27, 2021, 11:06:15 am
Besides creating your new XML UAVO file, did you change any other XML / UAVO files (anything that changes the checksum / md5sum, even a space or blank line or comment) that the OSD accesses?  If so, you will need to put the new structs and new md5sum into the OSD code.
Title: Re: Bimode aircraft code changes
Post by: trust on February 27, 2021, 08:53:44 pm
The only changed modules were actuator, sanitycheck, and adding mixersettings2, bimodefun, and bimodestatus - none of these last 3 are accessed by OSD.
It seems to be accessing parameters fine now, though I haven't done a flight test yet. Windy last few days.

I've upgraded 2 more of our Hellaplanes to use the bimode code - it's been a tricky getting the systems to add a 3rd switch and the camber adjust function - I need all 8 channels of input, and 8 channels of output for my Hellaplanes, and Chris needs 11 channels of output. I wanted a switch for arming - as I discovered several times when doing power off glide tests, holding the yaw stick can disarm in flight - not a fun thing to deal with. Fortunately was able to land successfully.
  I realized I can use the Throttle 2 curve input selector to select an Accessory adjustment knob input, and can scale it + or -, then add it to appropriate axis functions for each mode to get the front elevon functions needed using bimode.
  One minor code change I made as a consequence is the code that scales Accessory input functions on throttle2 curve was set to absolute value - I changed it to proportional, so the knob would go + or -.
  I ended up using a not-completely-functioning-properly Atom FC for 6 of the servos on Chris' plane in bimode - I worked around the Ch1 problem. I though his Orangerx 920 receiver would work in PPM mode, but it turns out the V1 receivers are s.bus output - I didn't discover this till yesterday. So I can fix his to run ALL control functions from the one Revo FC. It seems the V2 are PPM output, which I have on most of my planes. The v3 versions do not support DSM2, which is what I have on my transmitter (dang) - I've ordered a DSM2/DSMX xmtr module I hope to adapt to my Futaba 9.
Title: Re: Bimode aircraft code changes
Post by: jdl on February 27, 2021, 09:47:58 pm
As a temporary "workaround", I set up everything in panel 1 the same as panel 0 - but then discovered that any attempt to enable the Horizon, gets a -1 index value and crashes the setup tool. It works fine on the first panel, but not the second panel.
So there is no artificial horizon (which is very useful), but everything else.

This issue (Horizon cannot be enabled in Config tool in Panel 2) was fixed few days ago, please download the current version of Config tool if you need Horizon in Panel2.
Title: Re: Bimode aircraft code changes
Post by: trust on February 28, 2021, 05:38:08 pm
JDL - thanks, I'll try that.

I ordered 5 older versions of the Orangerx 8 & 9 channel receivers - they were supposed to be v2 with PPM but instead they are V1 with s.bus output. I currently have a DSM2 xmtr module on my Futaba 9.
I can make them work with the s.bus input on the main port.
But I need 8 channels of PWM output, and want to be able to run the GPS/mag module, the OPOSD module, & the OPLINK on my mini REVOs.
If I plug the GPS in the flex port, then I still need a telemetry port. I can allocate that on the rcvr in port, which can have multiple functions - but I don't see an option for BOTH telemetry and using the remainder of the pins as output pins.
  If there are enough UARTs to run all these devices, is there a way to make a special allocation code for telemetry+output?
I've been looking at the code, and found the place in pios_board.c where they set this up:
    case HWSETTINGS_RM_RCVRPORT_PPM:
    case HWSETTINGS_RM_RCVRPORT_PPMOUTPUTS:
    case HWSETTINGS_RM_RCVRPORT_PPMPWM:
    case HWSETTINGS_RM_RCVRPORT_PPMTELEMETRY:
    case HWSETTINGS_RM_RCVRPORT_PPMDEBUGCONSOLE:
    case HWSETTINGS_RM_RCVRPORT_PPMCOMBRIDGE:
    case HWSETTINGS_RM_RCVRPORT_PPMMSP:
    case HWSETTINGS_RM_RCVRPORT_PPMMAVLINK:
    case HWSETTINGS_RM_RCVRPORT_PPMGPS:
    case HWSETTINGS_RM_RCVRPORT_PPMHOTTTELEMETRY:
#if defined(PIOS_INCLUDE_PPM)
        PIOS_BOARD_IO_Configure_PPM_RCVR(&pios_ppm_cfg);

        if (hwsettings_rcvrport == HWSETTINGS_RM_RCVRPORT_PPMOUTPUTS) {
            // configure servo outputs and the remaining 5 inputs as outputs
            pios_servo_cfg = &pios_servo_cfg_out_in_ppm;
        }

        // enable pwm on the remaining channels
        if (hwsettings_rcvrport == HWSETTINGS_RM_RCVRPORT_PPMPWM) {
            PIOS_BOARD_IO_Configure_PWM_RCVR(&pios_pwm_ppm_cfg);
        }

        break;
#endif /* PIOS_INCLUDE_PPM */
    case HWSETTINGS_RM_RCVRPORT_OUTPUTS:
        // configure only the servo outputs
        pios_servo_cfg = &pios_servo_cfg_out_in;
        break;

I imagine I need to enable ONLY the output pins that are NOT telemetry pins, AND enable the telemetry pins (where is this done?).
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on February 28, 2021, 09:18:44 pm
This is starting to get into the complicated stuff.  :)  There is a data only .c file in that same area where most of the hardware configuration is stored in structures (e.g. probably pios_ppm_cfg, pios_servo_cfg_out_in_ppm, pios_pwm_ppm_cfg, pios_servo_cfg_out_in).  Then there is either jumping in and trying what looks like it will work or researching the PIOS layer and finally the functions and limitations of the processor in question as it is wired in the FC in question.

I don't use OSD on many aircraft and don't really have any "running out of ports" issues.

Would running a PPM/Sbus to PWM converter connected in parallel to "receiver out" help you at all by reducing the number of outputs you need?  Would running a parallel FC (even one of your spare Atoms) this way do what you need?
Title: Re: Bimode aircraft code changes
Post by: trust on February 28, 2021, 10:20:58 pm
The simplest solution would be to just get some 8 or 9 ch PPM Orangerx DSM2 compatible receivers - and I'm looking into that - vendor says he has some, is checking stock.
  Another vendor sent me 5 sbus receivers instead of the PPM ones - I either have to decide to keep them or return/exchange them.  DSM2 compatible receivers are getting hard to find, so I'm tempted to keep them.

I tested the GPS port - as expected it works fine.

But when I selected the receiver port as telemetry, I get no data comm to the OPOSD board. I checked with scope - no data coming out of the Tx port of the Revo. Checked all pins - nothing.
Title: Re: Bimode aircraft code changes
Post by: trust on February 28, 2021, 11:29:58 pm
Well, I found the Tx telemetry output pin - it was on pin 5, the white wire pin that is normally the PPM input (or is an output).
The OSD now works (I guess it doesnt need Rx to work).
So my guess is there are enough USARTs to work everything needed (although I dont have the OPLINK connected yet).

Now to figure out the output mapping.
Title: Re: Bimode aircraft code changes
Post by: trust on March 01, 2021, 02:54:52 am
Somewhat of a hack, but I got it working.
My notes:
add item Telemetry+Outputs hwsettings.xml RM_RcvrPort
add     [HWSETTINGS_RM_RCVRPORT_TELEMETRYOUTPUTS]        = PIOS_BOARD_IO_UART_TELEMETRY,
to pios_board_c flexiio_function_map

in  switch (hwsettings_rcvrport) {
    case HWSETTINGS_RM_RCVRPORT_TELEMETRYOUTPUTS:
        // enable pwm on the remaining 5 channels
            pios_servo_cfg = &pios_servo_cfg_out_in_ppm;

        break;

Compiled firmware & GCS.
The last case statement uses the config for ppm+outputs, which i figured since the PPM pin was now the telemetry pin would be safe to use.

It seems like the code is allocating 2 pins for the telemetry plus the ppm pin - I only get 3 PWM output pins active (I need only two)
It also seems like the original code does not route the telemetry Tx to the correct pin - as I mentioned, it's on the white pin 5.
Not sure why that is!
But at any rate it appears to work - at least in so far as doing what I need it to do!
Now I can use these Orangerx sbus receivers.
Title: Re: Bimode aircraft code changes
Post by: trust on March 08, 2021, 11:13:42 pm
So far we have now flight tested two of the four Hellaplanes we've implemented the Bimode code on.
In both cases most of the flight after vertical takeoff was executed in horizontal wing mode (uses the alternate mix table).
The most recent test was in a more challenging aircraft configuration with more of a canard style airframe - wider wingspan in rear wing than front, and further aft CG.
Despite a rather harrowing transition, flight was successful and fairly smooth. Review of the tailcam footage & telemetry data couldn't find an aircraft cause for the extreme left roll after transition. It was pretty thermally and somewhat gusty day, winds about 5+mph on the ground, probably 10+ aloft. The aircraft correctly then applied a hard right roll - which it did - a bit too strongly, as it banked almost vertically to the right, then rolled back level - all at about 10 feet off the deck (wingspan is 5'). I can't be certain exactly when the bimode switch was flipped, but it was ASAP after the wing transitioned. I'm considering adding some OPOSD display of the actual control inputs - it would be very helpful to know exactly what was applied vs what the plane did.
Here's a V1 video:
https://youtu.be/S7uycMUrsRc
And the above mentioned V3 front cam video:
https://youtu.be/zYqZtB_k8Os
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on March 09, 2021, 06:43:03 am
Looks more reasonably controlled than earlier; without forward flight oscillations.  :)

Is hover mode (say in Attitude) fully controllable?  Looks like you use it very little.  Maybe for some test hovering, lock the wings into hover configuration if afraid it will transition otherwise?

Are you actually transitioning to hover and switching to hover before landing?
Title: Re: Bimode aircraft code changes
Post by: trust on March 09, 2021, 06:53:54 pm
Yes, hover mode is fully controllable and very stable. With the fairly large wing area it tends to drift a lot - note the backwards drift after take off in the wind. The tail tries to keep it pointed into the wind.

None of these flights have had transition back to hover before landing. From many other flights, I've found if the wind is more than 5mph or so, it's easier and safer to horizontal wing hover to land - pitch up until hovering, then back off on throttle till tail touches and cut throttle.

To get the wing to transition back to vertical, the plane has to be flying backwards relative to the airflow. In little or no wind, pitch up in horizontal wing hover until forward motion stops, and plane starts drifting backwards - usually at that point the wing will rotate. Immediately back off pitch and plane will go into vertical wing mode hover - provided you're in vertical wing mode!

So if the wind is lite enough, on final approach as I increase AOA, I'll switch from hrz wing to vertical wing mode. The high pitch angle prevents the roll oscillations. The process of hovering is similar to horizontal wing hover, especially if roll is coupled to yaw (as I have it set in the transmitter). Then the transition process is as describe above.

What I have not yet tried is dealing with wing transition if the plane is still in horizontal wing mode. In theory, it should still hover. Pitch is normal. If it tries to roll to the left, gyros will apply elevon that will try to yaw to the left - then the the gyros will tell it yaw to the right to compensate, which turns up the left side motors and it will roll back to the right.

It's the same reason why it sort of works with just one set of controls - not ideally with the oscillations however.

I'm considering automatic switching of modes - a sensor to detect wing position and automatically switching modes.
It could be "analog" and have gradations based on angle.
But for now I want to test the various planes with manual switching and see how well it handles.
I've flown 2, am modifying a fifth one now, and plan to test the other 3 as conditions allow. I've modified one of Chris and he wants another one modified too - more FCs on order. He also has two more planes (larger, size in between the micros and Hell8ious) we may modify.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on March 10, 2021, 10:32:30 am
My vote, instead of a wing position sensor, have a wing position servo.  Without that, waypoint/FPV missions have the potential for getting into the wrong mode.  One Tx FMS position changes both the flight mode and the wing position.

They make slow and powerful servos for landing gear and sail winches, but something could also be home made like a something with a screw reduction and micro switches or screw reduction and servo pot/electronics.
Title: Re: Bimode aircraft code changes
Post by: trust on March 10, 2021, 07:31:40 pm
One of the principles of the Hellaplane design was NOT to have a motor/servo driven wing transformation device. So many of the eVTOL designs use some form of motorized device to rotate wings or motors - and they are a major source for failure and added weight, due to their high torque requirements. KISS has been the design philosophy.
  I do have a "wing lock" servo I added to V1 - when the wing is in hrz mode, activating that servo holds the wing in hrz mode. It has been a bit problematical - not always working. And not used anymore.
  I recently ordered a TX16 - hopefully I can get around too few channels and incompatabilities with receivers, so I can experiment with more channels if needed.
  Rainy wx here so no testing for a few days.
  One other minor note - when upgrading Micro V2 to bimode, I noticed one of the rear elevons was "twitchy" - something I noticed on M1 as well after a recent test flight. The elevon - usually soon after first power up, would jitter back and forth, sometimes moving fairly far. If you move the control surface, sometimes it would oscillate. Only happens on the rear elevons. Replacing the servo fixed it. Landing tail first with high AOA, sometimes the elevons hit the ground before the tip protectors (rods extending from the wing tips to hold the wing off the ground, away from the elevon) - and it can damage the servo. Not sure if its stripped gears or what. The tip protectors are made of bamboo on the micro (carbon fiber on Hell8ious) and also often crack or break - one test flight was marred by the broken stick being bent inward and preventing the elevon from moving properly. Pre-flight, pre-flight checks!
Title: Re: Bimode aircraft code changes
Post by: trust on March 16, 2021, 09:32:15 pm
Picked up this last week and programmed some settings. Some minor beefs on the wheel but overall very nice! Plus open source.

I'm doing some planning on incorporating a wing position sensor. I can use an IR LED and phototransistor pair with any one of several devices to control the light intensity based on the wing position. Example a piece of film with a gray scale pattern - black graded to clear, attached to wing. As wing moves it shifts the pattern, enabling light to dark full range of position sensing.

I can hook this up with a pair of resistors to an ADC input - I could use the sonar inputs on the Revo, or I could use the Orangerx receiver telemetry.
If I use the receiver telemetry, I could program the TX16 to interpret the values and set a threshold to automatically interpret wing position and send it as the switch value for bimode. Fairly straightforward.
But if I loose telemetry, it won't work properly. Not sure what range will be on Orangerx telemetry.

If I use the Revo ADC, can I translate the values to a 1/0 I can use to set the bimode? Can the ADCs be set as an Accessory input? If so I can use my existing code - it just thresholds on 0, and I have a flag I can use to invert states if needed.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on March 17, 2021, 06:02:06 am
I'm doing some planning on incorporating a wing position sensor. I can use an IR LED and phototransistor pair with any one of several devices to control the light intensity based on the wing position. Example a piece of film with a gray scale pattern - black graded to clear, attached to wing. As wing moves it shifts the pattern, enabling light to dark full range of position sensing.

etc
I'd use an old servo.  Remove electronics, gears, motor.  You have a pot and an arm left.

If I use the Revo ADC, can I translate the values to a 1/0 I can use to set the bimode?
That sounds reasonable.  I have to shift my brain into realizing you will probably be having this sensor effectively change your flight mode.  Sounds scary but should work.

Can the ADCs be set as an Accessory input? If so I can use my existing code - it just thresholds on 0, and I have a flag I can use to invert states if needed.
Not that I am aware of.

IIRC the AccessoryX's only allow normal receiver channels to be assigned.  (I think you can have more than one receiver/type connected.)  That said, if you can have your sensor output PWM, it would look like a receiver.  (But then the default is to set up enough Revo PWM inputs to fly something and that eats inputs that you probably don't have.)  A $3 clone Arduino Nano or Uno and the aforementioned servo pot would do it.  There is probably some very simple Arduino code to do the analog to PWM that you could find on the internet.

Revo ADC sounds easy / already mostly coded.  You will have to write some code to do something besides look at it in telemetry.

Be aware that internally Revo runs on 3.3V and although some pins are 5V tolerant, some aren't, and maybe even some clone 5V tolerant pins aren't and some clone OP boards don't have the port protection circuits the authentics have.  More than one user has fried a servo connector signal by carelessly plugging in an ESC that has live 5V.  If the 5V and signal connect before the ground does, you have effectively driven the signal pin way out of range.  Solution is to use a spare output (6x outputs, only 4 used for a quad).
Title: Re: Bimode aircraft code changes
Post by: trust on March 17, 2021, 09:02:28 am
I considered the servo idea - I even took one apart and prepped it to be used. But I don't have a place to input it.
I'm currently using 8 input channels as S.bus input on one pin of the main port. 8 outputs, split between 6 on the normal outputs and two on the 8 pin "receiver input", with 2 of those pins for the OPOSD telemetry. Flex port is GPS/mag. So I really don't have another input port I can use, unless it were inserted in the s.bus stream somehow as a 9th channel.
Title: Re: Bimode aircraft code changes
Post by: jdl on March 17, 2021, 12:18:47 pm
... with 2 of those pins for the OPOSD telemetry...

OPOSD uses just one (output) pin to passively receive data from FC, it does not send commands to FC.
Title: Re: Bimode aircraft code changes
Post by: trust on March 22, 2021, 10:24:32 am
Thanks for the clarification on the OPOSD JDL.

I've added some additional code to implement the hardware wing position sensor, and assembled and tested a photointerrupter connected to the battery voltage input on the sonar port. I used a GP1S196HCZ0F from digikey with a 470 ohm R between the IR leads and 5V supply, and a 10k between the emitter and ground. 5V also goes to the collector. Clear drives it to near 0V, interrupted to near 5V. The input only registers up to 2.5V but it seems to be a 5v tolerant input.
This device is really way too small, but I'll try to use it.

The code has 3 "switch" options - Sensor, Switch, or SwitchOverRide - in Sensor position, if the voltage passes a threshold (float value set to 1.5v) then it switches. In Switch mode it uses the selected Accessory channel switch. In SwitchOverRide, if EITHER sensor or switch is 1 then it is 1 (logical OR). Both switch and sensor have an invert option.
  I'll likely use the SwitchOverRide mode at first - that way if anything goes wrong with the sensor, I can override to hrz wing mode. I can turn this off when landing, to ensure that when the wing swings back to vertical it will immediately go to vert wing mode.

Tested the code and the sensor - so far looks good, everything works but need to add sensor to plane and update plane firmware (testing on a spare FC).

Yesterday did a flight test in strong wind conditions - did a hand launch for the first time in 20+mph winds - 30 aloft. Some of my hang gliding buddies can be seen in the video as well (tiny specs but hey). Basically a 4 minute vertical elevator ride up and down. Needed a LOT of down elevator to get down - lift was very strong in the main lift band. Also turbulent.
https://youtu.be/QCSXWBbdrdI
Title: Re: Bimode aircraft code changes
Post by: trust on March 27, 2021, 12:18:21 am
At the request of my buddy Chris, I've added another mixer type - ManualServo.
An output set to ManualServo ignores all the attitude and gyro settings and acts purely as a mixer for the roll/pitch/yaw receiver data. It can be used in bimode as well.
  Since these Revo FCs have as many as 12 output channels, its very useful to be able to use the FCs purely as mixers - and still use the gyro functions on output channels where needed.
  Seems to work in preliminary testing - one minor oddity - in the GCS Output page I can set the min/max/neutral settings fine, but it does not show the manuelservo assignment - it looks blank, but I can set items in it. Does not seem to affect being able to use it, but annoying I can't see it set.
Any idea where in the GCS code I would find this?
Title: Re: Bimode aircraft code changes
Post by: trust on March 27, 2021, 12:57:16 am
As a minor issue, where should I change the firmware code name? having it always list as xxx-dirty is somewhat confusing.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on March 29, 2021, 09:54:51 am
I've added another mixer type - ManualServo.
...
In the GCS Output page I can set the min/max/neutral settings fine, but it does not show the manuelservo assignment - it looks blank, but I can set items in it. Does not seem to affect being able to use it, but annoying I can't see it set.
Any idea where in the GCS code I would find this?
Any firmware change that you want to show up in the GCS GUI (that is besides automatically showing up in System) must be hand coded.  This generally requires hand editing QT files or using QTCreator to edit them.  Maybe you won't need to actually write C++ (GCS is C++) code if you only want to change UAVO field values.  I consider that this is something you do if you want to give a polished enhancement to the world.  Having done it before, I would just use System to edit the new UAVO stuff.

As a minor issue, where should I change the firmware code name? having it always list as xxx-dirty is somewhat confusing.
If you use git to commit your changes, the dirty goes away and you increment the RXXX number like currently next is 16.09+r796.  Or you can change the build system that does that.
Title: Re: Bimode aircraft code changes
Post by: trust on April 02, 2021, 06:33:08 am
Update on testing - the latest version with the wing sensor and manualservo functions were upgraded in 4 Hellaplanes - 2 of mine and 2 of Chris. The first test of the wing sensor the sensor worked fine and transition happened as planned - but the wing transitioned at very low altitude due to wind, and the V2 model it was in had an issue with pitch oscillation at low speed transitions - and subsequently crashed. Parts tested - mostly all still working (only one bad servo), but frame wrecked so will be built into a new model. Chris tested his Mini V1 next - it worked very well using the manual servo modes and he had several successful flights. Some tweeking needed but an improvement over the non-bimode version. We also stripped both his planes down from two FCs to one Revo, which saved some weight. He did some hover testing of his Mini V2, which is a somewhat different design but no horizontal flights yet.
Today I got in the first solid test of bimode with wing sensor on my V3 which went very well. Very smooth transition - I couldn't tell when it switched. I added elevator on the front elevons, which seems to have eliminated the pitch oscillations (in so far as tested) - so I went away very happy. Clip of the week from that flight:
https://youtu.be/ZF0MZgQ-gIA
It's remarkable to me how robust this FC hardware is. I've had planes sustain multiple 35-50mph crashes - and the electronics still works just fine. Most common failure is ESCs after a crash. Servos also. Perhaps a testimony also to our fail softly designs, which have multiple breakaway devices (mostly zipties and foam!) which absorb impact.
Title: Re: Bimode aircraft code changes
Post by: trust on April 11, 2021, 08:04:55 pm
I've noticed that after some period of time, I get EVENT flag blinking slowly orange. Its not clear what conditions start it. I sometimes arm then disarm while checking system functions - it often shows up after a few of these. I use an accessory input from one of the switches on the xmtr.
Doesn't seem to affect operation.
I did find that using the batteryvoltage input on the sensor input, as it runs in the range of 0.3 to 3.3V, I had to change the alarm and warning limits to 0, or under some conditions I couldn't arm the system. Possibly useful as a warning of failure of the wing sensor.
What conditions cause the EVENT flag to blink like this?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on April 12, 2021, 10:06:15 pm
I forget exactly what to look at here, but I would start with GCS -> System -> DataObjects -> SystemAlarms -> *

I would also set up the Scopes to monitor similar things.
Title: Re: Bimode aircraft code changes
Post by: trust on May 11, 2021, 01:23:06 am
Most of the bimode functions seem to be working fine, but one new issue has come up.
I modified GetCurrentFrameType to return the mode the wing is currently in - but it appears this does not change the behavior of VelcoticityRoam, RTB or any of the pathfollower functions once armed. It would seem I need to run some function whenever I change modes to initialize these functions for VTOL or fixedwing control parameters.
  Do I run pathFollowerHandler with newinit set to 1 or something else?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 11, 2021, 09:28:58 am
You are looking in the right place as long as you can limit it to when the wing position or FMS switch changes and don't call it with newinit=1 constantly.

Better yet, to be more certain that it is really treated as an FMS change (including which handler to call, etc.), I would modify flight/modules/ManualControl/manualcontrol.c to watch this sensor and do all the stuff it does when the FMS actually changes.

manualcontrol.c is where the FMS is read and acted on and where pathFollowerHandler() or other handler (like for non-GPS flight modes) is called from.
Title: Re: Bimode aircraft code changes
Post by: trust on May 13, 2021, 11:38:14 pm
I modified code to generate a mode change state flag so I can execute some code only once when mode changes.
I dug through the code - what concerns me is all the parameters that need to change when switching from Vtol to FixedWing when using pathFollower.
I found code that initializes this: pathFollowerSetActiveController
This code calls pathFollowerInitializeControllersForFrameType to init controllers for wing type.
 I would think I need to execute what this does every time I change wing mode.

I also see that calling SettingsUpdatedCb calls GetCurrentFrameType - and SettingsUpdatedCb calls and sets the active controllers if the frameType changes. So that looks like what I need to call when mode changes. Is the parameter a dummy parameter (says unused)?

I notice one other confusing factor in this function. It defines  a local frameType and sets it to the global frameType. Then it calls GetCurrentFrameType and sets the LOCAL frameType to that value. It uses that to check and see if frameType has changed, and then calls pathFollowerInitializeControllersForFrameType. But I don't see where the global value of frameType is updated. Where/when should I update the global frameType?
My version of GetCurrentFrameType gets the current frame type based on sensors and switches.
Does this make sense?
Title: Re: Bimode aircraft code changes
Post by: trust on May 13, 2021, 11:54:32 pm
Arg. I see there is a DIFFERENT version of SettingsUpdatedCb in many different modules.
??
Title: Re: Bimode aircraft code changes
Post by: trust on May 14, 2021, 12:22:12 am
Ok. I get that these are all private local functions and vars for each module.
But can I access just the one I need that's in pathfollower.cpp?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 14, 2021, 11:11:09 pm
I modified code to generate a mode change state flag so I can execute some code only once when mode changes.
I dug through the code - what concerns me is all the parameters that need to change when switching from Vtol to FixedWing when using pathFollower.
I found code that initializes this: pathFollowerSetActiveController
This code calls pathFollowerInitializeControllersForFrameType to init controllers for wing type.
 I would think I need to execute what this does every time I change wing mode.
As this has never been done before, it seems that you are finding more things that need to be tweaked.  I haven't been in this code as much as you have now.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 15, 2021, 12:09:09 am
Ok. I get that these are all private local functions and vars for each module.
But can I access just the one I need that's in pathfollower.cpp?

The obvious quick change that comes to mind is to make that variable a global.  That works best if you have one setter and possibly multiple getters.

Be aware that this is run under a multi-tasking supervisor.  Setting a global (or even a local through a global setter function) should be done from only one thread if at all possible.  If more than just that thread reads it, the read should be done atomically and if necessary, steps taken to mitigate it being changed just before or just after the read.

For multiple setters, the more typical change would be to put the change in a setter function where anything that must go along with the change can be put and locking against reentrancy can be done to limit access to one thread at a time.

Imagine thread #1 of 2 setters is setting it one way, and a timer interrupt causes a context switch to the other thread, some time in here, switch bounce causes it to change wing tilt sensor state.  How should the interrupting thread handle this?  How should the interrupted thread handle this?

To cause additional nausea, look over these things that I did to avoid threading issues, and grok the reasons they may be necessary:  :)
Code: [Select]
cliff@i925 ~/dev/librepilot/1609 $ grep -nr __sync_ flight
flight/modules/GPS/GPS.c:548:    if (__sync_fetch_and_add(&mutex, 1) == 0) {
flight/modules/GPS/ubx_autoconfig.c:241:    if (__sync_fetch_and_add(&mutex, 1) == 0) {

Code: [Select]
cliff@i925 ~/dev/librepilot/1609 $ grep -n current_step flight/modules/GPS/ubx_autoconfig.c
169:static volatile bool current_step_touched = false;
221:static void set_current_step_if_untouched(initSteps_t new_steps)
226:    if (!current_step_touched) {
229:    if (current_step_touched) {
527:    current_step_touched = false;
618:        set_current_step_if_untouched(INIT_STEP_SEND_MON_VER);
626:        set_current_step_if_untouched(INIT_STEP_WAIT_MON_VER_ACK);
638:        set_current_step_if_untouched(INIT_STEP_RESET_GPS);
675:        set_current_step_if_untouched(INIT_STEP_REVO_9600_BAUD);
706:    // set_current_step_if_untouched(INIT_STEP_GPS_BAUD);
728:        set_current_step_if_untouched(INIT_STEP_REVO_BAUD);
746:            set_current_step_if_untouched(INIT_STEP_SAVE);
748:            set_current_step_if_untouched(INIT_STEP_ENABLE_SENTENCES);
768:                set_current_step_if_untouched(INIT_STEP_SAVE);
772:                set_current_step_if_untouched(INIT_STEP_CONFIGURE);
775:            set_current_step_if_untouched(step_configure ? INIT_STEP_CONFIGURE_WAIT_ACK : INIT_STEP_ENABLE_SENTENCES_WAIT_ACK);
798:                set_current_step_if_untouched(INIT_STEP_PRE_ERROR);
805:            set_current_step_if_untouched(INIT_STEP_CONFIGURE);
807:            set_current_step_if_untouched(INIT_STEP_ENABLE_SENTENCES);
821:            set_current_step_if_untouched(INIT_STEP_SAVE_WAIT_ACK);
824:            set_current_step_if_untouched(INIT_STEP_PRE_DONE);
838:        set_current_step_if_untouched(INIT_STEP_PRE_DONE);
852:        set_current_step_if_untouched(INIT_STEP_DONE);
859:        set_current_step_if_untouched(INIT_STEP_ERROR);
902:    current_step_touched    = true;
Title: Re: Bimode aircraft code changes
Post by: trust on May 15, 2021, 09:44:59 pm
I created a public function PathFollowerSettingsUpdatedCb inside pathfollower.cpp which calls SettingsUpdatedCb, converted to a C code link so I could access it from ActuatorTask, where I check for changes, and call it ONLY when the mode switches.
   Did a flight test yesterday and today. It starts out fine, in VTOL mode, and when I switched to VR mode it held position pretty well - kept heading and tilted to stay in position despite some wind. I went back to stab2 mode, transitioned to hrz flight, then switched it to VR mode again. The plane kept flying, but did not seem to be flying back to the position when VR was set. I could not affect it's movement with any controls, other than to switchback to stab2 mode and fly it normally. Tried this twice - same results.
   I later also tried RTB - in this case it went into a sudden spiralling turn, so I switched back to stab2 mode.
Here is the video of the first part of the flight with the OSD view.
https://youtu.be/jxyEXvmzscA

SettingsUpdatedCb inside pathfollower.cpp seems to be the right place - it checks for mode changes and updates the frameType accordingly. Not sure why this didn't work.
Title: Re: Bimode aircraft code changes
Post by: trust on May 15, 2021, 10:47:16 pm
I'm wondering if the problem is that although it initializes controllers, it doesn't actually assign them as the activecontroller.

I see there is another function pathFollowerSetActiveController that sets these - but if I try to call it and activeContoller (the pointer) is already set, it will skip all the setting. It seems this was only meant to initialize once.
Does this make sense or is there more that needs to be done?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 15, 2021, 11:06:04 pm
I assume that the code was not written with changing airframe type in mind, so you will need to enhance it for that, whatever is required.

The good things are that you didn't crash, :) and that you have a reproducible problem.  Debug it on the bench.  You can try a cheap hardware debugger connected to the SWD port, or use the printf method.  :)

Print a small amount of debugging to come out an FC serial port, and watch this on your computer through an FTDI and a terminal program.

Another way I use (probably the easiest) is to use an unused UAVO (just pick one) as a scratch pad and poke some numbers there (1=it got to here, 2=it got to there) into several different UAVO variables (even the actual value of variables of interest) to correspond to different places you are debugging.  Don't forget to init that UAVO on startup if it is not already inited elsewhere.  You will also need to change that UAVO metadata via GCS System page so that e.g. every time the FC changes it, it gets sent to the GCS.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 15, 2021, 11:30:16 pm
What does stock VR mode do when configured in a fixed wing configuration?

I don't recall whether or not VR is appropriate for that.  I think there are other modes more suited to fixed wing?  Autocruise comes to mind.  I confess that I only know to use Attitude and RTB in my fixed wing GPS aircraft.  Is simple Attitude not good enough?  I know it doesn't fight a crosswind, but fighting the wind can cause confusion if you thing it should be pointing in one direction but it is pointing in another.  Look here for some autocruise info.
https://forum.librepilot.org/index.php?topic=4644.msg31459;topicseen#msg31459

I had hoped that running all the code that runs when you do a normal FMS change would do all you need.  I know that there are different controller sections for the different aircraft configurations.  You will just need to make sure that that gets updated.  Hopefully there aren't any "inits that shouldn't be done while armed/flying", or that they can be made airworthy.
Title: Re: Bimode aircraft code changes
Post by: trust on May 16, 2021, 02:46:59 am
Thanks for the debugging suggestions - I'd been using some of the vars as you say to check internal states.
VR on fixed wing has the plane do circles or figure 8s back to the start point.
If I startup with my bimodefundata.TypeSwitchEnable flag set to 0, it doesn't use my version of GetCurrentFrameType and uses the default set airframeType. I currently have it set to FixedWing. Then when I switch to VR mode it does the above movements - which is what I want.
In the just performed test, I set the flag to 1. So when system initialized, it saw it was in VTOL mode so initialized to VTL mode. That part worked fine.
But after it transitioned to hrz mode, switching to VR mode - it didn't fly the pattern described above. Just kept going, as if it didn't know where to go, or wasn't in VR mode.
Title: Re: Bimode aircraft code changes
Post by: trust on May 16, 2021, 07:55:05 pm
Looking over the code & trying to understand the flow, I'm thinking of using the following code to deactivate the current activeController, then check the wing status and set activeController based on the current state & flight mode when the wing mode changes - thoughts?

// deactivate activeController & set update activeController
static void pathFollowerReactiveController(__attribute__((unused)) UAVObjEvent *ev)
{
 
    if (activeController) {
        activeController->Deactivate();
        activeController = 0;
    }

    pathFollowerSetActiveController();

    if (activeController) {
        activeController->ObjectiveUpdated();
    }
}
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 17, 2021, 09:57:47 am
In the just performed test, I set the flag to 1. So when system initialized, it saw it was in VTOL mode so initialized to VTL mode. That part worked fine.
But after it transitioned to hrz mode, switching to VR mode - it didn't fly the pattern described above. Just kept going, as if it didn't know where to go, or wasn't in VR mode.

I guess the thing to test next would be if it works correctly in FW mode if started in FW mode.  If that is the case, then it is "just" a matter of completely changing the mode after startup.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 17, 2021, 09:59:45 am
Looking over the code & trying to understand the flow, I'm thinking of using the following code to deactivate the current activeController, then check the wing status and set activeController based on the current state & flight mode when the wing mode changes - thoughts?

// deactivate activeController & set update activeController
static void pathFollowerReactiveController(__attribute__((unused)) UAVObjEvent *ev)
{
 
    if (activeController) {
        activeController->Deactivate();
        activeController = 0;
    }

    pathFollowerSetActiveController();

    if (activeController) {
        activeController->ObjectiveUpdated();
    }
}

Sounds reasonable, but I haven't been deep in this area for years, and have not researched the active controller stuff.
Title: Re: Bimode aircraft code changes
Post by: trust 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.
https://youtu.be/Tvfn_XfqOp4
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on May 18, 2021, 10:44:37 am
Did you change the code as you had discussed?  Setting "Active Controller"?
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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
Title: Re: Bimode aircraft code changes
Post by: trust 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.
 
Title: Re: Bimode aircraft code changes
Post by: trust 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?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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?
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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.
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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. . .
Title: Re: Bimode aircraft code changes
Post by: trust 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.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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?
Title: Re: Bimode aircraft code changes
Post by: trust 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.
https://youtu.be/GB3RmmgyZHc
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff 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.
Title: Re: Bimode aircraft code changes
Post by: trust on November 25, 2021, 08:52:52 am
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.
https://youtu.be/n2NoQPMs8Pk
https://youtu.be/Ah_OQTWAa5A
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on November 25, 2021, 11:53:38 am
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!
Title: Re: Bimode aircraft code changes
Post by: trust on November 26, 2021, 02:23:25 am
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.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on November 26, 2021, 02:59:15 am
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.
Title: Re: Bimode aircraft code changes
Post by: trust on November 26, 2021, 05:38:36 am
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.
Title: Re: Bimode aircraft code changes
Post by: jdl on November 29, 2021, 10:22:27 am
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.
Title: Re: Bimode aircraft code changes
Post by: trust on December 01, 2021, 06:37:36 pm
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.
Title: Re: Bimode aircraft code changes
Post by: jdl on December 02, 2021, 08:10:30 am
I've uploaded the new source code (v2.59) here:

https://github.com/jdlilov/MinOPOSD-JDL/tree/main/Sources/ArduCAM_OSD (https://github.com/jdlilov/MinOPOSD-JDL/tree/main/Sources/ArduCAM_OSD)

Hope it works, I don't have time to test it right now. Any observations and comments on the new feature are welcome! :)

P.S. You might want to change the Flight Telemetry Update Period to something less than (default) 1000ms if faster updates of the OSD displayed thrust in autonomous modes are desired.

LibrePilot GCS: System Tab (UAVObjectBrowser) | Data Objects | ActuatorDesired | Metadata | Modes | Flight Telemetry Update Period
Title: Re: Bimode aircraft code changes
Post by: trust on December 11, 2021, 07:37:11 am
jdl - thanks - I'll try it soon.
Meanwhile I ran more tests - after the first day of mostly reasonable tests, my attempts to improve it by narrowing the thrust window had the opposite effect. There was a tendency to speed up and turn in the right direction, but then the plane would pitch up, stall, and go into a spin.
After two days of trying adjusting the thrust and speed limits, I tried shifting the landing pitch from 0.5 to -5 degrees. This made a world of difference. Ran about 10 tests today and they all flew back to target. There is still a tendency to first speed up in the first turn, then throttle way back. At least now it doesn't stall. The pulsing tends to even out if the path back is far enough. You'll notice the pulsing in the 2nd RTB test - throttle peaks about every 10 seconds.
Any ideas on how to smooth it?
https://youtu.be/QlpB_9sJQRg
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on December 11, 2021, 10:36:07 pm
First you need to make sure that your Airspeed UAVO is set up and working right.

Then the "correct" way would be do tweak the Altitude PID.  If a PID is oscillating, a quick fix is to reduce the numbers (say multiply P, I, (and D) all by 0.66).  The long way is to tune the PID however you know to do that.

The Altitude PID version is either in the pathfollower version you are using (I guess this auto-switches and re-inits correctly?) or is in an external Altitude* UAVO.  Generally, the *PF settings are used when the PF is being used, but IIRC there is one case where the *PF setting is completely ignored and not ever used?

IIRC you can disable the use of airspeed and it will try to fly with a fixed angle of attack, must be slightly up where adding power makes it climb.  Airplane probably needs to be a bit nose heavy...

Be aware that in the FWPF, the vertical/thrust algorithm is "if too low, increase thrust" and "if too slow, push elevator down".  It is done this way for safety on engine failure instead of needing special code to keep it from pulling up and stalling on engine failure.  I think the main FWPF altitude setting is VerticalPosP, but then there are several other settings such as PowerPI. SpeedPI, and *CrossFeed that I have not played with and probably all interact.  Finally, there are Safety* and if these are disobeyed, your waypoint flight will go to "error destination" rather than next waypoint.  Try to understand these and set the limits to good values.  The way to avoid this for waypoints is to to set error destination to -1.

It would be great if someone would write up a complete FWPF tuning guide, but I suspect that there are a lot of things there that you should just leave alone, like the EKF settings.

Be aware that there seem to be some issues with flying wings and FWPF.

Karla, JDL, and I discussed FWPF altitude tuning (some guessing and testing) and flying wings here IIRC:
https://forum.librepilot.org/index.php?topic=4769.0
https://forum.librepilot.org/index.php?topic=3518.0
Title: Re: Bimode aircraft code changes
Post by: trust on December 13, 2021, 02:07:20 am
Thanks for the notes.
I don't have an airspeed sensor. UseAirspeedSensor is set to false, so it flies with parameter hasAirpeed false all the time.
There seems to be a way to use the GPS to simulate airspeed, do I just set UseAirspeedSensor to true?
How does it know if there is actually a sensor? If one was setup in the config?
BTW - if hasAirpeed is false, it always flies with fixed pitch - the one defined as landingpitch.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on December 13, 2021, 08:43:47 pm
There seems to be a way to use the GPS to simulate airspeed, do I just set UseAirspeedSensor to true?
How does it know if there is actually a sensor? If one was setup in the config?
As I recall, you set AirspeedSettings.AirspeedSensorType to GroundSpeedBasedWindEstimation

I have flown many autonomous flights using GSBWE and not really had problems with it, but IIRC @JDL has.  I have some hacks, like setting thrustlimits to a narrow range that could potentially be making my setup work better than stock?

I have 2 autonomous airplanes, one with GSBWE and the other with a pitot tube sensor.

I would compare airspeed sensor value to GPSPositionSensor.GroundSpeed over some long flights (live or recorded telemetry).  Of course if you do this on a calm day they should be very similar and if they differ, GSBWE is suspected.  Long periods of flight into the wind or downwind can be easily subtracted from your wind speed estimate.  Flying perpendicular to the wind (but a little downwind, just enough to drift down wind with the wind) can negate the wind speed.

BTW - if hasAirpeed is false, it always flies with fixed pitch - the one defined as landingpitch.
I would not have guessed "the one defined as landingpitch"
I would guess that is for landing mode and that it uses PitchLimit.Neutral for normal FWPF flight
Title: Re: Bimode aircraft code changes
Post by: trust on December 17, 2021, 12:51:57 am
Thanks. Ill try GSBWE.
Looking online there seems to be a dearth of available pressure sensors to use for airspeed that are supported. Must be the chip shortage. The chips are all back ordered well into 2022.
Do you are does anyone have any extra sensors they're not using they'd be willing to sell?

A tricky question is whether the pitot tube should be mounted on the rotating wing, or to the main body. I would think the latter, but there may be cases where that isn't correct, such as steep climbs in vertical wing mode. IF the motors are at high power, the lift tends to be so great that the body stays mostly level but the wings tilt more in the vertical direction.
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on December 17, 2021, 09:00:55 am
Here are some sensors/pitots from posts I remember.
https://forum.librepilot.org/index.php?topic=4819.msg32303;topicseen#msg32303
http://e-hely.com/index.php?route=product/product&path=73&product_id=7141
https://www.xt-xinte.com/h-product-detail.html?goods_id=138778
https://www.ebay.com/itm/333924554403
https://www.ebay.com/sch/i.html?_nkw=(mpxv7002%2C+mpxv5004%2C+4525DO)
https://www.google.com/search?q=Ardupilot+Arduplane+Airspeed+Meter+Sensor

https://forum.librepilot.org/index.php?topic=4819.msg32389;topicseen#msg32389
https://www.aliexpress.com/item/32560997823.html?spm=a2g0o.cart.0.0.21f93c00C3V7HQ&mp=1

A tricky question is whether the pitot tube should be mounted on the rotating wing, or to the main body. I would think the latter, but there may be cases where that isn't correct, such as steep climbs in vertical wing mode. IF the motors are at high power, the lift tends to be so great that the body stays mostly level but the wings tilt more in the vertical direction.
In the code, the airspeed is used for fixed wing, to maintain airspeed in a range and avoid stall or flutter.  I don't see a need for pitot to rotate with the wing.  If hovering upward is positive speed, what would hovering downward be?
Title: Re: Bimode aircraft code changes
Post by: trust on December 20, 2021, 06:25:02 am
Thanks for all the links. Many are back ordered, but Aliexpress has one I think I'll order.
Today before the rains hit again I tested the GPS ground based wind estimator.
It seems to act slightly different, though there is still the throttle up after initiating. The updating process seems to happen faster, and there is more pitch oscillating at times, but it always got back to base. On the second test with it pointed directly away, it had a bit of problem deciding which way to turn - changing direction several times - but it did finally pick one and go with it. Winds lite 5 SE but seemed stronger up higher.

The sound is slightly delayed in the audio.
https://youtu.be/5LVd4z6T0WI
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on December 20, 2021, 10:31:08 am
I recall a fixed wing in an autonomous mode that ran the motor up to full and down to off with a period of many (10?) seconds.  For a quick fix that I never changed, I adjusted the thrustlimits.  I recall @JDL had a similar issue that he fixed in a more correct fashion by adjusting some period1 / period2 stuff.  Pretty sure that thread is linked in my previous post.

Ah, search found it:
https://forum.librepilot.org/index.php?topic=3518.msg24240;topicseen#msg24240

(RTB)
Quote
it had a bit of problem deciding which way to turn - changing direction several times
As you know, it simply picks the shortest one of the two turns to home.  Changing (or seeming to change) the turn to go the other way says something funny is going on.  Adverse yaw when you roll or other control problems, bad compass readings (doubtful), strong wind blowing you sideways as you fly straight away from Base and thus changing an 89 to a 91, etc.
Title: Re: Bimode aircraft code changes
Post by: trust on December 20, 2021, 05:28:37 pm
The two IMUbasedxxx periods 1 and 2 are at 0.5 and 10 respectively. I can try upping them to 0.75 and 20 and see what happens.
I had tried in earlier tests to tighten the thrust limits to 0.4,0.5,0.6 - but it did not seem to have any helpful affect - it still ramped up and down a lot (much more than that range), but that was before I changed the pitch neutral to -5, which made the biggest difference. I also tried changing the Horzvelmax/min to a narrower range and Vertvelmax to 3 - those too did not seem to help any, though in checking the code they still SHOULD have had an affect even with hasAirspeed false.
At one point it did ramp up to 20m/s but that was a downwind leg.
I may try changing them back again to the tighter limits anyway.

It's too bad the algorithm can't be tailored to using yaw to change direction - with wing mounted motors it does very tight yaw turns at low speed, with very little or no loss in altitude. A little bank reduces the slip losses, but it doesn't need much. It will stall if you go TOO tight, but it's still impressive how tight you can get it.

I think I may try some waypoints now too - with some altitude changes to see how it works there.
Fun!
Title: Re: Bimode aircraft code changes
Post by: TheOtherCliff on December 21, 2021, 08:55:19 am
I had tried in earlier tests to tighten the thrust limits to 0.4,0.5,0.6 - but it did not seem to have any helpful affect - it still ramped up and down a lot (much more than that range),
That makes me wonder if it is using the VTOLPF (or even AltitudeHold.ThrustLimits?) there...  or if more stuff needs to be done during the switch from VTOL to FW.

Telemetry ActuatorDesired.Thrust should stay within 0.4 to 0.6 or it could be tracked down as to why it isn't...

It's too bad the algorithm can't be tailored to using yaw to change direction - with wing mounted motors it does very tight yaw turns at low speed, with very little or no loss in altitude.
I am currently running a version where I hacked that code to immediately apply some up elevator to allow configured bank tighter / turn tighter.  It will give some up immediately rather than wait for the nose to drop before applying up.  I imagine you could add maybe some yaw ratedesired in there?