Move to Python Asyncio with next SDK?

[zlite]

I may be preaching to the converted, but can I put in a vote for rethinking the crazyflie multitasking approach as you move to the Crazyradio 2.0? Callbacks are pretty outmoded, and starting with Python 3.9, the Python team has really been encouraging the use of asyncio for multitasking instead.

This library is a pretty good start at porting the Crazyflie SDK to asyncio, but is incomplete and the C++ CR drivers are a PIA: https://github.com/skybrush-io/aiocflib

What do you think about moving to asyncio for Crazyflie SDK 2.0?

[krichardsson]

Hi and thanks for the feedback!

Yes, asyncio is on the radar :-) We have been, and are currently discussing the library, the API and what we want to do with it in the future. Pretty much everything is up in the air at the moment and we are hoping that it will come back down and hopefully fall into place. We are trying to rethink the full communication stack and the API is part of this work.

In my opinion it makes sense to use the most standardized mechanism in a language to express functionality in the API, and like you mention, for python asyncio is the way to describe multitasking.

Any feedback is welcome, don't hesitate if you have other input.
Thanks!

[ataffanel]

Hi, nice feedback which matches what we have been looking at. I can add a bit since lately I have been thinking and experimenting with the communication stack and lib.

Moving to synchronous-looking code is definitely something I would like to do, callback have caused a lot of problems and if Asyncio is the way to do it in Python why not. We have a bit of AsyncIO already for the Qualisys system and it has cause a lot of trouble to interoperate with Qt in the client, but I am assuming things are going to stabilize more with the Python team pushing for it.

One thing I have been pitching internally is to write the lib in Rust and then making a Python binding for it. Rust is much easier to compile and distribute on different OS than C++, it is more pleasant to use and it would also allow to make C/C++/ROS binding from one single official CF lib. The API I ended up with in my experiment does not have any callback, everything looks synchronous. My initial though was that if a lot of the communication is handled outside of python, asyncio might not be needed. But thinking more about it having asyncio in python might actually be required anyway since everything will be a task and so we might end up having a lot of waiting Python tasks.

Like @krichardsson says, everything is currently in the air, even the language of the next lib. I have been playing with Rust and I love it but it might or might not be a way forward.

We are planning to have an online dev-meeting in February to talk about the new comm and lib architecture. We will announce the date soon on a blog post. This might be a good place to talk more about ideas and needs for a new lib.

[zlite]

Excellent. Really interesting to see how you think about a future architecture that can scale across all those platforms and use cases. I haven't used Rust myself, but my friends in the commercial embedded space have been moving their whole stack to that with good results