I was a bit sad to see sport mode was removed, i liked to use it to do some cinematic shots, where i could just lock the angle and throttle of the drone on a calm day, and move the gimbal around.
Is there a way get the same functionality with Acro for example? Sport mode would limit the max angle of the drone, and also semi stabilize the drone back to those max angles if the wind would push it outside the limits (from what i could tell, or maybe just my imagination).
I don’t want full Acro, as i don’t want the drone to be upside down at any point , it needs to have some stabilization at least in case of unexpected un-commanded external forces.
The issue is there are already some pull requests pending to remove it from Mission Planner as well… So unless they revert the change (please?) i need another option.
It makes sense that it would be removed from MP if it is no longer officially supported in the latest stable version. You can still build the firmware with it enabled and use it unimpeded. You simply won’t have a specific text-enabled selection for it in MP, and it will probably display as an unknown flight mode when connected. Related parameters should still be accessible, but they will lack textual descriptions and recommended limits.
Here is the related PR and rationale, which makes sense. If you dig a little further into the issues and PRs, you’ll see that it was considered for deprecation for about 4 years before the decision was made to simply disable it by default to save flash rather than deprecate it entirely.
I put a comment there. Hopefully one user using it will be enough to revert it. I never had to post any logs since usually i manage to fix all issues, and never had any bugs on my drones. On top of that, if needed i would post a log in stab or althold, since other flight modes are just extensions; the bug would be present in the main flight mode as well. So in my opinion logs are not really metrics to see if a flight mode is used or not
I think you’re making more of this than it is. The feature is still available. It isn’t even slated to be removed from MP, as noted in that closed PR by Randy. I retract my previous statement that it should be removed, since it is still supported just not enabled by default.
I see no sport mode specific bindings for Lua, so that is a moot point. You can still interact with the flight modes and parameters via scripting all the same, and that appears pretty future proof.
It is seldom used, so saving flash in favor of other features makes sense, which is a pretty minor inconvenience to those who do use it (I fail to see your point about building custom firmware being that bad).
That said, weighing in on the issues/PRs is absolutely the right venue to make your voice heard. You will probably get a response there, one way or the other.
It’s a cascading effect. MP + Ardupilot might just hide it, but other softwares might not, since they also recon “oh if AP is not using it, we can also remove it”.
Lua i mean scripts on the radio. A lot of them are starting to go closed source, with no way to add features if they decide to remove the mode. For example:
Also, the code change from AltHold to Sport is very small. Having the controller hold attitude vs level is trivial and i wouldn’t say takes up lots of flash. There are many other features that are also not used that take up much more flash.
Having to use the custom build tool would hurt everyone if someone uses the feature. The firmware compile time + storage on the server + user having to do it for each firmware release.
Flight Deck has been irrelevant/obsolete for years. Their website is showing a version of Arducopter from 2017… The Yaapu telemetry script replaced it.
Well, I’m somewhat happy to hear that sport mode is/was actually being used. Leonard wrote it years ago and it seemed like it was a waste of effort but the use case described is what it was meant for.
I suspect we will bring it back. If done today, we probably would have implemented Sport mode as a lua script because all the required control are available in Lua but because it’s already in the C++ we can probably just bring it back.
In case it matters, besides the flash savings, it’s just good practice (I think) to try and keep complexity down by removing those features that seemed like a good idea at the time but didn’t end up becoming popular.
We’ve got other candidates for the chopping block though including the AVOID_ADSB mode and ToshibaCAN ESC support.
By the way, I think you should be able to create a Copter-4.2 binary with sport mode using custom.ardupilot.org.
I have also wondered why Sport is deprecated. It turns out, there is no particular reason, apart from the desire to remove features that are (apparently) not used, which is not the case.
Regarding Sport though Lua, I wonder whether the control reaction speed will suffer if we do this. Sport is basically Acro with altitude control, and one wants to really maintain the angles as sharp as possible. As some people try to increase the scheduler frequency to make that even sharper, I wonder whether Lua is up to the task.
And this also raises the question of composite modes. AltHold is Stabilize + altitude control, Sport is Acro + same. Of course not all modes are easily decomposable, and I understand that Ardu seems to be generally against composite modes. But that might be an answer to the flash size: maybe with a little refactoring we get the fourth mode for free?
Change the second to last line to your board. You will end up with the same firmware as Mission Planner outputs.
Use the custom build tool:
If you want to end up with close enough to the same firmware as Mission Planner, select ALL the features apart from VTOL. I’m not sure if the custom builder takes into account the “!HAL_MINIMIZE_FEATURES” that the local builds do (which takes into account if your board has disabled some specific feature or if there is enough space for it). In the output it seems to completely remove the definitions and re-adding them, which would be bad.
A message saying to do this to get a default firmware should probably be added, or better yet, a button that will select all the features that DO generate the exact same default firmware.
Because of the slight difference in file size, having to guess what features are default and the strange output removing all features even though all are selected, i will probably just build my own firmware to be sure, i don’t really trust the custom builder at this time.
@rmackay9 Hoping to skip all of this when the mode is re-added
Yes I did that today and it seems to have worked nicely when loaded to the Cube. But when I tried to use the resulting APJ file with the APJ tool to set or verify default parameters it would give “Param defaults support not found in firmware”.
, it needs to have some stabilization at least in case of unexpected un-commanded external forces.
