The future of Rosetta Drone

[pktiuk]

Hello,
I would like to ask how do you see the purpose and the future of this app in the long term?

Is it just your personal side project developed for your usage, or something meant to be used by many people? Do you plan to make it more accessible for users, are you planning to promote it/gather some community around it? (And if yes how are you going to do it?)

[kripper]

Hi, my vision is:

• DJI drones are the best drones available in the market considering features and price.
• the development ecosystem around the DJI SDK is very poor and we don't want to be constrained to DJI, but be part of the MAVLink OS ecosystem.
• RosettaDrone is and will be the official MAVLink wrapper for DJI drones, but is also a general framework for building applications on top of the SDK, since it includes a GUI, a mission manager (an "off-board flight controller implementation") and even a Plugin interface that allows us to continue extending in any direction.
• I'm continuously cleaning, rewriting and improving the code base and overall "development experience" to attract more developers to join the project and help us to improve everything.
• I'm currently interested in computer vision and AI development and would like to see more projects compatible with DJI drones. Actually, in the next days I will release a framework for measuring and calibrating the drone dynamics required for precision landing based on vision (vision latency, effective measured velocities vs controlled output velocities, dynamics estimation and prediction, etc).

What are your interests and vision?

[pktiuk]

To be honest, I investigate for my company whether this app is a suitable base for our projects, because (as you said) DJI has a very poor ecosystem. I don't have any particular vision about four further development. But I may have some advices (from my experience linked with maintenance and development of app called AntiMicroX )
For the sake of order I would prefer discussing these aspects in separate comments in this discussion. But the short list is:

• Creating separate organization was a great Idea, it makes management much easier lets you group all repositories related to Rosetta in one place. But I think you should make a small cleanup of this repository.
• You should think about promoting your app and making it more accessible for users, not only to attract developers, but also to make your app more visible and easy to find.

[kripper]

I investigate for my company whether this app is a suitable base for our projects

What projects are you developing?

[pktiuk]

I'm sorry, but I can't tell.

[pktiuk]

Cleanup of repository

I think creating organization was a good first step, but there are some things to do (mainly in issues):

• You should convert to discussions some old issues which were used for talking like Help to connect drone to python program #96 (this is neither bug, nor precise feature request, just a discussion)
  
• Close outdated issues (for example Cant build in android studio #5 )
• Use proper tags with remaining issues bug, enchancement (and others you may find useful telemetry, video, android, maintenance etc.) to make managing them easier
• Remove some entries from your README and Wiki. Many things are visible in both of these places, it would be good to remove redundant entries. For example building from source. You could just put link to wiki in readme.
• In readme there are Known Issues for Users and Developers. Why these issues don't have any open issues? You could open some issues for them and properly label them
• You should store docs about your app by yourself (I think about docs Delta Flower wrote ) because they can be outhated and you may not have any control over them.
• Contributing/hacking tips would look better in wiki (instead of random google docs, which may expire).
• instead of announcing implementation of something new (or updating used SDK version) in README you should create simple changelog.
• (optional) I would also recommend deciding what would be your recommended code formatting (used code formatter) to ensure consistency across entire codebase

[kripper]

there are some things to do (mainly in issues):

Do you want access to manage the issues?

[pktiuk]

I could help with them, but you are the one who should some of these tasks (like opening issues for these Known Issues, because I don't know any context)

[pktiuk]

Promoting Rosetta Drone

My subjective experience (click me)

I spent over 1 day looking for alternative DJI apps and I found only apps like `Litchi`, `Rainbow for DJI` and `Maven Lite`. Later I was crawling through forums to get to know whether there is an option to stream with other apps/protocols from DJI. (Just write in google `Dji low latency streaming` or `DJI alternative apps` and see where you can see even the briefest mention of Rosetta Drone). I found it only thanks to luck (also searching for `DJI` and `DJI Android` in Github did not bring any results). This app can be found only through MAVLink docs and forums.

Rosetta Drone is very difficult to find and it requires a rather big time investment for potential user/developer who wants to test it.

• You should make this app more searchable - at least add some topics to this repository (DJI, Android, Streaming, MAvlink etc.)
  
• There should be a build available for regular users/people who wants to test it (in Release page)
  • I know that it requires registering DJI app in developer site, but I don't know why it is a problem. I think they serve similar purpose to tokens required by discord bots.
  • TBH I don't know why license from google is obligatory. It was not used earlier (legacy repo and FLower wiki you mention in Readme), so I guess this is not necessary part of app. It should be optional, because Google API is paid and in published version of the app it should be disabled
  • Rosetta is focused on developers, not final users - I don't think this claim makes sense for app which is meant to be used, but I agree that reports from non technical users may be useless. If you don't want reports from users unable to compile the app, then you can just add disclaimer to the issue templates, that if you want bug fixed, then you should be able to compile it to test proposed fix or something (proper instruction for collecting logs also very improves quality of reports). Regular users generate traction and demand for plugins. They would also generate posts in your Discussions. Thank to them you could start thinking about donations, which may be useful because development of this kind of app sometimes requires access to physical hardware.
• I would also recommend adding some screenshots describing elements of the interface, because not all of the icons can be obvious