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!
