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 fixes a bug that happens with VISION_SPEED_ESTIMATE from a
companion computer, which may come in before the EKF buffers are
allocated. That causes a push to an uninitialised ringbuffer which
triggers memory corruption
found using the new memory guard system
this fixes a bug that happens with VISION_SPEED_ESTIMATE from a
companion computer, which may come in before the EKF buffers are
allocated. That causes a push to an uninitialised ringbuffer which
triggers memory corruption
found using the new memory guard system
Other drivers consider that they received data even if the value is
reported as "out of range" by sensor. On the I2C driver for TFMiniPlus
we considered this case, too. However when the signal strength is very
low (and thus the distance would likely be out of range), we would end up
ignoring the new sample. With enough samples without any value this
would lead the status to turn to "NoData".