As for #1 I’m not telling about implementing joystick driver in SDK. But about implementing interface that allows you to send control commands so you can implement such a joystick in your app.
Right, make sense.
- I set drone in Manual Mode which is not yet possible with SDK I believe (probably Action is best place to implement such stuff)…
Manual mode is not implemented yet because my goal is that the SDK is for autonomous flights which is the future rather than supporting “old-school” manual control. That’s why it currently only support position and mission control, so you need either GPS or something like flow.
The idea is that you develop and tune your airframe with manual controls. Once the airframe is setup and tuned correctly and works for autonomous flights, that’s when you can start automating things and plan missions using the SDK, etc…
If this view is not shared by the SDK users, I’m open to change this and support manual control as well, it’s just that I would really like to push autonomy.
- I send thrust commands in programmatically controlled way and with corresponding precision to validate drones thrust on the rig.
So this would be more like a motor test rig?
- I send pitch/roll commands or corresponding rate commands to validate control and to tune parameters on the rig again in programmatically controlled way and with corresponding precision.
Ok, I can see how the SDK would be handy to automate these things. Best would probably be to have some separate plugin that allows these sorts of control/motor tests.
As for other stuff like nsh or ftp how about implementing all the stuff QGC has and than building QGC on top of that SDK? Would it be easier to maintain and develop both SDK and QGC then? As for now you have to implement some features in SDK and QGC separately.
I had that idea too at some point but there are a few reasons against it:
- QGC already works well, so why would you change it for the sake of changing it? Building QGC on top of the SDK would be a full time job for 2 people for a year if everything goes well (or at least that’s my wild guess). Also, QGC uses Qt for the cross-platform things while the SDK does not, so that would be something to keep in mind.
- It’s not a bad thing two have two implementations for the mavlink functionality. We’re more likely to find errors of the protocol implementation this way.
- Maintenance and development can be quicker if it’s shared between pieces but at the same time you can end up in a big dependency nightmare and it actually becomes much harder to change anything. It’s a trade-off at the end of the day.
As for doing stupid things its funny argument) I believe somebody using your SDK is more responsible person and can do less stupid things then somebody knowing nothing about programming but who can fire up QGC and do whatever he can do with it.
That’s probably true but the goal should still be to try to guide the user not to make bad choices. One way is to make it clear what is sort of the normal use case and what are “expert backdoors”, such as the
param_raw interface, or a motor/tuning test plugin.