Drone CAN Bus Power Schemes

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 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 IMHO not fit for the task: 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 current limited. Moreover, that 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 the current 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, that rail passes a BQ24315 protection IC with a current limit set to 1 A. This 5V-PERIPH rail in addition powers the peripherals on essentially all other ports, except of that on the Serial1 port, which is 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 that 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 fuses as protection. The CAN bus is connected to the 5V-PERIPH rail, which is protected by a 1 A fuse, very similar to the Pixhawks. The 5V-PERIPH rail powers all other peripherals, including that 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 a weaker fuse or so. So be warned that even this 1 A limit is not 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 conclusion is clear: These 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 scheme is 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 OPreoLEDs) 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-ORing 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 are the „artificial“ current limitations in the above 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 not.

Besides the current limitation of USB, 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 there would be sufficient current. To be clear, 5V CAN transceivers such as the TJA1051 are a GOOD thing! They help achieve a high robustness of the CAN bus network, and that’s 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 OereoLEDs. 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 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 current 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 the peripherals connected to the other ports. 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 the servo power rail. 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 to measure the voltage level). One needs to attach an external BEC to the OUT 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 an 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 5V BEC. In a systematic concept one should prefer a triple-power scheme however, which additionally distinguishes between CANbus and servo, in order to separate the CANbus network from 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 5V or the servo 5V (or a CANbus 5V in a triple scheme). Another one is the additional complexity that some CAN nodes are of dual-power nature themselves, as described in the previous section, and would want to be connected to both 5V sources.

Hinterlasse einen Kommentar