Emlid team is happy to announce official support of Raspberry Pi 2 for Navio+.
From now on Raspberry Pi 2 Model B is the main platform for Navio+. With RPi2 it is possible to fly 400hz copters without missing a single cycle and we that it’s improved performance will allow to create truly sophisticated and advanced projects. Previous Raspberry Pi models are still supported. And we keep working on Odroid-C1 port (we are very close).
Raspberry Pi 2 SD card image with real-time kernel is available in the downloads:
We have also made our APM binaries universal - they work on all versions of Raspberries and all versions of Navios. Updated deb package includes binaries for all vehicle types - to install it follow the instructions in the docs.
Is the real-time kernel really that important? From the chart you post I get an impression that the difference in responsiveness is very very small - if I read the chart correctly it seems like there is only noticeable difference within 50-100 us area where the RT performs better. A rough calculation - 1M readings in total and in about 30*100=3000 cases there was few tenths of us longer delay… Can you elaborate on why exactly the RT is so important for autopilot?
It does not really show that something performs “better” at 50-100us area. That’s a histogram - it shows number of cycles (y) that took amount of time in us (x). For RT - the area is tighter and the values are smaller.
And the most important characteristic here is the max latency and for RT kernel it’s few times smaller. That allows autopilot to work with proper scheduling, otherwise cycles could be missed and that would affect flight behavior.
Difference in real-time performance of default 3.10-3.12 kernels and kernels with RT patch was huge.
With 3.18 the gap is smaller (as many parts of rt patch were included in the mainline), but full RT patch still performs better.
You are definitely right that this latest standard kernel (3.18?) has much closer RT performance than the previous standard kernels you tested.
That allows autopilot to work with proper scheduling, otherwise cycles could be missed and that would affect flight behavior… but full RT patch still performs better.
It would be interesting to try to test fly the standard 3.18 kernel… Have you actually tried it or are you willing to try it? In case that would work reasonably well you may save yourself some patching work ;). Maybe you will not need to patch the kernel at all in the near future… Remember that histogram has a log scale, from the statistical point of view the differences in 3.18 really look very very small…
However, it would be interesting to diff both charts to see the real histogram difference. You could also count an exact difference and say something like “the standard kernel has a 99,7 % performance of the RT kernel” or “the standard kernel is X ms slower than the RT for given number of tasks”. Maybe 99.7% (or whatever number would come out of the exact comparison) could be enough for a “standard pilot” to fly. Maybe not for a quadcopter racing or some acrobatics but OK for most people.
EDIT:
And the most important characteristic here is the max latency and for RT kernel it’s few times smaller.
I am not sure we understand each other. Yes, you are right with the max latencies of the std kernel being much longer. But the question is - in how many cases those “max” latencies occur? My point is that this number might be negligible for autopilot operation… I have no experience with quadcopters but I am just curious if you are not looking for a problem (std vs RT kernel) in a place where there is none.
It would be interesting to try to test fly the standard 3.18 kernel… Have you actually tried it or are you willing to try it? In case that would work reasonably well you may save yourself some patching work wink. Maybe you will not need to patch the kernel at all in the near future…
We tried. For the moment it works a little bit worse (much worse under a stress). It should probably be okay for planes and rovers, but 400hz copter is a different story. We don’t mind some patching work if it ensures better safety for users.
And yes, we probably won’t need the RT patch in future - when most of it’s important parts will be merged in a mainline kernel.
Remember that histogram has a log scale, from the statistical point of view the differences in 3.18 really look very very small…
Cyclictest is synthetic, and those numbers are just a relative real-time performance comparison. Real-time system cannot rely on “statistics”.
You could also count an exact difference and say something like “the standard kernel has a 99,7 % performance of the RT kernel” or “the standard kernel is X ms slower than the RT for given number of tasks”. Maybe 99.7% (or whatever number would come out of the exact comparison) could be enough for a “standard pilot” to fly.
Well, that’s the fundamental difference between real-time OS and general purpose OS. If the system provides you proper latency only in 99,7% then it’s not a real-time system.
Yes, you are right with the max latencies of the std kernel being much longer. But the question is - in how many cases those “max” latencies occur?
Even a single delay matters.
I have no experience with quadcopters but I am just curious if you are not looking for a problem (std vs RT kernel) in a place where there is none.
There is no problem. Why should we choose standard kernel with lower real-time performance when we can use the RT kernel?
I tried to download the latest binaries to use with the realtime os on raspberry pi 2 and it doesn’t seem to include APMrover2.elf, is that something that will be added later?
I then tried building it on the pi2 with the latest navio branch and am having some issues. My APMrover2 build loads but never seems to arm, the LED stays purple on the Navio+. Any suggestion on where I may be messing up the build process? Does the latest navio branch on github provide universal raspberry pi support?
There’s no APMrover2.elf in the package since in Linux binaries usually have no extensions an thus the binary is called simply APMrover2. Could you please try the deb package again and connect from the APM Planner? Does it show any errors?
Hi!
I hope this is the right place to ask.
I tried to run navio-rpi on my rpi2 in both ways:
(1) used the ready-to-go-image for rpi2
(2) used the newest raspbian software and substituted the kernel and overlays as described in github
Both ways it starts right away but I get no device-tree :-/
The debug log says: "No kernel trailer (run mkknlimg to fix) - assuming not DT-capable"
Can anybody help? Sounds like there is something missing?
when I chage kernel7.img file back to original, device-tree is there again.
Yes, I have done as you say. I double-checked today and it is just the same thing: system falls back to none-device-tree.
Do you have one in your system or do you work without?
I wonder why the problem occurs in both ways.
I found out because I use the bcm2835-lib by Mike McCauley that checks for a file named “ranges” in the device-tree and if it is not there, it uses the old peripheral base addresses of rpi.
The “No kernel trailer”-message is still in the debug log but I get my
/proc/device-tree and the
/sys/firmware/devicetree/base/soc/ranges file
so I can use the lib as is
Thank you for real time and hints! Cannot wait to do some tests
im using rpi b and installed your real time kernel. when i tried to login as root it said invalid password. And connecting via ssh doesnt working either, (i tried connecting with pi raspberry)
