I've been looking around at ways in which to control a drone from a computer and although I've certainly found *some* solutions, they don't seem to be what I'm looking for. Here's hoping that one of you has that magic link I've been looking for

Basically I'd like to directly do in software what we would otherwise do with our hands on a TX, and I'd prefer to be able to use a Betaflight-alike board and an RX that I know I can trust like an FrSky/Flysky protocol.

First I'll share what my research has taught me and then describe what I'm missing.


This whole domain is new to me but I've read up a bit, let me see if I can put things in order correctly. I believe that a fairly normal setup would be along the lines of using QCGroundControl or Mission Planner software on your laptop/computer. These can speak to flight controllers like PX4 and ArduPilot using the MAVLink protocol. The wireless connection speaking that protocol could be done using something like the 3DR 433Mhz/914Mhz transmitter/receiver combo (banggood link).

From what I can tell most drone controlling software is like 'mission planner' stuff: operates for the most part as a waypoint delivery and flight status monitoring system with a focus on 'managed' flight. My main interest is actually directly controlling the throttle/yaw/pitch/roll channels (and some more AUX channels too) via software in real time, ideally an API of sorts. I've found something along those lines in Dronekit.io and I'm thinking it's probably going to allow me to bypass the whole QCGroundControl/MissionPlanner software and directly chat with the flight controller through the 3DR transceivers. But that does leave the necessity to use a MavLink-compatible flight controller and I find them bulky  and over-featured for what I need. I'd rather just use a Betaflight board, but AFAIK that doesn't speak Mavlink(?). What's more, in an ideal world I'd also be able to use the cute tiny RX's that we have in the hobby, meaning that I'd like to be able to talk protocols like ACSST (taranis) or ADFHS (Flysky). It's my guess that those protocols are probably lower latency as well. BUT... what solutions are there on the PC side to actually employ those protocols??? 

ARG, I feel like I'm missing a small little thing. Like that ONE magical device (computer-side) that will allow me to talk directly to a quad using a fast protocol.

Thanks in advance.

ps -> another route I found is to go the oldschool DIY way and use a connection using a 2.4Ghz connection like an NRF24 wireless transceiver chip and Arduino. The Arduino on the receiving end would speak to the flight controller over a UART with the MSP protocol... right? I'm not massively opposed to that but I'd rather depend on the robustness of Flysky/Frsky/etc RX's that I've come to know by now.

I have no answers, but I do have a question. Why? I'm not trying to be a smart-ass, but it seems to me that you are trying to take the fun out of the hobby.

Great question, happy to answer. Didn't want to add that to the original question and make it a huge story. My intentions have anything to do with actual fpv flying. Like you I enjoy the necessity of developing good stick control.

I'm going to use a Vive Tracker (using the HTC Vive VR system) on the quad to track its movements super accurately in 3D and position the quad within that 3D space wherever I want. Should be fun to do. I've seen other people do it but I want do try it myself too. Will entail employing a PID controller in how the quad moves from its current position to a defined destination position, looking forward to tuning that. It's all theory for now though. First to get the quad computer-controlled.

MSP is the equivalent control protocol to MAVLINK for Betaflight/Cleanflight. The base protocol is documented (poorly) in various places on the Internet if you search for Multiwii Serial Protocol. What's actually supported in Betaflight is probably only documented in the source code.

I know that Betaflight/Cleanflight supports minimal MAVLINK telemetry, but I doubt this is enough to control the craft in flight.

Although FrSky receivers implement a generic serial data stream over the link via SmartPort telemetry and there is code in Betaflight which bridges SmartPort to MSP, it's a request/reply model rather than the subscribe/publish model that MAVLINK uses. I have my doubts about the effective baud rate of the telemetry link being sufficient for what you want to do.

I think your idea of using a dedicated wireless serial link is better than trying to cram full speed bidirectional MSP down a SmartPort telemetry link.

Thanks for your reply. I'm starting to think that you're right about not wanting to use the Mavlink connection for full control. I just haven't found decent other ways to send my control commands to the quad. Well that's not totally true: my fallback is going 'oldschool' and implementing this:

pc <-- serial --> arduino <--> NRF24* <- - - - - - - - - - - - -> NRF24* <--> arduino <-- MSP --> flight controller
*NRF24 is a general purpose 2.4 ghz transceiver module

If possible though I'd prefer to use an existing robust tx/rx protocol that handles failsafe and such. Does that seriously not exist?

Failsafe is a firmware feature on the receiver. It's one thing to have the firmware remember fixed values for the 8 or 16 channels that are transmitted and use the saved values if a new packet isn't received within a time limit, but you can't have failsafe for arbitrary binary data.

If you just want to mimic stick control and have failsafe on a receiver that thinks it's talking to a radio with sticks, then you don't need to start looking at MSP or MAVLINK. Just take yourself over to deviationtx.com and have a look in the repo for the DeviationTX firmware. A deviated radio uses SPI to talk to the various transceiver chips that it supports. Deviation supports the CC2500 transceiver chip, so you could use the code there to drive a CC2500 and implement the FrSky ACCST protocol with the channel values provided by your code.

The code is for the STM32, so you'd need to do some porting to adapt it to Arduino, but it wouldn't surprise me if you can already find an Arduino library that will drive the CC2500 and implement ACCST with full telemetry if you use a CC2500 board that includes a PA and LNA.

That doesn't sound like a bad idea at all. Will check out that avenue. Thanks!