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

Investigate communication speed #467

Closed
knmcguire opened this issue Sep 3, 2024 · 4 comments
Closed

Investigate communication speed #467

knmcguire opened this issue Sep 3, 2024 · 4 comments
Assignees

Comments

@knmcguire
Copy link
Member

We have been saying that the communication speed (packets per second) should be about 400ish packets per second. The maximum size is 26 bytes (without the header). The minimum period per packet is 10ms

Let's check this with the current situation! There might be some bottlenecks here and there (usb to crazyflie), but it would be nice to have some ice cold hard facts in numbers to see what the current situation is.

@whoenig
Copy link
Contributor

whoenig commented Sep 4, 2024

FYI, in Crazyswarm2 in the cpp backend we continuously monitor these sort of connection statistics and also allow for user-provided warning threshold.

@knmcguire
Copy link
Member Author

Thanks! Yes I was aware that you have implemented something like that. Eventually we want to add more quality checks to the cflib as well, but for now this is just investigating without adding a new functionality, so a separate issue will be made for the quality stats (for better user understanding of what is happening and for CI)

This was the PR where you implemented the latests on these quality stats right, in cpp link? bitcraze/crazyflie-link-cpp#28

@whoenig
Copy link
Contributor

whoenig commented Sep 4, 2024

The statistics in the link had been around for a long time (other backends might have it too?). It was hooked up to the warning system here: IMRCLab/crazyswarm2@d71ee98.

@knmcguire
Copy link
Member Author

I'll close this as we have determined that there is not really that much wrong with the overal communication packet sending but many other things that we simply can't monitor. After we have implemented #469 we can make any issues that we see arising of our tests to specific issues here, but at least the investigation has lead us to the path of better comm stats improvements 😄

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

No branches or pull requests

2 participants