CPU usage

Navio / Edge Hardware
1

How many % of the RPi/RPi2 CPU does APM with Navio+ use during a quacdopter flight? I would like to do other possibly real-time tasks on the RPi CPU so the question is how much power is left for custom processing…

I am also curious about process priority on the real-time kernel… I guess APM will have the highest priority on the Linux machine? Will the CPU drain be different in various APM modes (rover, quadcopter, plane) since rover may not need to watch as many sensors as quad for example? Do you have some CPU usage statistics?

2

Numbers vary depending on Raspberry Pi version and overclocking settings. ArduCopter takes 30-40% (that’s for one core), ArduRover is around 10-20%. Plus 20-30% for RCInput (pigpio) for any vehicle. So, there’s plenty of resources left on RPi2.

SCHED_FIFO priorities are in that order:
99 - important Linux things such as watchdogs
51 - interrupt handlers
10-15 - APM
All other processes in the system are usually run with default scheduler thus they have the lowest priority.

3

The load generated by the RC input seems to me a good argument for a digital/serial RC input in the long term. I guess all this power is spent sampling the PPM signal at a high rate. Correct?

4

@mikhailavkhimenia

So these numbers are for a single core (either on RPi1 or RPi2), right? So there should be 3 cores close to 0% usage on RPi2, right?. There actually is not “plenty” of resources left even on RPi2 for me since I want to do computer vision on it. I most likely will be able to downscale my CV application in terms of image resolution requirements and still have it work reasonably well but I would like to be as effective as possible.

5

@mfm Yes, that’s correct. PPM does not really fit digital world. Something like SBUS should be better (but it has a couple of its own caveats).

@kozuch Yes, ~75-85% of CPU resources (summary) are free. That sounds plenty to me.

6

@mikhail.avkhimenia

I always wondered why FrSky doesn’t put out a reciever with a standard TTL UART interface as their customer share in the multicopter area seems to be pretty high. Would be probably just a firmware change required for their recievers with telemetry support.

I’m probably gonna look into using one of the 35 MHz ACT-DSL recievers I still have when I receive my Navio. They have a TTL UART for their satellite system. UAVP NG has a implementation of their reverse engineered protocol. https://pub.uavp.ch/svn/releases/ngos-0.67-src/sources/ngos-rcc/rc-dsl.c