Instead of requiring every program to specify the HAL related modules,
let the build system do it (in practice everything we compiled depended
on HAL anyway). This allow including only the necessary files in the
compilation.
The switching between different AP_HAL was happening by giving different
definitions of AP_HAL_BOARD_DRIVER, and the programs would use it to
instantiate.
A program or library code would have to explicitly include (and depend)
on the concrete implementation of the HAL, even when using it only via
interface.
The proposed change move this dependency to be link time. There is a
AP_HAL::get_HAL() function that is used by the client code. Each
implementation of HAL provides its own definition of this function,
returning the appropriate concrete instance.
Since this replaces the job of AP_HAL_BOARD_DRIVER, the definition was
removed.
The static variables for PX4 and VRBRAIN were named differently to avoid
shadowing the extern symbol 'hal'.
* Retains ability to read from Analog Pin
* Adds ability to read RSSI from PWM channel value as is done in OpenLRSng, EazyUHF, and various other LRS.
* Handles any type of RSSI that provides RSSI values inverted - i.e. when the low value is the best signal and the high value is the worst signal.
* Has different key names from all existing RSSI parameters to provide for a clean break and easier distinguishing.
* Existing parameters are marked as obsolete
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.
Fixed this bug
https://github.com/diydrones/ardupilot/issues/840
If a Rover was in AUTO and the user moved the throttle stick into
reverse past 50% the rover would increase. Basically the throttle
nudge behaviour was the same regardless of whether you moved the
throttle forward or backward.
When the rover goes into guided mode it sets the current location as
the guided point to goto. If the rover is stationary when this
happens no problem. If however the rover is still rolling (say going
from AUTO to GUIDED) then the rover would go past its guided position
and get confused and begin to circle it. This change resolves that issue.
Rover now honours the Param1 setting of a time in seconds for a
NAV_WAYPOINT and the Rover will loiter at that waypoint for that
period of time.
Note that as soon as the Rover reaches that waypoint the loiter timer
will start. If you enter a different mode during this time (HOLD for
instance) the timer resets. If you then switch back to AUTO
mode and the Rover returns to that waypoint it will wait for the
loiter time configured in param1.
Merged a bug fix where mode would not revert on geo-fence disable.
The mode would not revert if the switch was in position 0.
Geofencing will soon be in Rover and I didn't want to forget this bug
and chase it later so committing it now. It works fine in Rover now
even though the geofencing code isn't in yet.
As the previous commit as doubled the number of reads required to
confirm that the mode change switch has been changed this means it
will halve the speed it changes at. So we double the rate at which we
read it to keep things consistent.
Caio Marcelo de Oliveira Filho
Gustavo Jose de Sousa
Grant Morphett
Randy Mackay
Andrew Tridgell
Stewart Loving-Gibbard
squilter
Peter Barker
Staroselskii Georgii
Siddharth Bharat Purohit
Peter Barker
Tom Pittenger
Lucas De Marchi