18

Proposal: Drones and Model Aviation

This proposal has a number of example questions that amount to "How to do X in Y software suite?" Some of these might be better suited to the specific product's support forums or GitHub. Should these support questions be considered on topic on this stack?

For reference, other sites have different policies for this:

  • Aviation.SE does not accept questions about specific CFD software (e.g. "why do I get this error in XFRL5?"), but it accepts general CFD questions ("What does this boundary layer parameter do for airfoil simulation?").

  • Engineering.SE is ok with suite-specific questions ("How to add a remote force in ANSYS?")

  • Robotics.SE is ok with suite-specific questions ("How to get data from ArduPilot through a serial port?")

To clarify, I am not referring to comparison questions like "What is the difference between ground station software packages A and B?" but rather specifically to support requests like "Why does ground station software A v0.9.11 lose connection with my transmitter?" or "How to set up antenna tracking in software B?"

3 Answers 3

Reset to default
17

This is a very good question. Personally, I feel the answer should be yes... in most cases. I think it is easy to agree that bug reports and associated issues with software packages should go on their respective GitHub issue trackers. That much I think is clear.

When it comes to "user-error" problems and questions about the behavior of said software packages, I think we should allow it. I can understand why the sites you listed above have the policies they do regarding asking for help with software suites. In my mind, we should be trying to be more like Robotics.SE and Engineering.SE in this regard than Avation.SE.

As an example from this proposal, most of the questions' subjects are the BetaFlight FC firmware. (This is an unfortunate coincidence of my inability to gain followers from non-drone enthusiasts. If you have a line on a more diverse audience, sharing to it would be great) The kinds of questions about BetaFlight which haven't been closed are in my mind justified living on this site because they concern how to use the software. Such questions are more relevant to a broader population than error reports, which are often due to the specific generation circumstances.

8
  • 3
    I say yes as well. 90% of all flight controllers use Betaflight or a fork of it.
    – tavis
    Dec 12, 2019 at 20:41
  • I agree on the bugs vs. user-errors , but those are hard to tell apart at a glance, especially with the tendency a lot of people have of not posting anywhere near enough details to diagnose their problem. How do you propose we deal with description-lacking questions?
    – AEhere supports Monica
    Dec 13, 2019 at 9:09
  • Furthermore, what line should we draw on what is "too broad"? I'm referring to questions for which RTFM is a valid, if abrasive, answer, ("hi how to connect the missionplanner ktx bye" being an extreme example).
    – AEhere supports Monica
    Dec 13, 2019 at 9:13
  • I honestly fail to see why the standard for defining questions that are too broad or not specific enough from other SE sites wouldn't work here. The way I see it, any question without sufficient detail to accurately describe the problem is too broad and one which concerns many different questions at once is too broad. Do you see a reason why this wouldn't work well here?
    – ifconfig
    Dec 13, 2019 at 16:01
  • I'm at a discord server helping people with questions, when BF 4.1 RC was release there were a few bugs to be solved, the users didn't have the knowledge to figure if it's a software bug or a configuration error and only few knows how to properly open and issue inside GitHub and yes it will be some kind of triage for the opensource/manufacteurs properties. I have the hope that the manufactures will help out
    – tiago ramos
    Dec 13, 2019 at 19:08
  • Sorry, @tiagoramos, your message is unclear. What are you trying to say?
    – ifconfig
    Dec 13, 2019 at 19:12
  • If you don't let specific software questions and redirect them to the GitHub, I say GitHub because 90% will be opentx and betaflight config questions, will start to overflow the GitHub with non issues, taking valuable time from the open source, I used to be part of the triage team in Ubuntu we wasted a lot of time with misconfigurations that could be used to debug real issues.
    – tiago ramos
    Dec 14, 2019 at 15:08
  • 3
    @tiagoramos, I really don't want to be running technical support for someone else's autopilot. IMHO, becoming the overflow for the maintainers' Issue list is one of the worst things which can happen to Drones.SE. If they need a Q&A forum for their ecosystem they should definitely invest in that, instead of increasing the noise at Drones.SE.
    – Kenn Sebesta
    Feb 8, 2020 at 2:44
3

I would also want product specific questions to be considered as on topic for this new site.

IMHO, one goal of the site should be to help hobbyists and people new to the field to become familiar with the everyday tools and features in these tools so that they can achieve specific results.

For example, after building my first quad-copter, I’ve come to realise the importance of filtering vibrations from the gyro in order to get good flight performance. However, filters can be done by hardware or software. With software filtering there are many different solutions and being able to understand what each solution brings and how it interacts with and which combinations of filters give good results is not always explained in the manuals.

Manuals tend to be written for a particular audience in mind. If you’re not the target audience and you have trouble understanding it then what do you do?

Other stack exchange sites, such as mathematics or photography allow questions regarding the use of Matlab or Photoshop respectively. I presume this is because for many mathematicians or photographers these tools are vital for their work and the questions/answers are of interest to many in the community.

1
  • agreed, from my own experience in various Drone related communities questions about software and configuration are the most common ones, so excluding them seems counter productive.
    – ppetermann
    Feb 1, 2020 at 21:05
1

No, they should not be on-topic at this point in time.

  1. What makes the difference between a good tool-specific question and one guaranteed to quickly go stale is the stability of the tool-set. Drone autopilots are still very much in flux, with projects forking and being abandoned on a yearly basis. Graphics, UI, and APIs are constantly being updated and deprecated.

  2. A weaker argument, but something important to consider, is that we not accidentally deprive the autopilot ecosystem maintainers from feedback. If someone is struggling to configure a hexrotor in a particular suite, the suite maintainers should be finding out about that directly via their forums.

  3. Lastly, arguably the suite-specific questions which are acceptable on Robotics.SE are really focussed on the connecting glue for robotics. Getting a serial port working on ArduPilot is relevant because the goal advances the general state of robotics.
    Whereas in Drones.SE, the link is much more direct. We're more likely to be fielding tons of tiny application questions, such as how to get a PixHawk equipped fixed-wing drone to orbit around a point. This isn't advancing the state-of-the-art in drones, it's just getting a PX4 user over a bit of a hump.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .