- during large transients in pitch demand the pitch integrator value
was shifted such that the final demanded pitch did not violate given
limits. Since this strategy can cause large knock-backs of the pitch
integrator we remove this logic completely. We already have logic in place
which reduces the integrator at the pitch time constant in case the
pitch limits are exceeded so we don't need to limit it further. This
has the advantage that spikes in the specific energy balance error
signal does not lead to integrator knock-back.
Signed-off-by: Roman <bapstroman@gmail.com>
Constrain the specific energy balance integrator input to prevent increasing saturation of pitch demand.
Decay the specific energy balance integrator state if the pitch demand is saturated to reduce saturation to zero and do so at the same tome constant as the control loop
Relax the clipping threshold on the specific energy balance integrator to allow the input constraint and decay functions to do more of the work
Improve variable naming and commenting
- when limiting the pitch integrator input the value was related to
a quantity with different units (specific energy error rate vs delta pitch)
- once the unconstrained pitch demand is larger / smaller than the max/min
allowed pitch angle the integrator input should only be allowed to drag
the integrator into the direction leading to less pitch demand violation
Signed-off-by: Roman <bapstroman@gmail.com>
- if the specific energy balance correction term produced a demanded
pitch value which exceeded the aircraft pitch limits then the pitch
integrator was shifted such that the pitch demand violation was prevented.
However, this meant that the exceeding pitch was just unloaded into the
integrator and caused unexpected behavior of the pitch loop.
In an underspeed condition e.g. this has lead to the plane pulling up it's
nose very quickly shorty after the underspeed condition kicked in.
Signed-off-by: Roman <bapstroman@gmail.com>
- the method in TECS for detecting an underspeed condition was run after
the method which calculated the airspeed demand. As a result the specific
engergy balance error signal showed a spike when TECS detected an underspeed
condition.
Signed-off-by: Roman <bapstroman@gmail.com>
In this particular case it does no harm,
but since in other cases it can lead to
problems I didn't want to add an exception
for this case to fix_headers.sh, that currently
chokes on this because it doesn't know better
than that it's a bad thing.
Note on how #pragma once works: when encountered
(aka the #ifdef that it is inside has to
be true), the compiler marks the whole
file as "seen" (this is implementation
defined, but most implementations store
the inode of the file). Subsequent #include's
of that file/inode are then completely skipped.
Hence it doesn't matter if the #pragma is at
the beginning, at the end or in the middle,
but it should be encountered every #include,
usually, and thus not be inside an #if... #endif
construct.
These headers files were missing from the header files that
I added them to; the fact that they were missing didn't
lead to compile errors because by coincidence the missing
headers are included in the source files before including
these headers. But, after the reordering of header inclusions
by Tools/fix_headers.sh, these cases will give rise to compiler
errors.
We don't have C++ unsafe headers (anymore).
I added a test to fix_headers.sh that checks if certain "unsafe"
headers are ONLY included inside a __BEGIN_DECLS ... __END_DECLS
(because after all, they are unsafe), as well as checking that
no other header files are included inside such a block. The rationale
of the latter is that if a file is a C header and it declares
function prototypes (otherwise it doesn't matter) and is sometimes
included outside a __BEGIN_DECLS ... __END_DECLS block (from a C++
source file) then it has to be C++ safe and doesn't ever to be
included from inside such a block; while if a file is a C++ header
then obviously it should never be included from such a block.
fix_headers.sh subsequently found several safe headers to be
included from inside such a block, and those that were (apparently
in the past) unsafe were included only sometimes inside such a
block and often outside it. I had a look at those files and saw
that at least an attempt has been made to make them C++ safe,
but especially because they already are included OFTEN outside
a __BEGIN_DECLS ... __END_DECLS (from C++ source files) the
best decision seems to treat them as safe.
This is not risky: .c files that define such functions still
generate C-linkage for their functions. If a C++ unsafe C header
is included outside a __BEGIN_DECLS ... __END_DECLS block then
the only possible result would be an undefined reference to
a function with C++-linkage that will not exist. Aka, when
something links after this commit, then the commit was correct.
I did build all targets and they all linked.
This patch reorders px4_defines.h to make it more readable (I think)
but more importantly, cleans up the #include <math.h>/<cmath>
and [std::]isfinite stuff.
My main goal was to completely get rid of including math.h/cmath,
because that doesn't really belong in a header that is supposed to
define macro's and is included in almost every source file (if not
all).
I'm not sure what it did before ;) (pun intended), but now it does
the following:
PX4_ISFINITE is only used in C++ code (that was already the case,
but hereby is official; for C code just use 'isfinite()') and is
defined to be std::isfinite, except on __PX4_QURT because that uses
the HEXAGON toolset which (erroneously) defines isfinite as macro.
I would have liked to remove PX4_ISFINITE completely from the code
and just use std::isfinite whereever that is needed, but that would
have required changing the libecl submodule, and at the moment I'm
getting tired of changing submodules... so maybe something for the
future.
Also, all includes of <math.h> or <cmath> have been removed except
for __PX4_NUTTX. Like the HEXAGON toolset NuttX currently defines
isfinite as macro for C++. So, we could have solved this in the
same was as __P4_QURT; but since we can fix NuttX ourselves I chose
to add a kludge to px4_defines.h instead that fixes this problem,
until the time that NuttX can be fixed (again postponing changing
a submodule). The kludge still demands including <cmath>, thus.
After removal of the math header file, it needed to be included
in source files that actually need it, of course.
Finally, I had a look at the math macro's (like M_PI, M_PI_F,
M_DEG_TO_RAD etc). These are sometimes (erroneously) defined in
certain math.h header files (like both, hexagon and nuttx).
This is incorrect: neither the C nor the C++ standard defines
math constants (neither as macro nor otherwise). The "problem"
here was that px4_defines.h defined some of the M_*_F float
constants in terms of the M_* double constant, which are
sometimes not defined either thus. So, I cleaned this up by
defining the M_*_F math constants as float literals in px4_defines.h,
except when they are defined in math.h for that platform.
This means that math.h has to be always included when using those
constants, but well; not much difference there as those files
usually also need/use the macro NAN (which *is* a standard macro
defined by math.h).
Finally finally, DEFAULT_PARAM_FILE was removed as it isn't
used anymore.
All in all I think the resulting px4_defines.h is nice, giving me
much less the feeling of a nearly unmaintainable and over time
slowly growing collection of kludges and hacks.
In most cases, _extern_address was unused, thus wasting cycles & RAM. This
adds a separate class BlockParamExt with the field and uses it in ekf2_main
Frees roughly 0.5KB of RAM on Pixracer
The packet_count was actually an error_count, therefore we should
process RC input only when the error_count since the last packet is 0.
Also, this commit fixes the RSSI scaling for st24.
It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.
Working crazyflie firmware build
* Console on USART3
* Could not disable building PX4IO firmware, currently commented out
Don't build PX4IO firmware if the board doesn't ask for it
Added crazyflie motor driver
Fixed wrong register
CLK_SEL is in PWR_MGMT_1
Initial I2C/SPI MPU9250 device
* Tested with I2C
* Need to add error checking
* Intermittent crash on stop call
Working ak8963 mag driver
Functional lps25h driver. Work in progress.
Works well enough to probe and allow sensors task to start.
Added serial port test module
HACK! Get sensors module working
Set crazyflie PWM range
Extend baudrate for Crazyflie's NRF radio
Added dummy tone alarm to allow for init
Added autostart script for Crazyflie
