Skip to content

chore: refactor "Flysky gimbal" to "Serial gimbal" #5713

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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

rotorman
Copy link
Member

No description provided.

@3djc
Copy link
Collaborator

3djc commented Dec 16, 2024

The issue I can see is there might be other serial gimbal protocols looming around..

@rotorman
Copy link
Member Author

rotorman commented Dec 16, 2024

As the same proto was used by also other companies as FS, the name seemed not appropriate anymore.
Would you have a better suggestion how to work around this?

@pfeerick
Copy link
Member

As the same proto was used by also other companies as FS, the name seemed not appropriate anymore.

IMO... yes and no... if the same protocol is being used... and Flysky came up with it first... then it is still Flysky serial protocol... but I think perhaps it is more that new radios, i.e. GX12 is using serial gimbals, not necessarily Flysky protocol, so instead a new specifier is needed to cover that case, or at least a generic specifier. i.e. perhaps "flysky serial gimbal" is a subtype of "serial gimbal" ;)

@pfeerick pfeerick added the house keeping 🧹 Cleanup of code and house keeping label Dec 16, 2024
@3djc
Copy link
Collaborator

3djc commented Dec 17, 2024

As the same proto was used by also other companies as FS, the name seemed not appropriate anymore.

IMO... yes and no... if the same protocol is being used... and Flysky came up with it first... then it is still Flysky serial protocol... but I think perhaps it is more that new radios, i.e. GX12 is using serial gimbals, not necessarily Flysky protocol, so instead a new specifier is needed to cover that case, or at least a generic specifier. i.e. perhaps "flysky serial gimbal" is a subtype of "serial gimbal" ;)

GX12 is using flysky serial gimbal protocol, I was thinking about another manufacturer which serial gimbal will use a completely different protocol. I'm personally not too fussed that the first to bring up a feature/standard/code gets his name for it, we call CRSF the radio to module ELRS protocol too

@richardclli
Copy link
Collaborator

I have concern about this. Flysky has a new version of protocol which supports sync sampling. And I am working on it, and I cannot guarantee that this change is compatible with other serial gimbals. I think the best way is to split the implementations.

@3djc
Copy link
Collaborator

3djc commented Dec 18, 2024

That's a possibility, but then how do we select which one to use ? Ok, Flysky radio get FS one, RM rm; Jumper jumper, but what does it mean for say FrSky radio that wants to add one of those 3. Do we include none and provide a compilation option for user to build their own custom firmware ?

@rotorman
Copy link
Member Author

rotorman commented Dec 18, 2024

Also, what if non-FS radio is modded with FS gimbals, like is possible: https://github.com/EdgeTX/edgetx/wiki/Flysky-Hall-Sticks-Mod

Ideally, our code should auto-detect the gimbal attached.

@3djc
Copy link
Collaborator

3djc commented Dec 18, 2024

Ideally I would agree, but I don't think any of those protocols actually allows that

@rotorman
Copy link
Member Author

The present FS implementation has a checksum, which could be one way to validate if present non-sync FS protocol is being used, or not.

@3djc
Copy link
Collaborator

3djc commented Dec 18, 2024

RM serial gimbal use 100% the same code, but for synchronisation where they use a dedicated line, so at this point in time, I have forced it on GX12 to assume it is a RM gimbal, so it uses Flysky serial code, and forces RM synchronization

@richardclli
Copy link
Collaborator

And my opinion is not necessary to do this renaming at this moment. RM just made a Flysky protocol compatible gimbal with sync enhancement. Not quite original to worth any refactoring effort just for a name!

@pfeerick
Copy link
Member

pfeerick commented Apr 28, 2025

@rotorman @richardclli @3djc

Can we get consensus on this?

I am of the opinion of "flysky gimbals" can be a subset of "serial" gimbals, but this is contingent on a second serial gimbal being present, requiring slightly different handling. Otherwise, very much, whatever.

@rotorman
Copy link
Member Author

I am with you that the top-level description for serially attached gimbals should be SerialGimbals, which could then have subdescriptors for variants, like SerialGimbalFS/SerialGimbalFlysky and so on.

@richardclli
Copy link
Collaborator

@rotorman @richardclli @3djc

Can we get consensus on this?

I am of the opinion of "flysky gimbals" can be a subset of "serial" gimbals, but this is contingent on a second serial gimbal being present, requiring slightly different handling. Otherwise, very much, whatever.

First take a look at #5869

Now there are gimbals that implement:

  1. subset of Flysky v1.0 protocol (GX12)
  2. Flysky v1.0 protocol (Flysky radios)
  3. Flysky v2.0 protocol (Flysky gimbal update)

Now auto detection is only done for Flysky v2.0 protocol, maybe we need to figure out a way to distinguish 1 and 2 as well. And I think the change should be made on top of #5869

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
house keeping 🧹 Cleanup of code and house keeping
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants