I coded a lua script for selecting a mission out of an infinite number of missions on SD-card and relocate (translate+rotate) that mission to the current location of my vehicle by pressing a button on transmitter.
You have a start (Mission#0) in the middle,
then two loiter waypoints NW (Mission#1),
then a horizontal eight NE (Mission#2),
then a triangle SE (Mission#3),
then a rectangle SW (Mission#4)
and in the end a landing (again Mission#0)
…and all is done by a single push-button on transmitter.
Three of that missions are situated in Europe, but it’s no problem to relocate them to Australia.
So my personal mostly used case is the horizontal eight that I defined at my home-airfield: I just place it against the wind when I’m looking for thermals when soaring or when I’m at the slope.
But there are surely many other use cases.
E.g. if you lost a plane or copter over a wheat field and you have to start a search by a camera-copter - just use an automatically created meander mission and place it where you suppose to find it.
Or use just translation without rotation to scan the ground of a lake:
For not to lose accidentially a mission in FC at start of the script, the Mission in FC is saved to one of five files SRM_Backup#x.waypoints in cyclic manner.
The last used Backup# you can find in SRM_Count.txt.
Only Waypoints (MAV_CMD_NAV_WAYPOINT/ID:16) and Spline-Waypoints (MAV_CMD_NAV_SPLINE_WAYPOINT/ID:82) will be relocated.
The diverse MAV_CMD_NAV_LOITER_xyz commands (e.g. MAV_CMD_NAV_LOITER_UNLIM) with optional location-information will not be relocated. If you want to relocate that commands, just put a Waypoint at the location and use the LOITER_xyz without location as next command.
Waypoints after DO_LAND_START (MAV_CMD_DO_LAND_START/ID:189) will never be relocated.
The Mission will be rotated by the heading of the vehicle at the moment the Start-Button was pressed (relative to North). I.e. if the vehicles heading is East, the rotation will be 90° clockwise. So you should plan your Missions “North-orinted”.
The altitude of the relocated Waypoints will be adapted only positive. I.e. if the vehicle at relocation is higher than the first Waypoint in mission, all Waypoint elevations will be increased accordingly. If it’s lower, no adaption will take place.
To prevent from accidentially relocation at start, there is an adjustable safety-radius arround Home within no relocation will happen.
SUMMARY OF PARAMETERS:
SRM_POSITIONS – the selection-method and/or amount of switch-positions
1 = pushbutton for cyclic selection
>1 = amount of switch-positions
0 = script paused
SRM_RC_SELECT – the RCx_Option (300…307) for selecting the mission or 0 to use start-button defined in SRM_RC_START
SRM_RC_START – the selected RCx_Option (300…307) for pushbutton to start the relocation
SRM_RELOCATION – the selected RCx_Option (300…307) of 3-pos-switch for definition of the kind of relocation or
directly via parameter:
0 = no relocation
1 = translation only
2 = translation+rotation
SRM_NO_RELOC_M – no relocation of Mission within a radius of XX m around Homepoint
should be adapted according to vehicle (kind, size, power, agility, …)
adapt SCR_HEAP_SIZE to e.g. 102400 to have sufficient memory available for the script
create the subdirectory ‘missions’ in the directory where the sripts are stored
load the Missions to that subdir:
a.s.o. Hint: No gap in the mission-numbers allowed
select the RC-input-pushbutton you want to use as SRM_RC_START (300…307) and set parameter RCx_OPTION accordingly
select the RC-input-3-pos-switch you want to use as SRM_RELOCATION (300…307) and set parameter RCx_OPTION accordingly
or set SRM_RELOCATION directly to 0=no relocation / 1=translation only / 2=translation+rotation
Options you have to select before relocation
Mission# (via pushbutton or multi-switch)
Kind of relocation (via 3-pos-switch or parameter SRM_RELOCATION)
start as usual
switch to a none-AUTO mode e.g. FBWB in ArduPlane and move to where you want to relocate the Mission
push the selected SRM_RC_START button
mode-AUTO is selected automatically
Hint for experienced users:
It would be straightforward to use other sources (e.g. a poti on an RC-input) to generate the amount of rotation, but from my side it’s not intended to overload that script more than necessary.
After long nasty wintertime the weather yesterday gave me the chance to check the last version of SRM-script in a real flight.
Especially the cooperation with Soaring I’m not able to test at home - but all’s working fine
The horizontal eight is defined far away at our RC-airfield:
Thanks for your motivating posts to @Allister & @Dimitris_Stefanakis.
Without feedback, it’s not easy for me to have an idea of general usability of such a script - at first I developed it for my purposes.
So it seems to me, placing a hidden bug in the script will help in the future
I’ve that in my personal code since years - especially for my many MATEK-F405-Wing FCs without scripting-ability.
But the developers decided not to pull it into the code because the FCs with only 1MB are more or less obsolete. They recommended to realize such things in lua.
Sorry but I am on the devs’ side on that.
Implementing waypoints with local frames in AUTO mode does not mean relocating the waypoints. The waypoints will be stored and used in AUTO mode w.r.t. origin.
@Mustafa_Gokce I’m also at the developers side. It’s a strategic decision not to overload the code and all that’s possible to be implemented in a script only to implement in a script. And for sure, relative/local frames would it make much easier to relocate a mission - but it’s a different thing.