Latest next fw. problems
« on: February 22, 2018, 07:04:31 pm »
Hi with the latest next fw., revo mini board. In GCS configuration "tx pid" and "camera stab." can't be disabled.
If unchecked, after reset they appear checked.

f5soh

  • *****
  • 4572
    • LibrePilot
Re: Latest next fw. problems
« Reply #1 on: February 22, 2018, 08:43:40 pm »
"TxPID" and "Camera Stab" cannot be disabled because they are "built in" with Revo, like with previous version but now the checkboxes reflect the "built in" status.
This logic will change in future allowing the module to automatically start according to his configuration instead of "enable", reboot and finally configure.

Re: Latest next fw. problems
« Reply #2 on: February 22, 2018, 11:30:01 pm »
Thank you for explaining it.
« Last Edit: February 22, 2018, 11:34:20 pm by octavvian »

Re: Latest next fw. problems
« Reply #3 on: March 01, 2018, 12:34:57 pm »
Same conditions, flies great in stab. mode, stab.-> alt hold, drops 0.5-0.8m from 1.8m stab. level and than regain alt. to 1.7-1.8m and hold alt. OK
Do you encounter same behavior?
Thanks!

Re: Latest next fw. problems
« Reply #4 on: March 01, 2018, 05:38:47 pm »
From my previous research on this issue there is a bug; and from what you say it has not been fixed:

A safety concern about throttle changes lead to a change in:
flight/libraries/math/pid.c
and my quick research indicates that caused the issue.


It would be a great help if you are building next that you make this change and see if it fixes it for you.  In the file:
flight/libraries/math/pid.c

You are looking for the line (probably exactly line 222, there is only one line like this in the file):
Code: [Select]
        pid->I = 0.0f;
and replacing it with:
Code: [Select]
        // pid->I = 0.0f;
        // whether ki is zero or non-zero, when doing 'reconfigure' we start with setpoint==actual
        pid->I    = (pid->u0 - pid->va) / pid->vb;
        // if ki is non-zero
        if (pid->bi > 5e-7f) {
            // then the output can wind up/down to get rid of a difference between setpoint and actual
            // so we can generate the full bumpless transfer here
            // else leave off the part that can vary due to difference between setpoint and actual
            // so that it is repeatable (for tuning purposes at least)
            pid->I -= pid->kp * (pid->beta * r - y);
        }
[/color]


Programmer notes:

Here is what I believe is the offending line in my oldish version of next:
(from git blame fb5f9034 (Eric Price 2017-03-09 18:48:36 +0100 222)         pid->I = 0.0f;)
        // pid->I = (pid->u0 - pid->va) / pid->vb - pid->kp * (pid->beta * r - y);
        // this is dangerous, if pid->I starts nonzero with very low or zero kI, then
        // it will never settle!
        pid->I = 0.0f;


In my personal version I previously noted and fixed it like this which does not have this issue:
        // pid->I    = (pid->u0 - pid->va) / pid->vb - pid->kp * (pid->beta * r - y);
        // cliff changed this to avoid initing a windup that will never unwind if ki is zero
        // damn
        // (FYI: after pid2_configure(), the next call to pid2_apply() causes 'reconfigure'
        // where the following happens while making the transition "bumpless"...)
        // the difference between neutral and I term unwind center generates a positive offset for output (not useful)
        // the difference between setpoint and actual generates a negative offset to exactly counteract the new P value
        // recall that P is generated from this difference times the constant Kp
        // these tweaks get put in the I term
        // the problem is that if ki is zero, the I term will never wind up or down,
        // so you are stuck with the offset you had when you entered that mode
        // and that offset could be high or low, positive or negative,
        // depending on what you did with the stick just before entering the new mode
        // example: thrust: falling toward ground you give full throttle but it is currently still falling
        // solution is to ignore the part of this I term offset that comes from the difference between setpoint and actual
        // whether ki is zero or non-zero, when doing 'reconfigure' we start with setpoint==actual
        pid->I    = (pid->u0 - pid->va) / pid->vb;
        // if ki is non-zero
        if (pid->bi > 5e-7f) {
            // then the output can wind up/down to get rid of a difference between setpoint and actual
            // so we can generate the full bumpless transfer here
            // else leave off the part that can vary due to difference between setpoint and actual
            // so that it is repeatable (for tuning purposes at least)
            pid->I -= pid->kp * (pid->beta * r - y);
        }


