What’s the most straight forward way to add custom commands that can be accessed in the “Plan” tab for mission planner? I’m currently using the “SCRIPT_TIME” command and reading the Arguments in a Lua script to do a few different custom actions when a waypoint is arrived at. I don’t like this because this might confuse the users and I would prefer the name of the action to be the command instead.
If I could just wrap the “SCRIPT_TIME” command with a different name, that would work! Would this require compiling the source code? I’d like to avoid that at all costs because I do not have a linux machine at hand.
Well, I am not sure I understood what you want to do but it is not a good idea to try to intercept the order coming from a mission planner button and modify the action made by it.
What you could do is adding a new button and use functions of the other buttons but it is not clear to me what you want to do so I can’t help you
I am using the SCRIPT_TIME command in my missions to trigger certain actions in LUA. SCRIPT_TIME has a 2 arguments that get passed into LUA and I’ve got a few different actions in LUA that trigger based on the SCRIPT_TIME arguments changing.
I would like to breakout the functions from SCRIPT_TIME and make a custom command for each different argument value. I think ultimately, I will need to add custom mavlink message to achieve this. I’ve only used LUA scripts up to this point, so adding a custom mavlink message and compiling the firmware seems a bit daunting.
It sounds like you have the right idea if you want to move forward with custom commands, however…
If you choose to build custom firmware, you’ll either be stuck on that version perpetually or you will have to pull newer versions of ArduPilot into your custom fork/branch in order to take advantage of future bug fixes and features. In my opinion, that’s a maintenance nightmare.
Additionally, you’ll need to make sure the GCS software is aware of the new commands, which likely means a custom build of Mission Planner or QGC. With that in mind, you could avoid a custom firmware build and simply write a little context into the GCS UI for your existing SCRIPT_TIME commands such that the GCS has proper titles/headers/dropdown selections on the planning page. But…that’s yet another maintenance nightmare.
As an alternative, give some more thought to exactly which parameters are important to your SCRIPT_TIME features and lay them out well. Then consider writing a companion “checker” of sorts that your users could use to validate their missions before sending them. Even a simple command line Python script (or similar) could be used to parse a saved auto mission and provide the user some insight into the SCRIPT_TIME events that he/she has selected.