Lua calls our registered panic function if a Lua error is raised outside of any protected mode set up by `lua_pcall` and friends. As scripts themselves are run in protected mode, such an error will only originate from our engine code. The current code handles panics, but does so incorrectly by neglecting to free the error message buffer during a panic exit. As the underlying heap is eventually destroyed and recreated, that static buffer pointer is to a heap that no longer exists. If the new state raises an error it will try to free that pointer, causing heap corruption and sadness. Fix this issue and avoid similar ones by refactoring to run the main part of the scripting engine in Lua protected mode. This creates exactly one exit path from the scripting engine and avoids the need for fragile panic handling infrastructure that duplicates what is built into Lua. Quoth the Lua manual, "The panic function, as its name implies, is a mechanism of last resort. Programs should avoid it." This is unlikely to be triggerable in flight as the main engine loop does not appear to use the Lua API in a way which can trigger errors. But the possibility can't be fully excluded. It is, however, possible to trigger beforehand using a perfectly wrong heap size that causes a memory error during initialization. Note that due to the error message buffer being freed properly now, an error message originating from the engine will not cause a pre-arm failure. This could be improved in the future.
AP_Scripting
Enabling Scripting Support in Builds
Scripting is automatically enabled on all boards with more than 1MB of flash space. The following example enables scripting, builds the ArduPlane firmware for the Cube, and uploads it.
$ waf configure --board=CubeBlack
$ waf plane
$ waf plane --upload
To run SITL you can simply use the sim_vehicle.py script which will wrap the configuration, compilation,
and launching of the simulation into one command for you.
$ Tools/autotest/sim_vehicle.py -v ArduPlane
Once you have a vehicle flashed with scripting you need to set the SCR_ENABLE parameter to 1 to enable scripting and reboot.
Adding Scripts
The vehicle will automatically look for and launch any scripts that are contained in the scripts folder when it starts.
On real hardware this should be inside of the APM folder of the SD card. In SITL this should be in the working directory (typically the main ardupilot directory).
An example script is given below:
function update () -- periodic function that will be called
local current_pos = ahrs:get_location() -- fetch the current position of the vehicle
local home = ahrs:get_home() -- fetch the home position of the vehicle
if current_pos and home then -- check that both a vehicle location, and home location are available
local distance = current_pos:get_distance(home) -- calculate the distance from home in meters
if distance > 1000 then -- if more then 1000 meters away
distance = 1000; -- clamp the distance to 1000 meters
end
SRV_Channels:set_output_pwm(96, 1000 + distance) -- set the servo assigned function 96 (scripting3) to a proportional value
end
return update, 1000 -- request "update" to be rerun again 1000 milliseconds (1 second) from now
end
return update, 1000 -- request "update" to be the first time 1000 milliseconds (1 second) after script is loaded
Examples
See the code examples folder
Working with bindings
Edit bindings.desc and rebuild. The waf build will automatically re-run the code generator.
Lua Source Code
The Lua 5.3.6 source code is vendored in lua/. This is a customized
version of the official
distribution. Where possible,
differences have been marked of the code.
Lua (not including modifications) is distributed under the terms of the MIT license.