Reverse thrust for controlled landings, even with much steeper approach slopes. This is achieved by allowing throttle demand to go negative to maintain a target airspeed. A Pre-Flare stage was added, triggered by an altitude, to allow for a slower airspeed just before land. That lower airspeed can be near stall.
new params TECS_APPR_SMAX - sink rate max during approach
This is the only driver doing this, using the system_initializing() from
scheduler to log selectively. Remove the check together with removal of
unused wrapper methods to semaphore.
With this change, there's no need to verify if the submodule is initialized,
because the submodules in GIT_SUBMODULES are automatically initialized and
updated if necessary before the build tasks are performed.
One downside of this change is that Google Benchmark configuration is now done
only during build. However that is minor, since now there are easy ways to
separately build different targets and program groups, so that a fail in
benchmark build doesn't really affect the other targets.
We define three build groups and set post_mode as POST_LAZY, which makes one
group be posted only after the previous one. That enables us to correctly
define dynamic sources with submodules and generators that may or may not
depend on submodules (e.g. mavgen - this one depends on mavlink submodule).
The groups are defined below, in that order:
1. git_submodules: contains taskgens that initialize and update submodules.
2. dynamic_sources: contains taskgens that generate sources used by the build.
3. build: contains the normal taskgens.
That is a workaround so that one can use `waf bin tests`, for example. In our
context, the only restriction to the task generators creation is values defined
during configuration. Thus, ideally, the recursion and task generators creation
should be done only once for multiple build calls. We should do that in the
future.
That makes the code cleaner and better readable. Futhermore, it's easier to add
a pattern for recursion.
Additionally, this commit remove Tools from the exclusion list as that is not
necessary.
Due to the way the headers are organized changing a single change in
an AP_Notify driver would trigger a rebuild for most of the files in
the project. Time could be saved by using ccache (since most of the
things didn't change) but we can do better, i.e. re-organize the headers
so we don't have to re-build everything.
Due to the way the headers are organized changing a single change in an
inertial sensor driver would trigger a rebuild for most of the files in
the project. Time could be saved by using ccache (since most of the
things didn't change) but we can do better, i.e. re-organize the headers
so we don't have to re-build everything.
With this patch only AP_InertialSensor/AP_InertialSensor.h is exposed to
most users. There are some corner cases to integrate with some example
code, but most of the places now depend only on this header and this
header doesn't depend on the specific backends.
Now changing a single header, e.g. AP_InertialSensor_L3G4200D.h triggers
a rebuild only of these files:
$ waf copter
'copter' finished successfully (0.000s)
Waf: Entering directory `/home/lucas/p/dronecode/ardupilot/build/minlure'
[ 80/370] Compiling libraries/AP_InertialSensor/AP_InertialSensor.cpp
[ 84/370] Compiling libraries/AP_InertialSensor/AP_InertialSensor_L3G4200D.cpp
[310/370] Linking build/minlure/ArduCopter/libArduCopter_libs.a
[370/370] Linking build/minlure/bin/arducopter
Waf: Leaving directory `/home/lucas/p/dronecode/ardupilot/build/minlure'
This is not used by any board and has a lot of commented out code. For
example, the compass is not enabled. The comment in the beginning of
the driver says it should serve as an example, but we should rather use
a working driver as an example. If this was at least a bit simpler and
that worked in the past we could refactor it to the new I2CDevice API.
This is not the case.
Tom Pittenger
Lucas De Marchi
Randy Mackay
mirkix
Matt Kocaj
Andrew Tridgell
Gustavo Jose de Sousa
Jonathan Challinger
Daniel Frenzel