dc4d1bacdd
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. |
||
---|---|---|
.. | ||
applets | ||
docs | ||
drivers | ||
examples | ||
generator | ||
lua | ||
modules | ||
tests | ||
.gitignore | ||
AP_Scripting_CANSensor.cpp | ||
AP_Scripting_CANSensor.h | ||
AP_Scripting_config.h | ||
AP_Scripting_helpers.cpp | ||
AP_Scripting_helpers.h | ||
AP_Scripting_SerialAccess.cpp | ||
AP_Scripting_SerialAccess.h | ||
AP_Scripting_SerialDevice.cpp | ||
AP_Scripting_SerialDevice.h | ||
AP_Scripting.cpp | ||
AP_Scripting.h | ||
lua_bindings.cpp | ||
lua_bindings.h | ||
lua_boxed_numerics.cpp | ||
lua_boxed_numerics.h | ||
lua_common_defs.h | ||
lua_scripts.cpp | ||
lua_scripts.h | ||
README.md | ||
wscript |
AP_Scripting
Enabling Scripting Support in Builds
Scripting is automatically enabled on all boards with at least 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.