Help building Navio2 from Sources

I am trying to build APM from source code; following the page @

I am getting:

pi@navio:~/ardupilot/build/navio2/bin $ sudo ./arducopter-quad
pi@navio:~/ardupilot/build/navio2/bin $

I just jumps out right away.

pi@navio:~/ardupilot/build/navio2/bin $ sudo ArduCopter-quad
Raspberry Pi 2 with BCM2709!
Raspberry Pi 2 with BCM2709!

I am actually trying to get the APMrover2 to work but it is the same result.

I have also done

pi@navio:~ $ sudo chmod +x APMrover2.elf
pi@navio:~ $ sudo ./APMrover2.elf -A udp:
pi@navio:~ $ ls -l
total 8552
-rwxrwxr-x 1 pi pi 8752929 May 5 14:58 APMrover2.elf
drwxr-xr-x 16 pi pi 4096 May 5 15:46 ardupilot
pi@navio:~ $

Please contribute any ideas. I have been at this for…what day is it…a long time!!

I ran it with the gdb debugger and this is what I got…

root@navio:/home/pi/Ardupilot_Navio/ardupilot/APMrover2# gdb ./APMrover2.elf
GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright © 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and “show warranty” for details.
This GDB was configured as “arm-linux-gnueabihf”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from ./APMrover2.elf…done.
(gdb) run
Starting program: /home/pi/Ardupilot_Navio/ardupilot/APMrover2/APMrover2.elf
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/arm-linux-gnueabihf/”.

Program received signal SIGSEGV, Segmentation fault.
OpticalFlow::OpticalFlow (this=0xc58c0 <rover+4992>, ahrs=…)
at /home/pi/Ardupilot_Navio/ardupilot/libraries/AP_OpticalFlow/OpticalFlow.cpp:58
58 _last_update_ms(0)

and that line is :


Totally lost!!!

Don’t be shy… anyone can give a shout out…

OK, that’s the last line in the constructor’s initialisation list.

The line numbers can be significantly misleading in these cases.

Use gdb to poke objects and pointers used in the initialisation list. In particular, I’m looking at hal.i2c_mgr->get_device(HAL_OPTFLOW_PX4FLOW_I2C_BUS, HAL_OPTFLOW_PX4FLOW_I2C_ADDRESS) with great suspicion. Is i2c_mgr null?

Additionally, this should definitely be raised as an issue here: