When stall prevention is enabled we were scaling from the aircraft's
minimum flight speed. However this is normally already picked as being
above the stall speed, and for a variety of reasons we may want to pin
the aircraft at a higher minimum speed. But if the aircraft was
commanded to fly to close to that minimum speed as soon as it banked for
a pattern it would command a increase in speed to keep it away from
stalling. However if your minimum speed is far from stalling this
increase was incorrect. To make it worse what this actually results in
happening is an aircraft diving for more speed (over 10 m/s on some
aircraft) as well as descending to gain that speed resulting in over 200
foot deviations in altitude control.
Only create the binding object (singleton metatable/userdata or C
function reference) once the user first references a particular
singleton or userdata creation function. Once created, the object is
stored into the script's environment so it doesn't get recreated on the
next reference and there isn't any further overhead. The userdatas are
no longer shared between scripts which imposes a slight memory penalty
for multiple scripts using the same singleton but this avoids an
additional lookup time cost.
Userdata and ap_objects aren't eligible for this optimization as the C++
code might want a particular metatable at any time.
Saves ~9.3K Lua heap.
The global table is then used as the __index metamethod of each state's
environment table. Avoids the overhead of loading binding objects into
each state. The binding objects are immutable from Lua so sandboxing is
not violated.
Does have the slight downside that a script can no longer know all the
binding names by enumerating _ENV.
Saves ~700B of memory per loaded script.
The __call metamethod was set to the metatable itself. With __call not
present, Lua will try to call the metatable (and fail), which is the
same behavior as with the __call metamethod set to the metatable.
Saves ~2K Lua heap.
gimbal was sending mavlink into ArduPilot with the target system's own sysid/compid tuple. ArduPilot was simply discarding these as its own messages being looped back to it
Aside from the RRG,1 call, the simulation should reply with exactly what was received as a receipt confirmation to allow the driver to proceed past init
"VNERR" does not match beginning of message_to_send, so have to prevent it from returning due to the string compare. Also must prevent exiting the decode before the sentence has completed so that we can go on to print the error code term.
Fix bug preventing disabling of ASCII measurements
Instead of snprintf the command to message_to_send then executing run_command, allow run_command to accept a string and format spec
Add check to ensure message_to_send is greater than length 6 before attempting to read past 6