it is possible to build for boards without storage (so no Posix, no Fatafs), but still have scripts in ROMFS.
In this case we will use the backend AP_Filesystem_backend base class when doing file operations. This will alway fail to open directories, so when we try to load scripts from SCRIPTS_DIRECTORY it will always fail.
This leads to a warning being emitted:
Lua: State memory usage: 2796 + 5227
AP: Lua: open directory (./scripts) failed
AP: hello, world
Time has wrapped
Which isn't great.
Detect we are working on this filesystem and don't warn.
Implements a reasonably comfortable REPL accessible over serial entirely
as a loadable script.
Also accessible over MAVLink using QGroundControl's MAVLink Console and
the new mavport module.
Abstracts the MAVLink SERIAL_CONTROL message to be usable as a Lua port,
in particular the DEV_SHELL device supported by QGroundControl's MAVLink
Console.
Serial bindings were dependant on HAL_GCS_ENABLED but this is not ideal, it should be dependant on AP_SERIALMANAGER_ENABLED so that serial can function without GCS
In Lua, strings are the only type that come with a default metatable.
The metatable must be shared by all string objects, and it is set to be
the `string` library table each time that library is opened. In
Ardupilot's scripting engine, the last script to load then has access to
the string metatable as the library is opened fresh for each script, as
its `string` library will have been set to the metatable.
Therefore, if two scripts are loaded, A first and B second, and script B
executes e.g. `string.byte = "haha"`, then `string.byte()` and
`s:byte()` for script B are broken. Because the metatable is shared,
this also breaks `s:byte()` for script A, which violates the integrity
of the sandbox.
Fix the issue by disabling the metatable setup functionality when the
string libary is opened, then manually opening an additional copy of the
library (which won't be given to any script) and setting it as the
string metatable during intialization.
This will break any script that modifies the string metatable for
constructive purposes, but such a script could have been broken if it
weren't the only script running anyway.
Referencing the original function to run is of questionable value and
the only user uses it to grab the script environent from the upvalues.
Instead, use a reference to the script environment table directly.
Some bits of the code in the require machinery use the `lua_ref` to
access the script environment. However, this can change after the script
is rescheduled and it returns an arbitrary function to run next.
Resolve this by introducing `run_ref` which is specifically a reference
to the function to run next. `lua_ref` is preserved for the script
lifetime.
Move the string checks into the load functions to avoid duplicating it
for each binding.
Also sync up the return types to avoid an unnecessary conversion.
Saves ~1.5K.
The Lua stack is guaranteed to have at least LUA_MINSTACK (default 20)
slots upon entry to C. Check to see if we might need more than that
minimum and only in that case call the function to check and resize the
stack. In virtually all cases the check can then be optimized away.
Additionally remove the redundant "Out of stack" message. Lua already
says "stack overflow" and a null message is valid.
Saves ~330B.
This example intercepts PREFLIGHT_REBOOT_SHUTDOWN COMMAND_LONG's and if
param1==2, it shuts down the BQ40Z smart battery BMS. Otherwise it
passes through the COMMAND_LONG as a COMMAND_INT (this required updating
the gcs:run_command_int to return a MAV_RESULT rather than a bool).
This adds bindings for an I2CDevice's transfer() function, an example,
and removes the nil return hint from the get_device() docs as it never
actually returns nil.
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.
this has been tested on a marine engine, and correctly produces key
telemetry data
the NMEA_2000.lua module is broken out to make it easier to add other
NMEA 2000 based drivers
The script uses the scripting matrix to produce non-equal
front and back thrust, compensating for the lever arm between the center
of thrust and the center of mass.
On macOS, sometimes ._script.lua is created to store metadata when the
user copies script.lua over to their SD card. Previously, the scripting
engine would barf since the file is not Lua. Now, these files are
ignored.
Also avoids a case where a hidden and valid script might be loaded
without the user's knowledge.
Allows a script to simulate a device attached via any serial protocol.
The script can read and write data and have it handled according to the
protocol as if exchanged over a serial port. The script can then do
protocol translation, data filtering and validation,
hardware-in-the-loop simulation, experimentation, etc., especially in
combination with the scripting protocol which lets the script itself
handle an attached device and so interpose any communication.
Using `luaL_Buffer` avoids the need for any heap allocation in the
common case (count <= 512 bytes) and avoids stressing out the system
heap for large reads, instead using the script heap.
Zero net flash usage change.
Adding another layer instead of just exposing UARTDriver bindings allows
substitution of the different functions for device simulation later.
Also take the opportunity to rework the docs a little.
Passing -1 to the argument count for the `creation` tag (name does not
matter) will stop the generator from giving Lua a function to construct
that userdata. The C `new_<name>` function still works.
This script uses the scaled output from the antennatracker servos and map them to corresponding Pelco-D messages to be sent via a RS-485 interface to a motorized base (can be anything from motorized tracker to a PTZ camera).
If your FCU doesnt offer a RS-485 interface by default, you can use or TTL-RS485- or USB-RS485-adapters.
Pelco-D allows to control using either speed-/differential- or absolute-control control of the pan-/tilt-axis.
Currently the script uses speed based control using by mapping the "ContinuousRotation" type servos outputs to the corresponding Pelco-D messages.
The absolute control messages are implemented nevertheless for future use.
The script assumes therefor at least the following parameters to be set:
SCR_ENABLE = 1
SERVO_PITCH_TYPE = 2 # ContinuousRotation type servo
SERVO_YAW_TYPE = 2 # ContinuousRotation type servo
SERIALx_PROTOCOL = 28 # serial port used by luascript
Additionally the PITCH2SRV and YAW2SRV tuning needs to be done as described by the antennatracker description.
Also keep attention to the PITCH_MIN, PITCH_MAX and YAW_RANGE parameters to fit your Pelco-D hardware!
Andrew Tridgell
Iampete1
timtuxworth
Peter Barker
Thomas Watson
Clyde McQueen
bugobliterator
Henry Wurzburg
yuri-rage
Tatsuya Yamaguchi
Randy Mackay
Willian Galvani
Loki077
George Zogopoulos
Hayden Donald
Ian Burwell
Pierre Kancir
TsuyoshiKawamura
petrosilius