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

max system id is limited to 250 #1307

Closed
BazookaJoe1900 opened this issue Feb 18, 2020 · 8 comments
Closed

max system id is limited to 250 #1307

BazookaJoe1900 opened this issue Feb 18, 2020 · 8 comments

Comments

@BazookaJoe1900
Copy link
Contributor

BazookaJoe1900 commented Feb 18, 2020

This is more of a question then a bug.
From what I Understand the sys_id is the identifier of the system that should be unique for every drone and station. am I right?
that mean that there is limit to only 250 drones+ground stations.
If a squad that has more than the limit, how is advise to overcome that?

@hamishwillee
Copy link
Collaborator

Yes. Every system on the network must have a unique id from 1 to 255. This is a limit of the fact that there is a single byte used for the address. You can't use 0 because that is a broadcast address.

So you can have 254 items.

If you need more, then you'll have to manage separate mavlink networks.

@BazookaJoe1900
Copy link
Contributor Author

@hamishwillee Thanks!
Do you know if there is a plan to extend that in some way?

@BazookaJoe1900
Copy link
Contributor Author

BazookaJoe1900 commented Feb 20, 2020

@LorenzMeier, @dagar
do you know if there is some work-on-progress about this issue?
I have thought of creating some "mavlink 2.1" where the changes will be contained so small changes:

  • header system_id is 16bit.
  • there will be target system and target component on the header (similar to UDP) (and will be removed from messages that have them)

@hamishwillee
Copy link
Collaborator

@BazookaJoe1900 There is no specific work on this. The changes you are suggesting would necessarily be incompatible, so would require some care.
Do you think you might attend the MAVLink dev call - we could then discuss options?

@BazookaJoe1900
Copy link
Contributor Author

BazookaJoe1900 commented Feb 27, 2020

@hamishwillee, Its understood that it breaks compatibility, but its required for commercial systems.
Yes, I would like to discuss that on the Dev call.

as baseline for the call, I have the next proposal, (from above)

  • Header system_id to 16bit.
  • Add target system and target component on the header, similar to UDP (and remove from messages that have them)

@hamishwillee
Copy link
Collaborator

What sort of commercial systems do you have in mind? I suspect you're going to have to manage this out of MAVLink at least initially - because even if we had a solution today, there will be systems running "vanilla" MAVLink 2 for years.

FWIW I think that there are many possibilities here. Extending the header is one, or defining a variable for a network id, or even directly mirror IP addressing. I don't know the best approach.

I am unlikely to be at the meeting. @julianoes @julianoes @auturgy are you planning on attending next week?

@BazookaJoe1900
Copy link
Contributor Author

By commercial I mean a fleet of more then 255 drones and GCS. not all running at the same time, but it possible to "switch" between drones on the same GCS, or switch between GCS's to control the same drone. -> so each drone/GCS must have some unique ID.
Mavlink SysID, probably is the best candidate to define this ID. and the mavlink protocol and logics already support all what related to that.
but the 255 limitation "kills" using the SysID as the distinction between the systems.

@hamishwillee
Copy link
Collaborator

@BazookaJoe1900 Yes, I get the limitation. I was just wondering what you're doing with fleets that have more than 255 vehicles? That is a pretty big fleet. I also agree that while this is a big fleet right now, it isn't going to be forever. So this is a problem that it would be best to solve sooner rather than later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants