BeagleBone Blue & ArduPilot Blue - Real-time kernel, etc

ArduCopter Copter 3.5
1

Date: 05/02/2018

Hi there,

I’m new to most of this, but eager to get ArduPilot Blue up and running on the BeagleBone Blue ASAP. So far, I have the board up and running on the bench, but without GPS/compass.

I’m using the latest Debian IoT image (Debian 9.3 2018-01-28 4GB SD IoT), and all necessary software is installed and configured according to the instructions at https://github.com/mirkix/ardupilotblue.

Executing the following command appears to work, with data being sent successfully over the network as directed:

/usr/bin/ardupilot/blue-arducopter -C /dev/ttyS1 -A udp:192.168.0.18:14550 -B /dev/ttyS2

I have a couple of problems/questions:

  1. Using the v4.4 real-time kernel (as is suggested) means I can no longer connect to the BeagleBone (as its client) over USB. Why? Is this deprecated by now anyway? Which version should I be using?

  2. Although enabled, the ArduCopter systemd service (arducopter.service) fails to get the autopilot running upon boot. I don’t know why. The logs show:

From journalctl:

Feb 05 04:36:15 bbea1 blue-arducopter[789]: RCOutputAioPRU.cpp:SIGBUS error gernerated
Feb 05 04:36:15 bbea1 systemd[1]: arducopter.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 04:36:15 bbea1 systemd[1]: arducopter.service: Unit entered failed state.
Feb 05 04:36:15 bbea1 systemd[1]: arducopter.service: Failed with result ‘exit-code’.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Service hold-off time over, scheduling restart.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Start request repeated too quickly.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Unit entered failed state.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Failed with result ‘exit-code’.

From systemctl status:

Feb 05 04:36:15 bbea1 systemd[1]: arducopter.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 04:36:15 bbea1 systemd[1]: arducopter.service: Unit entered failed state.
Feb 05 04:36:15 bbea1 systemd[1]: arducopter.service: Failed with result ‘exit-code’.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Service hold-off time over, scheduling restart.
Feb 05 04:36:16 bbea1 systemd[1]: Stopped ArduCopter Service.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Start request repeated too quickly.
Feb 05 04:36:16 bbea1 systemd[1]: Failed to start ArduCopter Service.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Unit entered failed state.
Feb 05 04:36:16 bbea1 systemd[1]: arducopter.service: Failed with result ‘exit-code’.

Could some kind person give me a few pointers?

I have included a little script I wrote below for configuring connman automatically over SSH (without having to mess with the hashed ID). Might be helpful to some.

Thanks,

Imf

setconn.txt (1.7 KB)

2

Hello @imfatant

@mirkix will update the wiki sonn, in the meantime here is my receipe:
download and create iot image
https://rcn-ee.net/rootfs/bb.org/testing/2018-01-21/stretch-iot/bone-debian-9.3-iot-armhf-2018-01-21-4gb.img.xz
note 2018-01-28 should be OK

sudo apt update && sudo apt upgrade -y
sudo /opt/scripts/tools/grow_partition.sh
Reboot and check free space with DF

sudo apt install -y bb-cape-overlays cpufrequtils g++ pkg-config gawk git make screen python python-dev python-lxml python-pip
sudo pip install future
Most of the above are already on the IOT image

Update Kernel to RT 4_9
sudo /opt/scripts/tools/update_kernel.sh --ti-rt-channel --lts-4_9

Then build the beagle blue using BBBMINI instruction and setting board as blue
./waf configure --board=blue
./waf copter -j2
Copy the file to the blue ==start connman as per pocketpilot instructions

Enable PRU
echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state
start arducopter
sudo ./arducopter -C udp:Gdound.Station.Base.Adress:14550

For more info , you can join us here: https://gitter.im/mirkix/BBBMINI

2 Likes
3

Hi @ppoirier,

Many thanks for your help :). There’s a bit to get through; might take a day or two.

By the way, I’m new to quads. Do you have any recommendations as to frame kits - something that can function as a testbed, but would be good for a little racing too?

Oh, and how can I quote a BASH script on this forum without the # comment lines being rendered in that huge bold font?

Thanks again,

Imf

4

@imfatant
there are many 250 size that are perfectly suited and sometimes its cheaper to get a complete kit and just remove the flight controler and replace it with the blue :wink:
Just make sure the ESC are BLHELI firmware (Simonk sucks).

Use the " quotes to insert code so none of these !@#$%?&* can change text "

Regards

5

@ppoirier

I’ve gotten to cross-compiling the ArduCopter source on my main Arch Linux desktop system (for speed). The problem I’m currently having is when I do ‘./waf configure --board=blue’. This calls for a file called arm-linux-gnueabihf-ar. I think I’m right in saying this is to do with setting up the arm build toolchain, and I notice a symlink is created to pkg-config earlier on in the procedure outlined on the BBBmini site (https://github.com/mirkix/BBBMINI/blob/master/doc/software/software.md). Gotta have a think.

May I ask you what you’re using for BeagleBone Blue WiFi antennas?

Imf

6

@imfatant Do you actually have a problem cross-compiling from Arch Linux ?
I am on UBUNTU and that is what recommended here.
The BBBMINI is a little bit outdated as well…

As for antenna, I am using the Blue mostly for tests, it is not on a flying platform at the moment.
You could certainly use higher gain antennas but beware of interference with the Radio Control signal.

7

@ppoirier

Regarding my original question about arducopter.service failing to work as intended, I think connman should be abandoned in favour of NetworkManager. The latter starts a helper service to announce that a WiFi connection is actually up, and this can then be used as a trigger to launch arducopter.service. For now, though, I’m going with connman and the following hacky fix, which works OK (I compiled the ArduPilot Blue code (ArduCopter v3.5.5) on the BBone and stuck the executable in /usr/bin/ardupilot/):

[Unit]
Description=ArduCopter Service
Conflicts=arduplane.service ardupilot.service ardurover.service

[Service]
EnvironmentFile=/etc/default/arducopter
ExecStartPre=/bin/bash -c "/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state"
ExecStart=/usr/bin/ardupilot/arducopter $TELEM1 $TELEM2 $GPS

RestartSec=2min
Restart=on-failure

[Install]
WantedBy=multi-user.target

Of course, this only applies to systemd. Also, I’d force the BBone to use 5 GHz WiFi.

Still working on cross-compiling with Arch.

EDIT: Ah, I see connman provides connman-wait-online.service. This does exactly what is needed:

[Unit]
Description=ArduCopter Service
After=connman-wait-online.service
Conflicts=arduplane.service ardupilot.service ardurover.service

[Service]
EnvironmentFile=/etc/default/arducopter
ExecStartPre=/bin/bash -c "/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state"
ExecStart=/usr/bin/ardupilot/arducopter $TELEM1 $TELEM2 $GPS

Restart=on-failure

[Install]
WantedBy=multi-user.target

(This can then be enabled with ‘sudo systemctl enable connman-wait-online.service’.)

Imf

8

Yep… :wink:
I personaly prefer hostapd because it transform the BB as an AccesPoint, it works fine but its limited to few chipsets.

9

Systemd, arduplane-auto-start-on-boot.
Finally got everything working manually last week on my BBBL (precompiled) arduplane twin-engine (differential thrust) delta wing breadboard, connected to Mission Planner via 915MHz telemetry radio and controlled via joystick. Woohoo!

Onward to an automatic startup script.

Tried it the “easy” way, i.e, with the now-deprecated rc.local, and while activating rc.local through systemd, I managed bugger my BBBL setup. I re-Flashed the Bone and went through my recipe again, this time determined to use the purely systemd approach cited on Mirko’s page, modified for arduplane on my setup.

Still unsuccessful: arduplane is not starting up at boot, and I’m informed by systemctl status that both arduplane.service and roboticscape.service failed to start. If only arduplane.service was failing I would suspect the culprit to be my modified systemd files, but with roboticscape.service also failing I wonder if I’m again bumping up against a work-in-progress.

My arduplane default file is in /etc/default

TELEM1="-C /dev/ttyS1"
TELEM2="-A udp:192.168.8.77:14550"
#TELEM2="-C /dev/ttyAMA0"
GPS="-B /dev/ttyS2"

#Options to pass to ArduPlane
#ARDUPLANE_OPTS=$TELEM1 $TELEM2

#-A is a console switch (usually this is a Wi-Fi link)
#-C is a telemetry switch
#Usually this is either /dev/ttyAMA0 - UART connector on a Navio

or /dev/ttyUSB0 if you’re using a serial to USB convertor"

#-B or -E is used to specify non-default GPS

WantedBy=multi-user.target

And my arduplane.service file is in /lib/systemd/system/

[Unit]
Description=ArduPlane Service
After=networking.service
Conflicts=arducopter.service ardupilot.service ardurover.service

[Service]
EnvironmentFile=/etc/default/arduplane
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_21_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_22_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_24_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_26_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state"
ExecStartPre=/bin/bash –c "/bin/echo 1 > /sys/class/gpio/gpio80 value"
ExecStart=/home/debian/bin/arduplane $TELEM1 $TELEM2 $GPS

Restart=on-failure

[Install]
WantedBy=multi-user.target

Any insight you can offer on this issue would be greatly appreciated. Thanks to all for your efforts and patient communication. Cheers.

10

Hi @CapnTim,

Welcome aboard :).

Yes, this seems to be a bit of a murky problem. Isn’t systemd fun? I thought I’d put the issue to bed by launching arducopter (arduplane in your case) ‘After=connman-wait-online.service’ rather than ‘After=networking.service’.

However, I ended up abandoning this method (for now, at least, because my time is limited) in favour of simply launching arducopter a certain time after boot (i.e. via a timer) rather than after a particular service comes up. This works every time for me, so I suggest you try it too. It’s not ideal, but I will revisit the matter soon.

Your arduplane.service file should look like this:

[Unit]
Description=ArduPlane Service
Conflicts=arducopter.service ardupilot.service ardurover.service

[Service]
EnvironmentFile=/etc/default/arduplane
ExecStartPre=/bin/bash -c "/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state"
ExecStart=/home/debian/bin/arduplane $TELEM1 $TELEM2 $GPS

Restart=on-failure

And make an arduplane.timer file (also in /lib/systemd/system) that looks like this:

[Unit]
Description=ArduPlane Service Timer

[Timer]
OnBootSec=60s

[Install]
WantedBy=timers.target

Now use sudo systemctl enable arduplane.timer to set it up, and reboot. Perhaps cross your fingers ;).

Imf

PS: Swing by https://gitter.im/mirkix/BBBMINI.

1 Like
11

Hello Imf!

Thank you for the clarity of your reply, for the strategic insight, and for taking the time to assemble file examples. Your reduced arduplane.service file script works, in that arduplane starts up and can connect to Mission Planner with 3DR V2 radios via TELEM1="-C /dev/ttyO1" to send its GPS and IMU telemetry there about 23 seconds after boot. That comes at the tolerable but notable penalty of wifi not becoming enabled until about 3 minutes after boot (rather than ~50sec). I’ll still call it a step forward. At some point I do want to enable servo rail power as well.

Other, perhaps unrelated, startup issues have arisen… manual startup suffers the same response (no signal at the BBBL servo rail when communicating via 3DR), so unfortunately I can’t yet report complete success.

Edit for clarity here: Are pins P9_21 and P9_22 and pins P9_24 and P9_26 set enabled for GPS and telemetry by default now? I wonder if my BBBL is receiving, since those enabling functions were extracted from your working example and Mission Planner stalls on retrieving parameters. I tried adding them back into the arduplane.service file and using systemctl daemon-reload, but their addition makes the ardupilot.service file fail.

