We consume these at line rate from the transciever, don't allow this to
cause unnecessary congestion on the bus, as it may be used for flight
critical functions. A more proper solution would be to behave more like
the actual AP_ADSB library, and simple rate limit how often we send any
updates out to the host device, as well as filtering for distance, but
that requires more information then is currently readily available.
This is very useful with an aircraft that is expected to be autonomously
operating in auto from takeoff to landing. It is convient to have a GCS
connected or RC, but the loss of either isn't considered a reason to
terminate the mission.
This is a change in bevaiour. The previous behaviour was to check for a
NACK, and if it wasn't a NACK it was assumed to be an ACK. This is a bad
assumption to let people get away with, because in the future if we ever
add other options to the enum we are more likely to have to cope with
bad implementation in the wild
Removes unneeded set's of memory that is already zero'd. It also changes
_flags to be all bool to match the actual usage, and removes the width
specifiers from them. This increases the RAM cost of AP_Mission by 4
bytes, but saves on flash. The RAM cost was eliminated by rearranging
members.
Also swaps to using an AP_Enum for the SBAS type, and fixes up the fact
that the prearm/failure reasons should be using the config step, rather
then the init blob index
This allows us to consider enabling UAVCAN_RGB_LED as a more general
default, as it won't consume one of our limited backend slots if UAVCAN
is not enabled.
This saves a shocking amount of bandwidth. On a CubeOrange-periph
build sending just baro data and 2 battery info's this results in 25%
less bandwidth being used. (Also given that we still have a instance id,
and can get the CAN node's descriptor in the general case this is not
costing us any information).
This fixes a configuration problem with SBF unit's where sometimes we
fail to detect the GPS unit continously, until it's been manually
configured. This was tested by doing a hard reset to the GPS unit.
This also now accepts a set of defines from the hwdef, or build
environment, which allows us to specify extra config options.
Also add a static assert and some docs on the fact that blending only
works with 2 actual recievers at the moment
Also a small optimization to not call get_rate_ms() twice
start of the update
This allows specifying a return value like "return update, 10" to run
at a near perfect 100Hz, where as before it would be run 10 ms after the
script had completed it's loop, which can be highly variable as the
script experiences interupts from the system, as well as needing the
script author to take responsibility for calculating the desired update
rate at the end. This was always intended to be fixed, but I pushed it
back during the initial development, however people are begining to run
scripts that have enough processing, or are rate sensitive enough that
we are now needing to start correcting this, or scripts will have to do
their best to guess the time, which will be inferior to us providing it.
As a note if you exceeded the time expected we will be rescheduling the
script immediately, thus it will have a schedule time in the past and
will be slotted in. This can't indefinetly starve other scripts as they
will still be slotted in, but if you request an update in 1 ms, but took
100ms to run we will simply slide you back into the queue 1ms after when
you started running.
This allows you to arm the copter without any extra GCS commands while
in auto, and can be done from both the GCS, or the RC Tx. This is useful
for creating a simpler workflow.
This also allows you to set the auto_armed flag internally, which
bypasses the need to raise the throttle stick for the copter to start a
takeoff.
This exposed a problem where we would start running the controllers
before the EKF was at all initialized, if you switched into auto to
early. This now has a check that prevents us from running the mission
state machine until after the origin has been set. This was a suggestion
from @rmackay9.
When combined these options allow you to have the vehicle on the ground,
disarmed in auto with a takeoff waypoint loaded, then just arm the
aircraft and watch it takeoff. This is a feature we've had on quadplanes
for quite awhile now, and it has proven to be very nice for operators.
Also fixes allowing an extra new line on the depends entries to be
emitted, as well as a possible stack overflow in the generator if
you inserted a malicious comment.
Michael du Breuil