I really need to write up some of these issues I have documented...

Re: Latest next fw. problems
« Reply #5 on: March 01, 2018, 06:17:46 pm »
Thanks, I also do remember this behavior when I switched from 16.09 to next, but I thought that was fixed ...
I give a try including in "flight/libraries/math/pid.c" the last part and make a build for test. The only fear is that for now I do my test indoor and I don't like to scrape the bird from ceiling :-).
« Last Edit: March 01, 2018, 06:31:14 pm by octavvian »

Re: Latest next fw. problems
« Reply #6 on: March 01, 2018, 07:30:07 pm »
When flight testing my quads that use 3S lipo I sometimes use a 2S lipo for the test.  :)

Re: Latest next fw. problems
« Reply #7 on: March 01, 2018, 07:50:37 pm »
Yes, 2s for safety. ;D

Re: Latest next fw. problems
« Reply #8 on: March 01, 2018, 08:30:51 pm »
And the .... error 2:
"D:/msys64/home/Octav/librepilot/ground/gcs/src/libs/osgearth/utils/utility.cpp: In function 'bool osgQtQuick::clampGeoPoint(osgEarth::GeoPoint&, float, osgEarth::MapNode*)':
D:/msys64/home/Octav/librepilot/ground/gcs/src/libs/osgearth/utils/utility.cpp:482:49: error: no matching function for call to 'osgEarth::ElevationQuery::getElevation(osgEarth::GeoPoint&, double&, double)'
     if (eq.getElevation(geoPoint, elevation, 0.0)) {
                                                 ^
In file included from D:/msys64/home/Octav/librepilot/ground/gcs/src/libs/osgearth/utils/utility.cpp:75:0:
D:/msys64/mingw64/include/osgEarth/ElevationQuery:93:15: note: candidate: float osgEarth::ElevationQuery::getElevation(const osgEarth::GeoPoint&, double, double*)
         float getElevation(
               ^~~~~~~~~~~~
D:/msys64/mingw64/include/osgEarth/ElevationQuery:93:15: note:   no known conversion for argument 3 from 'double' to 'double*'
mingw32-make[4]: *** [Makefile:1249: utility.o] Error 1
mingw32-make[4]: Leaving directory 'D:/msys64/home/Octav/librepilot/build/librepilot-gcs_release/src/libs/osgearth'
mingw32-make[3]: *** [Makefile:437: sub-osgearth-make_first-ordered] Error 2
mingw32-make[3]: Leaving directory 'D:/msys64/home/Octav/librepilot/build/librepilot-gcs_release/src/libs'
mingw32-make[2]: *** [Makefile:44: sub-libs-make_first-ordered] Error 2
mingw32-make[2]: Leaving directory 'D:/msys64/home/Octav/librepilot/build/librepilot-gcs_release/src'
mingw32-make[1]: *** [Makefile:43: sub-src-make_first-ordered] Error 2
mingw32-make[1]: Leaving directory 'D:/msys64/home/Octav/librepilot/build/librepilot-gcs_release'
mingw32-make: *** [Makefile:308: gcs] Error 2"
I'm stuck.

Re: Latest next fw. problems
« Reply #9 on: March 01, 2018, 11:30:13 pm »
That is an unrelated error in OsgEarth.

All I can say about that is that I recall hearing about some build issues with OSGE.  You might find some help by searching the forum for osgearth.

Msys2 is a moving target, always pushing newer versions of libraries.
So things are sometimes broken (like osgearth currently).

As for the 'dirty' in the package name it indicates that your git clone contains uncommitted changes.

Here is a post that got it to build by disabling the building of OsgEarth.  Read whole post for more:
As in https://forum.librepilot.org/index.php?topic=4044.0 changed ~librepilot/Makefile to:

else ifeq ($(UNAME), Windows)                                             
    UAVOBJGENERATOR := $(BUILD_DIR)/uavobjgenerator/uavobjgenerator.exe   
    GCS_WITH_OSG      := 1                                               
    GCS_WITH_OSGEARTH := 0       <<<< changed from 1 to 0                                         
    GCS_COPY_OSG      := 1                                               
    GCS_WITH_GSTREAMER := 1                                               
    GCS_COPY_GSTREAMER := 1                                               
endif   

finally it compiled ok (but with a dirty word.)

LibrePilot-16.09+r589-g4c9c3c2-dirty_x86_64.exe

Re: Latest next fw. problems
« Reply #10 on: March 02, 2018, 08:51:27 am »
Thanks, I'll try.

later edit: regarding the fix in althold mode, this fix will be reflected in future next fw.?

later edit 2: reinstalling MSYS2 MinGW after LP wiki "solve it for good ..."
$ make package
/usr/bin/sh: /mingw32/bin/python: No such file or directory
- LibrePilot UAVObject Generator -
Done: processed 121 XML files and generated 121 objects with no ID collisions. Total size of the data fields is 5107 bytes.
generating flight code
 FWINFO    [fw|cc  ]  D:/msys32/home/Octav/librepilot/build/firmware/fw_copterco                                               ntrol/fw_coptercontrol.bin.firmware_info.c
process_begin: CreateProcess(NULL, D:/msys32/mingw32/bin/python D:/msys32/home/Octav/librepilot/make/scripts/version-info.py --path=D:/msys32/home/Octav/librepilot --template=D:/msys32/home/Octav/librepilot/flight/templates/firmware_info.c. emplate --outfile=D:/msys32/home/Octav/librepilot/build/firmware/fw_coptercontrol/fw_coptercontrol.bin.firmware_info.c --image=D:/msys32/home/Octav/librepilot/build/firmware/fw_coptercontrol/fw_coptercontrol.bin --type=0x04 --revision=0x02--uavodir=D:/msys32/home/Octav/librepilot/flight/../shared/uavobjectdefinition,...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make[1]: *** [D:/msys32/home/Octav/librepilot/flight/make/common-defs.mk:290: D:/msys32/home/Octav/librepilot/build/firmware/fw_coptercontrol/fw_coptercontrol.bin.firmware_info.c] Error 2
mingw32-make: *** [D:/msys32/home/Octav/librepilot/flight/Makefile:227: fw_coptercontrol_opfw] Error 2
« Last Edit: March 02, 2018, 07:37:18 pm by octavvian »

filnet

  • *****
  • 113
Re: Latest next fw. problems
« Reply #11 on: March 02, 2018, 08:28:36 pm »
Update the msys2 package by running:

Code: [Select]
pacman -Syu
You might have to do it twice. Follow the instructions. If it asks you to close your shell, then close it, open a new one and run the same command again.

It will upgrade osgEarth and other packages.

Re: Latest next fw. problems
« Reply #12 on: March 02, 2018, 10:12:17 pm »
Exactly that I was.... and game over! ;D

"$ pacman -Syu
:: Synchronising package databases...
 mingw32 is up to date
 mingw64 is up to date
 msys is up to date
 librepilot-mingw is up to date
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
 there is nothing to do"

f5soh

  • *****
  • 4572
    • LibrePilot
Re: Latest next fw. problems
« Reply #13 on: March 03, 2018, 09:13:40 am »
From MinGw32 console, try installing Python ?
Code: [Select]
pacman -S --needed mingw-w64-i686-python2

Re: Latest next fw. problems
« Reply #14 on: March 03, 2018, 09:55:02 am »
Spot on, like always :).
Regarding "flies great in stab. mode, stab.-> alt hold, drops 0.5-0.8m from 1.8m stab. level and than regain alt. to 1.7-1.8m and hold alt. OK" do you have any thoughts? Thanks!