So I decided to monitor the cpu usage of ardupilot on my Navio2/ Pi 3+ using HTOP.
I decided to also activate sudo systemctl run fpv to stream. I noticed that in some instances the CPU usage would be very minimal where the load is spread almost evenly over the 4 cpu’s. However I did noticed that at times the usage of CPU 1 will sit at almost 100 percent when running the systemctl service while the other cores doing almost nothing. So the question is.
How is the Navio 2 image programmed to use the cpu on the Raspberry pi? Is is supposed to use all 4 or only 1 at a time?
In general, a process (or program) will only run on 1 cpu unless it is capable of multithreading. If so then it can use multiple cpus. Some are, some aren’t.
Then there are rules which can restrict certain processes to certain cpus (affinity).
So if you have a critical guidance process running at 50% cpu and then say there is a multithreading image processing task to do which is encodes to h.264 for broadcast and will use 100% of all available cpus. That could choke out the guidance process and cause real trouble. So the solution is dedicate cpus based on the jobs you want them to perform. That way you can run some non-critical processes at 100% on some cpus and leave the crititical processes running at 50% of a different cpu.
The other way to deal with it is the “nice” value.
The more “nice” a processes the more it lets other processes go ahead of them. The less “nice” a process is, the more it hogs the cpu(s) for itself.
So I don’t know what is happening on your Pi specifically, but it is safe to say that to seeing a process hogging a single cpu and keeping it pegged at 100% is pretty normal.
If you want to make your 4 cpus busy, try running these 4 processes: while true; do true; done & while true; do true; done & while true; do true; done & while true; do true; done &
But make sure you know how to kill the processes when you are done (or just reboot).
It will demonstrate that the tasks will be spread to different cpus to even out the load.
The reason I am looking at this is that in the past I have had multiple crashed drones where the drone will be flying and then all of a sudden everything will just go dead. This happened on 2 different Navios and 2 different pi’s.
So I am trying to figure out if this could be caused by the CPU being over burdened by something
I don’t know what log files are available, but that is where I would start whether it is a drone crash or a computer crash.
/var/log/syslog is the typical place for the system log. Take a copy of that (or the whole /var/log/ directory) after a crash.
Then there will be ardupilot logs to look at too and they will probably have the information you should look at first.
If the system log just ends without even a kernel panic message, then you might be chasing a power failure. I think the Pi has temp sensors, so if it was an overheat, then that should be in the system log.
It is like taking your car to the mechanic and saying it didn’t start the other day, but it starts fine now. Can you fix it? A mechanic might go two ways. The first is, “Bring it back to me when it doesn’t start.” The second is, “Sure. We’ll install a few new parts. If it happens again, we’ll install some other new parts.” There’s no really good answer there.
So if it becomes a repeatable thing (I hope not). I suppose you could attach a logger of some kind. Either voltage or a serial port logger (to capture the CPU usage if you think that could be an issue).
The Navio 2 is a very very sensitive device. It will fly nice one minute and the next it will have compass issues. Mine was flying very nice the other day and on the next flight it started to fish bowel which gradually became worse untill it toppled over.
Navio2 is a highly customizable device. The variety of its use-cases influences the setup complexity.
There are a lot of factors that can affect Navio2 performance, that’s why the appropriate hardware setup is so essential.
Usually, it’s quite hard to figure out what might go wrong without observing logs, hardware setup photos, current configurations and actions performed. Moreover, even if this information is provided, it’s easy to overlook something.
