92 over the next 10-15 years as a greater proportion of uncrewed vehicles come with high voltage electric and hybrid drivetrains in need of less heavy, costly, and thermally burdensome DC/AC and DC/DC components. Firmware practices While ESC firmware is accessible and available online, such as BLHeli_S, Bluejay, and AM32, high-end manufacturers increasingly insist upon the necessity of engineering their own firmware inhouse, from the ground-up. The prime reason given is that the incredibly high switching speeds of UAV motor controllers mandate an extremely tight, holistic integration between software and hardware, particularly as UAVs increasingly start to move hundreds of kilowatts with nanosecond-scale switching intervals. Without that matching between software and hardware, the software may make demands either in excess – or falling short – of the hardware’s capabilities, potentially resulting in inefficiencies and latencies in operation, and hence insufficient switching speeds for the kinds of throttle response or vibration minimisation expected of today’s industrial UAVs. Alternately, the software might fail to account for correct slew rates – how much voltage or current gets changed per unit of time – by not sensing or responding to inputs accurately. In extreme cases, such a mismatch could trigger a fault so severe that the ESC overloads its capacitors and explodes mid-flight. Making one’s own firmware helps avoid these issues, and also minimises the chances that sporadic new protectionism barriers will not suddenly cut-off one’s access to ESC firmware simply because it came from a targeted overseas country. On top of those, it enables masses of testing data (and also possibly user data) to start informing the modelling of empirical analytics functions highly useful to end-users, such as AI detection of capacitor failures, motor saturations, and other drive errors. Those can then be plugged into customers’ GCSs, to record the errors in their flight logs, or flagged in their GCS interfaces in real-time as alerts or recommendations to abort flight and bring down the aircraft. With such capabilities potentially enhanced via the integration of sensors for real-time overvoltage, overcurrent, temperature and so on (particularly when installed across different sections of the board to pinpoint the exact location and cause of an electrical or thermal issue). And while high-end motor controllers and drives will experience such failures rarely over their 3000-4000 hour lifespans, such capabilities can be invaluable when building a safety case to be submitted for gaining flight approvals. Naturally, transmitting ESC and motor telemetry, as well as error messages, depends heavily on using effective communications protocols. Newer generations of motor controllers now widely use DroneCAN (formerly UAVCAN). DroneCAN enables extended telemetry and communication of diverse information sets for analysing (and thus optimising) drive safety and performance, not just in motor drives but also in servos and autopilots. With proliferation of the protocol in those other components of course making the transition more sensible and appealing for ESC manufacturers, thanks to the greater compatibility and hence adoption it creates among UAV subsystems. High-end manufacturers will also supply ESCs with other advanced, modern protocols, such as ARINC-825 CAN, which is more common in military applications. Like DroneCAN, ARINC-825 networks enable multiple subsystems to communicate quickly and efficiently over a single bus with low latency, allowing real-time control and monitoring of control surfaces, engine throttle, and e-motor drives. Furthermore, it has – again, like DroneCAN – been designed for decisive fault detection and isolation in its networks, as well as message prioritisation and ad hoc, over the air firmware scaling and updating – all more proficiently extent than the conventional CAN 2.0b. That ability to update networks and firmware modules as needed, via having a comms protocol structured to do so, saves copious time on having to redesign or reconfigure vehicles’ networks to accept such updates. It is imperative, however, that customers use their own flight controllers to define even the most plug-and-play ESCs within their networks, connecting and flashing them to particular configurations individually, as that ensures updates and reconfigurations are deployed from a central hub within the software architecture, minimising room for error and hence faults. April/May 2025 | Uncrewed Systems Technology Modern, UAV-specific comms protocols, as well as firmware engineered to spec in-house, are the key to capturing and analysing vital data on ESC health and performance (Image courtesy of Currawong)
RkJQdWJsaXNoZXIy MjI2Mzk4