Building for BeagleBone Blue

Hardware Linux
1

I can’t find any description here how to build AP for BeagleBone Blue:

https://ardupilot.org/dev/docs/building-for-beaglebone-black-on-linux.html

It is provided for BB Black and BBBMini (the site is not responding). But it should be different for Blue?

EDIT:

I’ve found a manual:

I’ve started to compile for the latest AP version:

./waf configure --board=blue
./waf copter

but I get an error:

…/…/libraries/AP_GPS/AP_GPS.cpp: In member function ‘void AP_GPS::send_mavlink_gps_raw(mavlink_channel_t)’:
…/…/libraries/AP_GPS/AP_GPS.cpp:1005:10: error: too few arguments to function ‘void mavlink_msg_gps_raw_int_send(mavlink_channel_t, uint64_t, uint8_t, int32_t, int32_t, int32_t, uint16_t, uint16_t, uint16_t, uint16_t, uint8_t, int32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint16_t)’
1005 | 0); // TODO one-sigma heading accuracy standard deviation

2

You need to get latest ArduPilot build and make sure you update recursively
git checkout master
git submodule update --init --recursive

1 Like
3

OK, it worked on a fresh checkout, thanks!

Is there any documentation how to add an external sensor, for example another barometer or IMU? Add a module to the linux kernel, and then call the code from the ardupilot?

4

The external device has to be on the scanning list an not conflicting with internal devices and bus

Here is the definition file for Linux boards

5

Hi from Bolton-est, Québec!
Paul, to not interfere is to have different pin numbers for each variable right?
Ex.: I want to had voltage sensing to BBlue, I then add this line
#define …VOLTAGE_PIN 1
to the linux_blue elif?
And I can follow the BBlue git page for the pin numbers?

Thank you so much, your comments got me to a working hexa.

6

Salut

The mapping is already built in ArduPilot, Have you looked at the code or you are trying something else ?

As for the pins assignation they are generally mapped in the DTB that is in the boot files but it can be done now from user space using the Config-pin utility.

There is still come action on the BBBMINI gitter page, you can ask for more info

Patrick

7

Trying to build on macos 10.14, I did:
git checkout master
git submodule update --init --recursive
./waf configure --board=blue

which doesn’t work with the arm-linux-gnueabi toolchain (can’t find g++, gcc even if they are found in /usr/local/bin and this path is in my PATH).

So I tried with arm-none-eabi:
./waf configure --board=blue --toolchain=arm-none-eabi

which configured succesfully, but the build doesn’t.
When running:
./waf

I get the error:

[ 85/1203] Compiling libraries/AP_Compass/AP_Compass_HMC5843.cpp
…/…/libraries/AP_Compass/AP_Compass_IST8310.cpp: In member function ‘bool AP_Compass_IST8310::init()’:
…/…/libraries/AP_Compass/AP_Compass_IST8310.cpp:161:36: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘uint32_t’ {aka ‘long unsigned int’} [-Werror=format=]
161 | printf("%s found on bus %u id %u address 0x%02x\n", name,
| ~^
| |
| unsigned int
| %lu
162 | _dev->bus_num(), _dev->get_bus_id(), _dev->get_bus_address());
| ~~~~~~~~~~~~~~~~~~
| |
| uint32_t {aka long unsigned int}
compilation terminated due to -Wfatal-errors.
cc1plus: some warnings being treated as errors

…/…/libraries/AP_Compass/AP_Compass_IST8308.cpp: In member function ‘bool AP_Compass_IST8308::init()’:
…/…/libraries/AP_Compass/AP_Compass_IST8308.cpp:168:36: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘uint32_t’ {aka ‘long unsigned int’} [-Werror=format=]
168 | printf("%s found on bus %u id %u address 0x%02x\n", name,
| ~^
| |
| unsigned int
| %lu
169 | _dev->bus_num(), _dev->get_bus_id(), _dev->get_bus_address());
| ~~~~~~~~~~~~~~~~~~
| |
| uint32_t {aka long unsigned int}
compilation terminated due to -Wfatal-errors.
cc1plus: some warnings being treated as errors

