Jetson Nano Shutdowns

Our company is using a Jetson Nano in a drone, however, during flight the Jetson keeps rebooting automatically.
This is a behaviour we don’t see in any ground tests. Is there some way to understand what is causing the Jetson to shut itself down?

Do you have a way of logging the output of “dmesg” up until a reboot? If you have enough disk space, then that would help. To get an example of the size of log file you might run this command after the unit has been running for a bit:
dmesg 2>&1 > log_dmesg.txt
(and then look at the size of log_dmesg.txt)

Usually, if not hitting some unusual software error (such as running out of memory), the problem is one of the power delivery not being sufficiently well regulated.

One form of power regulation not being high enough quality is if the same regulator output is used to power both the Jetson and some external load, e.g., flight control hardware or the electric motors for propulsion.

If the regulated output feeds only the Jetson, then perhaps the regulation needs improvement (Jetsons are sensitive to very short power spikes causing reboot or shutdown). An example of improving this without going to a completely new power supply would be to put a large capacitor right at the power delivery point, e.g., 2000uF.

Also, if you power via the barrel jack (assuming it is a dev kit), then your odds are improved yet again. USB power delivery is limited to USB standards, but the barrel connector is capable of providing more power delivery than USB power delivery is capable of.

Probably putting a large capacitor as close as possible to the power connector, and using the barrel jack, would be the best first test. Checking dmesg logs is a bit iffy since if shutdown is sufficiently sudden, then nothing will log (serial console does not generally have this issue, but getting a serial console log while in flight might be problematic if you don’t have a second computer capable of logging the serial UART).

Hi @linuxdev, i guess i should have added more detail to the top post.

Logging dmesg sounds like the right way forward at this point. When it comes to logging the serial console it may also be possible with the help of a zigbee module to provide remote telemetry of the data, which is something we’ll look into if dmesg doesn’t show anything.

As for power regulation issues, we are using a Jetson Nano on a custom carrier board integrated in the drone with a 5V 6A power supply, and the output voltage of this power supply is being monitored through flight and never left the 5.05 to 5.12 V range (regulated slightly above 5V on purpose), between the power supply and the Jetson we have 2 x 1000uF, 4 x 10uF and 8 x 0.1uF so i really hope power regulation isn’t the problem!

And how much current is drawn? Jetson Nano can draw up to 4A (~20W), leaving 2A for the rest of the the drone electronics and motor…

Motors are powered directly from the battery, as they consume up to 4 kW (180 A at 24V).
The 5V 6A power supply is dedicated solely to the Jetson Nano.

Your basic design seems good, but I want to emphasize that the power spikes which can cause reboot are far shorter than most equipment can measure. Voltage monitoring would probably require monitoring down into microseconds if you really want to be certain regulation is working. Your capacitor setup tends to say this is probably not the issue, but understand that the spikes which cause reboot are probably over too short of a time to actually guarantee this is not an issue (and power regulation is the most common cause of this issue on the forums, perhaps followed by running out of memory).

Do be certain that any EM noise generated by the large motors (and inductance) don’t have any indirect method of adding spikes to the Jetson’s power source.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.