LibrePilot Forum
Development => Firmware General => Topic started by: octavvian 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.
-
"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.
-
Thank you for explaining it.
-
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!
-
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):
pid->I = 0.0f;
and replacing it with:
// 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...
-
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 :-).
-
When flight testing my quads that use 3S lipo I sometimes use a 2S lipo for the test. :)
-
Yes, 2s for safety. ;D
-
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.
-
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 (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
-
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
-
Update the msys2 package by running:
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.
-
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"
-
From MinGw32 console, try installing Python ?
pacman -S --needed mingw-w64-i686-python2
-
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!
-
The change to flight/libraries/math/pid.c that I described in reply #4 should fix that perfectly like it used to be and also have the fix intended in the change that broke it.
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197
If you like the way this worked in 16.09, that change will make it work that way, but be better in case you configure PID I term = zero for some reason.
Ah, maybe you just want a second opinion. I can understand that. :o
-
Which timing for the drop part (instant, slow?) and how many time it takes to remains to the previous altitude ?
Can you post your config file ?
-
at Laurent,
not really sure I am right here, but this link may show a video and also have a log file of the drop you ask for,
so you can see it
https://forum.librepilot.org/index.php?topic=3999.msg28215#msg28215
If this is out of line, just ignore it :)
-
The change to flight/libraries/math/pid.c that I described in reply #4 should fix that perfectly like it used to be and also have the fix intended in the change that broke it.
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197
If you like the way this worked in 16.09, that change will make it work that way, but be better in case you configure PID I term = zero for some reason.
Ah, maybe you just want a second opinion. I can understand that. :o
Yes and no, just wanna know why this was included in 16.09 and now is changed? Nobody notice this behaviour? I'm struggling for now to compile the build again and include the modified pid.c according to you (TheOtherCliff). Thanks, hope I'm not offended you.
-
Which timing for the drop part (instant, slow?) and how many time it takes to remains to the previous altitude ?
Can you post your config file ?
~config attached
PS. the drop only occur in transition from stabilized to althold flight mode (each time when repeated)
-
Yes and no, just wanna know why this was included in 16.09 and now is changed?
I think this used to work well in 16.09. The change was made (from comments) because if you set PID I term to zero, the I term can't unwind when / if it is wound up.
No offence taken. :)
-
The "drop" is shown very nice in the vid from a topic - https://forum.librepilot.org/index.php?topic=3999.msg28230#msg28230.
==https://youtu.be/U87Xt3ug_0o== see 16 sec time frame.
-
Has anyone verified whether the change in post #4 fixes this issue?
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197
-
Hi, I succesfuly complied the fw. with the pid.c modified acording to your suggestions. But unfortunately didn't tested yet. I'll hope this week-end... :)
-
Hi, I succesfuly complied the fw. with the pid.c modified acording to your suggestions. But unfortunately didn't tested yet. I'll hope this week-end... :)
Tried, same 0.5-0.8m drop, I switch to altvario (hold) at 45% throttle, about 1,5-2m.
Maybe could anyone try too as second opinion :(.
-
AH is the best test because AV must be at 50% throttle to maintain altitude. If your quad hovers at below 40 or above 60 throttle, then you will have some vertical motion when switching into or out of AV.
I guess I need to retest this. Right now I am running 16.09 on all my stuff.
-
I just tested it with next r550-g213893e and the code fix in reply #4 fixes the issue perfectly for me.
Make sure you replace the one line with the set of several lines. If you put the new code above the single old code line it will still break.
Then save the file. Then build the FC firmware you need. Then flash the new FC firmware. Settings are the same. No need to erase settings or change anything when you swap these firmwares. First time each flight, make sure you hover (no climb or descend) for a few seconds before switching into AH.
Is it very windy where you are testing? I wonder if that could have an effect.
I verified that it works correctly in 16.09
I verified that I can see the issue in r550 next.
I verified that after the fix, the issue is gone in r550 next, and it works as well as 16.09.
Tested switching from:
Attitude, Attitude, Axislock, ManualThrust
to
Attitude, Attitude, Axislock, AltitudeHold
in all cases.
Details:
I have adjusted my AH PID to some higher numbers, so it reacts more quickly. I enjoy flying that way because you can slam the stick around and it automatically applies full acceleration power or full braking power. When the issue happens it only drops 10 to 15cm, but you can see it unless it is climbing slightly when you switch into AH.
-
Thanks for effort, Ill try to figure out.
Regarding the place or the wind, the test was done indoor. One more remark with 16.09 the copter never fall, the behavior appear when switched to next.
As a kind request, could you provide the modified pid.c file?
All the best!
-
I read your message before you modified it, so I didn't see the request. :)
The next I used was from December 2017.
I don't know what version of next you are running.
pid.c does not get changed much though. The December version should work fine. You could also use the 16.09 version of pid.c
After replacing the file you could do:
git diff flight/libraries/math/pid.c
and it should only show the changes we are talking about. That is a way to make sure there are no other changes in this file.
I would first replace the file then clean the current firmware like this (assumes you have Revolution FC):
make revolution_clean
then build it like this:
make revolution
then flash it and test it, no need to erase settings.
Here is the pid.c I used (attached).
-
Thanks a lot. I'll post the result after test.
-
During testing, make sure that you hover at throttle position that does not climb or descend, with manual throttle, for several seconds, before switching into AH for the first time on any flight.
-
Tested, confirm the lost of alt fix, but know when switch from stab to ah it jumps 20 cm and tend climb , can't test the right way, here it's storming (wind) so even indoors pressure isn't stable. I'll repeat on better weather. Thanks.
-
Tested, confirm the loss of alt fix, but know when switch from stab to ah it jumps 20 cm
Does it jump up or down? Always up or always down or sometimes up sometimes down?
tend climb
If the climb is very slow, then thermal calibration (Attitude page) may be needed. The board warms up for the first 5+ minutes after plugging battery in and as board warms up, the quad climbs. Thermal calibration fixes this.
A video showing your problems would probably help, and be entertaining too. :)
-
Yes, will be, at least entertaining ...
I'll try a video next time.
-
I'd like to report that tests with a myself compiled "dirty" Revo firmware (based on Next.589) incorporating the change in post #4 were successful for me.
This change from TheOtherCliff in post #4: ...flight/libraries/math/pid.c fixes for me the ugly transition from Rate to RTB I've observed when the copter is in more challenging attitude / orientation with throttle away from ThrustLimits/Neutral setting.
Transition from Attitude to AltitudeVario is also butter-smooth now, as it was in 16.09.
I guess this fix should be made "official".
-
I guess this fix should be made "official".
Here is : https://bitbucket.org/librepilot/librepilot/pull-requests/509
-
I confirm the transition is now extremely smooth and barely unnoticeable.
Well done!