strncpy() does not enforce NUL-termination, but snprintf() does. So we need to ensure all strings are terminated. Another issue was the use of the wrong length parameter for these functions, resulting in the limiting arguments not being applied to the right length.
Necessary so that build_git_version.h is generated before version.c is
compiled.
Error before:
../src/lib/version/version.c:152:31: error: 'PX4_GIT_TAG_STR' undeclared (first use in this function)
return version_tag_to_number(PX4_GIT_TAG_STR);
boards define BOARD_NAME, so board_name() is not necessary. HW_ARCH was
just a wrapper around board_name().
This patch simplifies to having only one common method px4_board_name().
The stack size was generally ok but seemed to get exhausted in the case
of a waypoint which is too far away and therefore exercises some more
code in the mission feasability checker.
Generally, we should have more margin in the navigator stack size
because there are a bunch of different code paths that can happen.
- 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.
BharathR