Work in progress!
In this article I will evaluate the power supply for drones using a CAN bus as communication backbone.
The system I consider is a drone with a Pixhawk-type flight controller, which uses the CAN bus for communication with peripherals (CAN nodes) such as GPSes, magnetometers, ESCs, and so on. The considerations should however apply more generally. Also, I of course look at the situation only from a hobbyists perspective, and specifically have the UAVCAN for Hobbyists (UC4H) project in mind. Redundancy, power backup, 12 V CAN bus, and other such ‚crazy‘ things will not be relevant here. A typical drone will have one battery with one 5.3 V power brick and one flight controller.
One of the issues with using many CAN nodes on such a system is their proper powering. Well, it’s actually not an issue in the sense that there would be any rocket science involved. It’s an issue (only) because essentially all currently available flight controllers with CAN ports, such as the Pixhawk 1, Pixhawk 2/Cube, Pixracer, AUAV X2.1, and many others, are not really fit for the task, i.e., their CAN bus power options were not well designed.
The basic issue is that the CAN-5V available on these flight controllers is derived from a main 5 V power source (the power brick), but in addition is current limited. Moreover, this current limit includes all other peripherals, i.e., also those not on the CAN bus (except of maybe that on Serial1).
So, let’s look at some flight controllers in chapter 1, draw some conclusion in chapter 2, and discuss power schemes in chapter 3.
1. Pixhawk-Type Flight Controller Power Schemes
Pixhawk 1
The power scheme consists of a LTC4417 power switch, which selects among the various inputs (power brick, servo, USB plug), and distributes it to the various consumers (5V-HIPOWER, 5V-PERIPH). The CAN bus is powered from the 5V-PERIPH rail. However, this rail passes a BQ24315 protection IC with a current limit set to 1 A. This 5V-PERIPH rail also powers the peripherals on essentially all other ports, except of those on the Serial1 port, which are powered by 5V-HIPOWER.
source: github.com/PX4/Hardware
Pixhawk 2, Cube
The power scheme is essentially identical to that of the Pixhawk 1, except that the electronics is distributed among different PCBs. The crucial parts, namely the LTC4417 power switch and the BQ24315 protection ICs, are located on the PSM. As for the Pixhawk 1, the CAN bus is powered from the 5V-PERIPH rail, which is current limited to 1 A, and which also powers essentially all other peripherals except those on Serial1.
The same PSM module or scheme is found in all cube-based flight control systems I know of, which implies that everything which is going to be concluded further below applies to them too.
sources: github.com/PX4/Hardware/tree/master/PSMv3_REV_C, github.com/PX4/Hardware/tree/master/FMUv3_REV_D, github.com/3drobotics/Pixhawk_OS_Hardware, github.com/proficnc/The-Cube
Pixracer
The Pixracer has the most primitive power scheme. It consists of a diode OR-ing as power switch, and resetable fuses for protection. The CAN bus is connected to the 5V-PERIPH rail, which is protected by a 1 A fuse, very similar to the Pixhawk 1 and Cube. The 5V-PERIPH rail powers all other peripherals, including those on Serial1.
The latter is problematic, since usually the telemetry is connected to Serial1 which can draw a substantial amount of power. Thus, here the 1 A current limit includes also the power hungry telemetry.
Also the diode OR-ing is problematic. It reduces the voltages by several 0.1 V, which can easily bring the 5V-PERIPH voltage below the under-voltage cutout level of the TJA1051T CAN transceiver. This can happen especially then the system is connected to only the USB plug. When the under-voltage cutout happens, the TJA1051 disconnects from CANL and CANH, and the Pixracer cannot communicate with the CAN bus anymore.
I’d like to finally add that with my Pixracer, which admittedly is from an Asian source, it is illusive to draw 1 A from the CAN bus. I don’t know the reason, maybe it has a weaker fuse or so. So, be warned that even this 1 A limit may not be reached by your Pixracer.
source: github.com/ArduPilot/Schematics/tree/master/mRobotics
AUAV X2.1
The power scheme of the AUAV X2.1 is better (sadly it is not over-voltage protected). The input power switch is realized by a diode OR-ing using LTC4415 ideal diodes, and the power distribution is realized by the TPS2062 power switch, which has an internal current limit of typically 1.5 A (according to the data sheet the actual limit can vary). Unfortunately, also Serial1 is powered by this rail. Thus, the 1.5 A limit includes also the significant current draw of the telemetry.
source: github.com/ArduPilot/Schematics/tree/master/mRobotics
Summary
The power schemes of the flight controllers discussed in the above can be roughly summarized as in the following sketch (it should be understood that the different flight controllers do vary in the details):
The conclusion is clear: The considered flight controllers do provide only a limited current to the CAN bus network, and if that limit is exceeded all CAN nodes will be powered off.
You don’t want this to happen on a flying vehicle, as it necessarily will bring down the vehicle. The employed power schemes are surely fine for as long as the CAN bus nodes do not consume much power, but with a growing network and more features it easily becomes a bottleneck. This point was in fact quickly reached by the UC4H project, as it added more and more nodes, including some which require substantial power such as LED lightning nodes (UC4H OreoLEDs) or rangefinder nodes (UC4H RangeFinder).
I’d like to finish this chapter with mentioning that any CAN power scheme involves some sort of a current limitation, and if it’s the power supply used to provide the main power. Also any power distribution scheme has inherent current limitations. E.g., Schottky diodes in diode OR-ing schemes have a current rating, FETs in ideal-diode schemes have a current rating, and so on and forth. This should be all clear, and is obviously not the topic here. The topic here is the „artificial“ current limitation in the above power schemes.
2. CAN Node Classification
The CAN nodes can be broadly classified as follows:
- low power vs high power
- flight critical vs non flight critical
- USB available vs non USB available
The first two points should be self explaining, the third probably less so. Let me go through them in reverse order:
USB available vs non USB available: For maintenance or on the ground it is often more convenient to power the system by just plugging in a USB cable, and not having to also plug in the battery. Examples would be parameter setting, magnetometer calibration, check of function, and so on and forth. However, USB doesn’t (usually) deliver much current, and it therefore makes sense to distinguish the nodes by whether they should be available when only the USB is connected, or not. A GPS or magnetometer e.g. should probably fall into the first category, the LEDs of a lightning system probably in the second.
Besides the USB’s current limitation, there is also a voltage level issue. Some CAN transceivers such as the TJA1051 (a Dronecode recommendation) have an under-voltage protection mechanism, with a cutout voltage level of ca 4.7 V. The USB may not deliver that voltage, especially under load, with the effect that CAN nodes may go offline when powered by USB even if the USB would provide sufficient current. To be clear, 5 V 3rd-generation CAN transceivers such as the TJA1051 are a GOOD thing! They help in achieving a high robustness of the CAN bus network, and that’s why they were developed in the first place and why they are my favorite CAN transceivers. They however have the mentioned implication for a USB powered CAN bus network.
Flight critical vs non flight critical : Well, this is really obvious, no further words.
Low power vs high power: This also appears obvious, but in fact deserves few words. Many CAN nodes can be separated into a high-power and a low-power section. A typical example would be a UAVCAN ESC or the UC4H OreoLEDs. Here the low-power section consists of a microcontroller, which in addition to the main task is also handling the CAN bus communication. The high-power section consists of the FETs and motor in case of the ESC and bright, power-hungry LEDs in case of the OreoLEDs. For such nodes, which formally are high-power since they consume lots of power in normal operation, it would be convenient if they could be operated in a mode where only the low-power section would be active, and the high-power section not be powered. This would allow e.g. configuration of the nodes without having to draw the full current. You certainly will note that this mode of operation is quite common for ESCs: Many of them can be configured without having to connect a battery, but by simply supplying a 5 V source. The point of this paragraph is to point out that similar situations exist for CAN nodes too. Thus, in short, for some CAN nodes it would be convenient if they would be supplied from two power lines, a low-power and a high-power line, where the low-power line would be for operating e.g. the node’s main microcontroller.
The perfect power scheme would, in case of any issue, stop powering non-flight critical nodes first, and preferably would start with taking the non-critical high-power nodes offline, but keep flight-critical nodes powered under all circumstances. This would, obviously, require some sophisticated power supervising and protection electronics. This is not what this article is going to deliver.
However, it is certainly possible to significantly improve the situation over the default of just connecting all CAN nodes to the flight controller’s CAN bus, by relatively simple means. It’s mostly about being aware of the issue, and taking the appropriate steps, within the possibilities of the specific drone at hand.
So, the article’s purpose is to raise the awareness of this point, that the flight controller’s CAN bus power supply can be limited, and suggest some few typical and simple power schemes. It also could be seen as a reminder to the flight controller designers to come up with better designs (and not just cheap tweaks at best).
3. Power Schemes
As discussed before, we talk about current consumption, and how to best make each CAN node happy.
It is thus obvious, that if the power consumption of all attached CAN nodes is low, there is no issue at all, and one just can connect them all to the CAN bus port(s) of the flight controller. You are reminded that „low“ depends on the chosen flight controller and also the peripherals connected to the other ports, see the discussion in chapter 1. So, a general statement like „below X.X A“ cannot be made. As an indication, I would think that a GPS and a magnetometer and ESCs should normally be no problem.
I started to think about the CAN bus power like a servo power rail, since here too one has similar points to consider. To address them, today’s flight controllers have very systematically separated out the servo power rail from the powering of the flight controller and the peripherals attached to it. For instance, the row of 5 V pins on the MAIN OUT and AUX OUT pin header on a Pixhawk has no connection to the flight controller and its attached peripherals (except for a sensor line for measuring the voltage level). One in fact needs to attach an external BEC to the OUT 5 V pin header in order to power components connected to the servo outputs.
So, the flight controllers do in fact already implement a dual-power scheme for distinguishing between peripherals such a magnetometers, GPSes, barometers and so on, and components such as ESCs, servos, landing gear, and so on.
What is missing is a similar extension of the scheme to also include CAN nodes. Conceptually, it’s actually very simple, since the dual-power scheme is already existing. Low-power CAN nodes could go to the flight controller’s 5V line, and low-power CAN nodes could go to the servo power rail, normally sourced from an external 5 V BEC. In a systematic concept one would prefer a triple-power scheme however, which additionally distinguishes between the CAN bus and servo power, in order to separate the CAN bus network from e.g. servo power surge spikes.
This proposal would, conceptually-wise, solve many issues – except of some inconveniences: One of them is simply that the connectors and connector arrangements of today’s flight controllers do not nicely support powering a CAN node either from the flight controller’s 5 V or the servo 5 V (or a CAN bus 5 V in a triple scheme). Another is the additional complexity that some CAN nodes are of dual-power nature themselves and would want to be connected to both 5 V sources, as described in the previous chapter 2.
Thus, with the given flight controllers, the next best approach would be to directly power all CAN nodes from the 5.3 V powerbrick itself. This approach assures that all CAN nodes get sufficient power, and voltage, and is thus most reliable. It can be easily achieved by not connecting the CAN-5V line to the flight controller, but to the powerbrick. The disadvantage of this scheme is that none of the nodes would be available when powered from USB only, i.e., a battery has to be attached also for e.g. maintenance work. Yet, given its simplicity and simple realization it might be the best option available for achieving a robust power scheme.
An obvious extension is to split the CAN-5V power line, such that some CAN nodes are powered from the flight controller’s CAN-5V line, and some others from the 5.3 V powerbrick. The scheme can obviously be further extended by wiring both flight controller’s CAN-5V line and 5.3 V powerbrick to those nodes which would prefer a dual-power scheme. All this can be achieved easily in a DIY manner, but not conveniently, since the presently used connectors and presently available CAN bus extensions do not support such schemes.