I’ve been auditing https://gitter.im/mirkix/BBBMINI for some months now, and I have found lots of information relevant to my project, but the experience still feels like I just sat down at the grown-ups table and should just listen for a while.

Yes, systemd is threatening to become another hydra. I’ve made peace with Linux, and just accepted that it teaches patience. The greatest difficulty with learning patience is that the lessons don’t come quickly.

12

I had a similar problem but fortunately I could solve it . I am using the image: bone-debian-9.3-iot-armhf-2018-03-05-4gb.img and the Kernel RT 4.9. When I was trying to run arducopter I got RCOutputAioPRU.cpp:SIGBUS error gernerated.

In order to solve this problem you should uncomment the line uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo in /boot/uEnv.txt. If you are using RT 4.9 you should also change the line to: uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo.

I hope this could be useful for someone.

2 Likes
13

@Gabriel_Dai hello, yes that is exactly what has been explained to @CapnTim on the bbbmini channel this week-end :slight_smile:

Feel free to join us there : https://gitter.im/mirkix/BBBMINI

1 Like
14

Hello , i am making quadcopter for my last term of project and i have some problems in my softwares. I am making quadcopter using BBB mini and follow the steps, which are mentioned in https://www.hackster.io/patrickpoirier51/pocketpilot-an-autopilot-based-on-the-25-pocketbeagle-1fa14b.The problem is i have done my hardware part and doing software on linux platform.Moreover, i have finished the program upto Compile ArduPilot native on BeagleBone and Cross compile ArduPilot (faster) with Ubuntu computer.However, when i am checking my hardware,which is mentioned in Run ArduPilot , that time i am getting some problem. In check IMU command , i write sudo /home/debian/INS_generic in my debian@beaglebone and getting this type of error-.Sensor failure: INS: unable to initialise driver . So please request you to help me with this. Waiting for your positive reply. please help me beacuse i have only 2 week to complete my project.

15

For BBBMINI you have to follow these steps https://github.com/mirkix/BBBMINI/blob/master/doc/software/software.md

16

@ppoirier, @imfatant and @mirkix: We are currently working on updating the setup and install instructions for the BBBlue, see ardupilot_wiki/common-beagle-bone-blue.rst at master · drtrigon/ardupilot_wiki · GitHub

Now we have some questions. Regarding the real-time kernel; can somebody explain whether it is needed at all? If not - say it’s optional - what does the use of a real-time kernel change? What is the advantage?

Thanks and Greetings

17

Well, it"s been a long time…
you may ask @yashlancers he seems to be active and worked with debian on a bbblue

oh btw, the best explanation and TEST of a RT Preempt kernel was this blog
http://www.frank-durr.de/?p=203

And not to forget @juvinski who is the sole survivor of the race… :wink:

18

@ppoirier: Thanks a lot for the very valuable info! May I ask why you are not using BBBlue anymore?

@yashlancers and @juvinski: As noted before we are currently working on updating the setup and install instructions for the BBBlue, see above. Any hint, recommendation, tought or experience regarding that topic is very welcome! Would you be willing to have a look and give some feedback? (e.g. are you still working with BBBlue? why? etc.)

19

Because an all-in FC-CC is not optimal , not stable , not flexible and lacking processing power

I might add a very important point : its missing a dedicated team of developers to keep it up to date … which is not the case since @mirkix is busy in other (commercial) projects

20

Hi guys,

glad to hear from you @ppoirier :slight_smile:

@drtrigon , in true, I have a blue but after several tests I prefer the BBBMini as Blue.
Regarding the blue, the I2C interface is not my prefered communication protocol, and BBBMini use the SPI for imu and baro communications.
Another point is the PRU. I tried to write some codes to deal with dshot, worked but I couldn’t figure out how to do the one wire telemetry, once on tne pru you just have outpout or input pins, not a configurable pin to deal with the communication.

1 Like