[trust]

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?

[TheOtherCliff]

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.

[trust]

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 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.

[trust]

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).

[trust]

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?

[trust]

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?

[trust]

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.

[trust]

Ah, well never mind.
I ran the separate firmware and gcs clean functions - those seem to do the trick.

[trust]

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.

[trust]

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.
?

[TheOtherCliff]

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.

[TheOtherCliff]

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?

[TheOtherCliff]

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.

[TheOtherCliff]

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.

[trust]

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.