Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

**Feature Request / Discussion**: Airframe group definitions for Planes #9118

Open
philipoe opened this issue Mar 20, 2018 · 5 comments
Open

Comments

@philipoe
Copy link
Contributor

philipoe commented Mar 20, 2018

Feature Request / Discussion

The PX4/QGC airframes for planes are in my opinion somewhat ambiguously defined. The obviously good concept of grouping airframes was contributed here. Currently, there is the groups "standard plane" and "Plane A-Tail", i.e. we group them by tail configuration. However, the planes in these groups also seem to differ by their flap configuration (Plane A-Tail: Two separate flaps, Standard Plane: Flaps on same servo output or not even connected).

Overall Question: Why were the groups chosen that way? I assume just because at that time there was only a limited amount of platforms. Overall however, I could think of the airframe types:

  1. Plane A/V-Tail, with 2 separate flaps
  2. Plane A/V-Tail, with 0/1 flaps
  3. Plane T-Tail, with 2 separate flaps
  4. Plane T-Tail, with 0/1 flaps (current group: Standard plane)

These groups would cover a wider range of configurations. Specifically I am thinking about adding a) Multiplex EasyGlider (proposed group 4), HobbyUAV Techpod (proposed group 3) and RP Flight Systems Vigilant C (proposed group 1).

@hamishwillee Seems like you were heavily involved in this.

@stale
Copy link

stale bot commented Jan 26, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@hamishwillee
Copy link
Contributor

@philipoe Sorry, completely missed this issue. Generally the design has been based around reducing the selection as far as possible - to a set from which a user can reasonably make a selection that will work (ie previously we have millions of specific tunings that were effectively the same).
Currently the set looks like this:
image

Anyway, sounds like you may have a point. @dagar @RomanBapst ?

@hamishwillee
Copy link
Contributor

Keep this open

@stale
Copy link

stale bot commented Dec 24, 2019

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@stale stale bot added the stale label Dec 24, 2019
@hamishwillee hamishwillee removed the stale label Jan 5, 2020
@stale
Copy link

stale bot commented Apr 4, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@stale stale bot added the stale label Apr 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants