Looks like everything is working well. I obviously haven’t flown yet. I just launched ArduCopter sending telemetry over wifi to Mission Planner, and it looks like I am getting all sensor data properly.
We also now have a newer kernel:
pi@navio:~ $ uname -a
Linux navio 4.1.6-v7+ #2 SMP PREEMPT Thu Jan 28 19:58:25 MSK 2016 armv7l GNU/Linux
Here’s what cpu usage looks like on the rpi2:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 886 root -13 0 46376 44908 3500 S 49.0 4.8 4:50.78 ArduCopter-hexa 145 root 20 0 0 0 0 S 7.6 0.0 0:43.36 spi0 179 root 20 0 0 0 0 D 5.9 0.0 0:47.85 rcio_worker 150 root 20 0 0 0 0 S 1.3 0.0 0:10.95 spi1 906 pi 20 0 5092 2508 2160 R 1.0 0.3 0:04.46 top 51 root 20 0 0 0 0 S 0.3 0.0 0:00.10 kworker/u8:1 636 ntp 20 0 5664 3828 3396 S 0.3 0.4 0:00.31 ntpd
I am not seeing the 15-20% cpu usage cause by the irq storm of the old dwc_otg usb driver. I wonder how you managed that!
When I issue the wget command from the rpi2 image instructions above, the apm-navio2.deb file being downloaded to my Navio2 is only 9,48KB/s. the apm-navio2 file in the download link is much larger so I know something inst right. What could I be doing wrong?
Im also experiencing the same sorts of speeds trying to download the rpi2 image. At this rate its going to take me more than a day. Maybe someone who has already downloaded it might be able to mirror (for now) the file on dropbox, or somewhere similar?
Any chance we can get this image working on the older Navios?
Even if it’s not possible to detect the old Navio chipset (HAT EEPROM?) maybe you coild still keep one RT build and add the old drivers blacklisted in the modules path plus a simple batch script which enables the older hardware.
Then you have only to maintain one kernel branch and the older customers have a greater chance they can keep up to date with newer kernels into the future.
Then main point of concern are the newer C libraries which are only built-in the newer kernels. So long as Navio+ only has the original RT build we have to resort to complex recompilation/back-porting or switch to the unstable package source.
The source code will be available in a day or two. Sorry for the delay.
Anyhow, I wouldn’t recommend fly off the master branch and hence pr/navio2, because it hasn’t been tested properly. We recommend to use only stable releases.
Sorry, I’m still not clear on whether EMLID intend to make an image available for older Navio or not?
If not, that’s OK just as long as it’s possible to build an updated system from source.
You see I have one of the earlier Navio board supplied to backers of original IndieGoGo campaign …didn’t do anything with it until recently when I purchased an RPi2 and started building a quad with my son. I’ve been working on a Gentoo-based image and trying out different kernels, including EMLID ‘rpi-3.18.9-rt5’, in an attempt to resolve issues (reported both here and other forums) regarding RPi camera electrical interference and USB-attached cameras (i.e. trying to find optimal dwc_otg parameters that allow decent performance without hanging system).
I inspected new Navio2 image and see newer kernel 4.1.6 so would it be possible to use EMLID ‘rpi-4.1.6-spi1-enabled’ source to build kernel for original Navio or is this only applicable to Navio2?
From first post (above) from @pierig regarding “not seeing the 15-20% cpu usage case by the irq storm of the old dwc_otg usb driver” …I too am very curious to understand how/if that was resolved (newer kernel with patches?) so a stable platform (with decent video streaming performance) can be achieved?
Regarding video, I am not keen to pursue option where RPi camera and cable are shielded in any sort of foil as anecdotal evidence (and my own testing) suggests it does not completely resolve the issue - just reduces impact so judicious placement of GPS antenna, use of ground plane and/or other shielding is still required. USB-attached camera seemed like a solution but then had to deal with dwc_otg shenanigans and trying to find workable streaming software compatible with either qgroundcontrol or apmplanner2 (still a work in progress).