AP_Scripting: add bindings to load fence #15598
Conversation
|
Would be nice to add a fence notify function to trigger the GCS to reload. |
|
It might also be possible to take the table as a argument directly rather than using unpack, but I could not work that out. |
| class AC_PolyFenceItem new_items[args]; | ||
|
|
||
| for (uint8_t i=0; i<args; i++) { | ||
| AC_PolyFenceItem *item = check_AC_PolyFenceItem(L,i-args); |
There was a problem hiding this comment.
I have no idea why we have to use negative stack index here where as in the logger binding there positive. But this does seem to work as expected. We start at larger negative number and work up to -1 in order to get the fence to come out in the expected order.
|
This was writing the fence backwards, now its not. |
|
This now allows to broadcast the fence back to the GCS with a second binding. |
|
looks to me like a nice clean implementation, which clearly works well. lgtm. |
| mission_type: MAV_MISSION_TYPE_FENCE | ||
| }; | ||
|
|
||
| gcs().send_to_active_channels(MAVLINK_MSG_ID_MISSION_ITEM_INT, (const char *)&ret_packet); |
There was a problem hiding this comment.
this won't handle pkt loss, or running out of uart buffer space
This adds a manual binding to allow one to load fences directly from scripting.
Required some small changes to the generator to allow nested userdata and userdata enums. There a bit of a pita to work with in lua (see comments in example), but they do work.
I attempted to use the lua buffer as with the logging binding but it was garbling the data by the time fence got it, not really sure why, so this ends up with out. Probably a bigger buffer than logging uses, but this will be a once before flight rather than a constant rate.
#15550