trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #15 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.
?

Re: Bimode aircraft code changes
« Reply #16 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

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #17 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?

Re: Bimode aircraft code changes
« Reply #18 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.

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #19 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.

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #20 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.

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #21 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...

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #22 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.

Re: Bimode aircraft code changes
« Reply #23 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.   ;)

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #24 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.
?

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #25 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.

Re: Bimode aircraft code changes
« Reply #26 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.

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #27 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.

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #28 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.

trust

  • ****
  • 301
Re: Bimode aircraft code changes
« Reply #29 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.