Waf: Leaving directory `/Users/admin/git/ardupilot/build/blue’
Build failed
-> task in ‘objs/AP_Compass’ failed (exit status 1):
{task 4472811840: cxx AP_Compass_IST8310.cpp -> AP_Compass_IST8310.cpp.0.o}
(run with -v to display more information)
-> task in ‘objs/AP_Compass’ failed (exit status 1):
{task 4472811720: cxx AP_Compass_IST8308.cpp -> AP_Compass_IST8308.cpp.0.o}
(run with -v to display more information)

Should I be able to build with arm-none? I’m following Imfatant’s walkthrough, though I’m using bone-debian-9.13-console-armhf-2020-09-07-1gb.img

8

I am trying to build a TriCopter with with BBBlue. I am assuming that the this vehicle type is compatible with BBBlue. I am following the instructions from @imfatant. I see that the version of debian in his instructions is not available any more - so am proceeding with the latest version. I wanted to know if the BBBlue PRU programming is left to the user - or it is included in the build process as described by @imfatant.

I am have zero/no experience with TI PRU coding - and I wanted to make sure that I understand what I am signing up for when attempting to build TriCopter+BBBlue !

9

Hi

You can use the a more updated version of Linux for beagle bone .
The pru is out of the box

10

Thanks @juvinski. PRU is out of the box for BBBlue Debian release or the ArduPilot (Copter>=4.0) build? I was trying to understand where the codebase for the PRU firmware and HAL is located, but could not find it in the Copter-4.0 branch. Any pointers where I could start?

11

I want to understand how the PREEMPT_RT kernel patch interfaces with the PRU firmware running on the two cores on BBBlue. I think this applies to all BeagleBone hardware. Does anyone have a pointer where I can start looking to understand this?

12

The PRU code is in ardupilot:

13

The main idea of PRU is to be independent of the main processor, so the SO on the main processor will not interfere in the code inside the PRU.
The question of why we use just 1 PRU instead 2 is because the pinmux - for instence, almost all sensors on BBBMINI is using pins on P9 header where sit the PRU0, and PRU1 was used to output the PWM signals.
on PocketBeagle there is just 1 PRU and on BBBlue the encoders use PRU0 and the outputs PRU1.

14

That is incorrect. The PocketBeagle has the exact same SoC as the BBB and BBBlue, hence consequently the exact same PRU subsystem with two PRU cores. And though the PocketBeagle has much more limited pinout, it still includes a fair number of direct I/O pins from both PRU cores, as well as PRU subsystem peripherals (uart, ecap, iep):

P2.29                     pru ecap in/out
P1.36   pru 0 in/out  0
P1.33   pru 0 in/out  1
P2.32   pru 0 in/out  2
P2.30   pru 0 in/out  3
P1.31   pru 0 in/out  4
P2.34   pru 0 in/out  5
P2.28   pru 0 in/out  6
P1.29   pru 0 in/out  7
P2.22   pru 0 in     14
P2.24   pru 0    out 14
P2.18   pru 0 in     15   pru ecap in/out
P2.33   pru 0    out 15
P1.20   pru 0 in     16
P2.09   pru 0 in     16                        pru uart txd out
P2.27                     pru edc sync 0 out
P2.25                     pru edc sync 1 out
P1.26                     pru edc latch 0 in   pru uart cts in
P1.28                     pru edc latch 1 in   pru uart rts out
P1.08                     pru edio sof out     pru uart cts in
P1.10                     pru edio latch in    pru uart rts out
P1.12                     pru edio in/out 0    pru uart rxd in
P1.06                     pru edio in/out 1    pru uart txd out
P2.35   pru 1 in/out  8   pru edio in/out 2
P1.02   pru 1 in/out  9   pru edio in/out 3
P1.35   pru 1 in/out 10   pru edio in/out 4
P1.04   pru 1 in/out 11   pru edio in/out 5
P1.32   pru 1 in/out 14
P1.30   pru 1 in/out 15
P2.31   pru 1 in     16
P2.11   pru 1 in     16                        pru uart rxd in
2 Likes