Can the flight controller of cheap "toy" grade quads, such as the Blade Inductrix, be programmed at all? I'd assume that even if it's possible, it wouldn't be practical. I don't have any experience with FC programming (yet).



Probably, but you'd likely be spending a lot of time locating a programming interface on the flight controller board and custom-compiling or custom-writing firmware to work on the special board configuration.

Some more expensive toy-grade drones may have accompanying smartphone apps that allow you to change some flight parameters, but very few of those exist for a variety of reasons.

In general, I wouldn't recommend trying to modify the firmware of cheap toy-grade drones... 😉 It's almost certainly a better use of your time and money to begin tinkering with DIY drone parts that are meant to be tweaked.

In the case of the OP's example toy drone, the Blade Inductrix FPV RTF, there is some limited good news. From looking at this image of the FC board, it can be discerned that the FC uses an off-the-shelf Atmel processor of some kind:

enter image description here

I've tried rotating and zooming the image to find what exact model the chip is, but the image is too coarse to read the finer print. The fact that it uses an Atmel processor means that you could probably use a UART/ISP programmer device to upload new code once you locate and solder thin wires to the appropriate legs of the LQFP package. However, you'd likely run into other challenges when trying to modify or change the existing firmware:

  • Attempting to de-compile the firmware on the FC to change PID constants or alike would be exceedingly difficult
  • The Atmel chip is likely 8-bit, which would require adaptation of open-source FC firmware like Betaflight to work (Betaflight is designed to work with STM32/ARM 32-bit processors)
  • The Atmel chip is almost certainly running at a slower clock speed and has less IPC capability than the chips used for DIY FPV drones and would require firmware with severely slimmed-down feature sets
  • The pinout of the FC board is entirely unknown; you'd have to manually trace out the circuit to find which pins on the processor lead to what parts of the drone, or locate a schematic
  • Critical peripherals like the IMU (accelerometers + gyroscopes), ESCs/H-bridges, RC RX, and FPV TX are likely non-standard components communicating with custom proprietary (or at least unknown) protocols that would require reverse-engineering
  • etc.
| improve this answer | |
  • $\begingroup$ Unfortunately, there's a lot of speculation here, much of which turns out not to be very reflective of the actual truth of common situations. $\endgroup$ – Chris Stratton Aug 9 at 16:25

Reprogramming toy-drone flight controllers which are based on readily recognizable microcontrollers is definitely "a thing", heavily benefiting from a few open source projects, one of the most popular being "Silverware" which has now become a whole family of repositories on github and years-long history of threads in places like rcgroups.

While in theory this could be done for the E-flight/Blade flight controllers (there exist open source firmwares for ATmega processors less powerful than the related XMega E-flight uses), in practice they tend not to be targets, because they are fairly expensive and relatively usable in stock configuration. Rather, efforts concentrate on the very low-end ultra-micros, where a flight controller or whole aircraft tends to cost $8-25, as that minimizes risk, and maximizes the reward in getting serious capabilities out of a "cheap toy". So you see a lot more of this going on with the inductrix-like "tinywhoop" platforms, than with the actual Induxtrix. The low price also typically means someone pioneering a new port of an open source control software can keep one board with stock firmware for reference while iterating experimental code on another.

Sometimes the target is simply the toy's flight controller board and not its airframe at all, eg, people having taken FC's intended to drive brushed pager motors, and after replacing the firmware wired them to the control signals of brushless ESC's on slightly larger aircraft, though typically still in the micro class.

Some of the key facts and techniques that make this possible include:

  • Weight and budget concerns prompt almost universal use of 2-layer circuit boards which are easy to visually trace under moderate magnification.

  • The past and not entirely extinct tendency to use readily recognized and reprogrammable microcontrollers, especially the STM32 series and its work-alikes from GigaDevices. These have a 2-wire "SWD" programming interface which can typically be found on pads on a board, and even where not, with care it's possible to solder fine wires even to the side metalizations of a QFN package. It also doesn't hurt that some of the STM32's turn out to actually have twice as much flash memory as they are supposed to. Or that in most cases one of the SWD pins can be re-purposed as a serial UART, allowing experimental code to create debug output (channelling debug messages through SWD is also an option). Some of these MCUs also have flash security bugs which permit the original firmware to be backed up and restored; but decompilation is not really of any interest or benefit. That said, MCU's unkown in the west are starting to show up in toys, and especially where they integrate the radio this does limit reverse engineering and firmware replacement.

  • $10 logic analyzers based on the CY7C68013A chip are excellent tools for examining SPI or I2C communication between a processor and a yet-unidentified radio or sensor chip. I2C busses in particular are readily recognized by the pair of surface mount pull-up resistors, which make a great place to solder debug leads.

  • 2.4 GHz radio chips are limited in number and mostly known by the community. There are a few unique designs (eg, the Cypress stuff DSM uses) and the A7105 and then a lot of various clones and semi-compatibles of the nRF24L01+, of which the "backwards bit order" XN297 is probably the most famous. These can typically be visually recognized, and there's already widespread knowledge of how to operate them from a replacement firmware. While entirely possible by studying logic analyzer captures, often it's not necessary (or even desirable) to re-implement the toy's original air protocol, but rather preferable to implement one supported by the modifier's available hobby-grade transmitter - not infrequently, being able to use a hobby TX is a main point of putting a custom firmware on it.

  • MEMS Gryo/Accelerometer chips are also limited in number. While toys tend to feature chips with markings which which "don't exist" in the public catalog of the well-known makers, in practice examination of I2C bus traces tends to indicate that they are minor variations of parts with public data sheets. Worst case, a re-implementor just sends the same setup sequences, and then performs the same repeating data query. Tilting and twisting the drone with the logic analyzer hooked up and watching the live data display readily distinguishes which bitfields of the response encode which motion parameter. PID tuning tends to be manually iterative, so there's no real need to put any actual "numbers" on the anything, just to distinguish the three acceleration and rotation axis and their format and sign.

  • Motor drivers are dead simple - FETs are readily recognized (and sometimes replaced with higher-spec versions). A few drones with inverted flight capability have more complex H-bridge drive, but again this is not hard to figure out. One cheap tiny platform had an odd set of connections running from the switched motor lead through a resistive divder to MCU ADC pins; it turned out that these were back-EMF monitors to detect spinning vs. blocked propellers during the PWM off time.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.