Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jul 27 2019 14:05
    HomeLH commented #45
  • Jul 21 2019 16:11
    mirkix commented #45
  • Jul 21 2019 16:11
    mirkix commented #45
  • Jul 21 2019 02:52
    HomeLH edited #45
  • Jul 21 2019 02:51
    HomeLH opened #45
  • Apr 09 2019 20:21
    mirkix commented #44
  • Apr 09 2019 20:21

    mirkix on master

    Add git pull instructions and c… Merge pull request #44 from Ard… (compare)

  • Apr 09 2019 20:21
    mirkix closed #44
  • Apr 06 2019 16:09
    Ardustorm commented #44
  • Apr 06 2019 15:50
    Ardustorm opened #44
  • Mar 18 2019 04:16

    mirkix on master

    Update ArduPilot (compare)

  • Jul 10 2018 16:36
    jackcarrozzo commented #38
  • Jul 10 2018 16:19
    awright424 commented #38
  • Jul 10 2018 16:17
    jackcarrozzo commented #38
  • Jul 10 2018 16:17
    jackcarrozzo commented #38
  • Jul 10 2018 16:17
    jackcarrozzo commented #38
  • Jul 10 2018 16:17
    jackcarrozzo commented #38
  • Jul 10 2018 16:16
    jackcarrozzo commented #38
  • Jul 10 2018 16:14
    awright424 commented #38
  • Jul 10 2018 16:12
    jackcarrozzo commented #38
this says rc input is p8_15
but reading what mirko says it should work. could you be using the wrong signal pin? does it work for you using the dsm2 port?
I have never used a beagle bone blue. but for some reason a part of me thinks this is the pru. From what I understand about the blue it accesses some sensors through i2c so probably doesnt use the pru. I would ssh in and run config-pin -f ardupilotblue/config/blue_pin.cfg wherever said file is or download it. I think you need to set the pins properly
Bas de Bruijn

I'll dig into that. I've tried both dsm port as well as the setup as per instructions on https://github.com/mirkix/ardupilotblue.

debian@beaglebone:~$ config-pin P8_15 pruecapin_pu
Invalid mode: pruecapin_pu

Are there any steps that I can check? overlay settings or whatnot?

looking a bit with google-fu beagleboard/bb.org-overlays#62
are you booting with the uninversal io cape?
not sure if that is used on the blue can only assume
it uses its own .dtb apparently: dtb=am335x-boneblue.dtb
Bas de Bruijn
This is what's in my uEnv.txt
debian@beaglebone:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0


###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
###Overide capes with eeprom
###Additional custom capes
###Custom Cape
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
###pru_rproc (4.4.x-ti kernel)
###pru_rproc (4.14.x-ti kernel)
###pru_rproc (4.19.x-ti kernel)
###pru_uio (4.4.x-ti, 4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
###Cape Universal Enable
###Debug: disable uboot autoload of Cape
###U-Boot fdt tweaks... (60000 = 384KB)
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet overlayroot=tmpfs

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
it looks like you are set to use the universal cape
but it doesnt seem enabled

Cape Universal Enable



Bas de Bruijn

I'm looking if I did somethhing wrong with building and I'm noticing that during the ./waf configure step there's this output

Checking for 'libiio'                                 : yes
Checking link with libiio                             : no

Does this sound like something that could be the source of the problem?

I have that configuration too.
Let me get my board and see my /boot/uEnv.txt file, too.
Hey. Did you make sure you are not using librobotcontrol on your BBBlue yet? Sometimes, this will interfere w/ things.
I think @awright424 is correct. My enable_uboot_cape_universal=1 is not commented out. So, it should be working during the flight precheck.
@luminize : Try to uncomment that line in your /boot/uEnv.txt file.
Linux beaglebone 4.19.50-bone-rt-r35 ---> Currently this is what my board is running. I will update the kernel and test it.
@luminize : I have a couple of questions.
1. How are you powering your RX? Okay...I see you said from your DSM2 port's 3.3v pin. Okay.
2. Are you using the PRU via the set up file or are you trying manually to establish the connection via config-pin or a .dts file?
3. Have you only used the PRU on Encoder4 Pin 4 and if so, did you also try to use GND from that specific Encoder 4?
Just for reference, I used the voltage from the Servo Header pins to power my receiver. I have a FrSky RX/transmitter. I had to plug in the ESCs to the receiver signal pins.
Oh and one for GND from the 4-in-1 ESC to the receiver.
here is a log of either my flight in acro or stabilize both modes I had issues once in the air. pids I think are good at this point. I am not sure if the issue is interference with the imu or if it is something else
Bas de Bruijn


  • I did not set up librobotcontrol, I'm not aware I'm using it. I started out from the sd image depicted in the instructions.
  • After checking yesterday I uncommented enable_uboot_cape_universal=1
  • I'm powering from the DSM connector (3.3V on the orange and black wires) which is needed for the Spektrum receiver) and using the signal on either the grey wire of the DSM connector, or on the red wire from the E4 connector. I've captured the signal on an OpenBench Logic Sniffer, and I can very clearly see the signal.
  • although I cleared my git repo (git clean -xfd), I still seem to have 3.6.10 version built, if that's a problem (I do not think so, see next point) i will remove the directory and build from scratch
  • I set up the service, failing to get things running I ran ardupilot from the terminal, forgetting to run the setup file. starting the service shows that there's a problem with the pins.
debian@beaglebone:~$ systemctl status arducopter.service
● arducopter.service - ArduCopter Service
   Loaded: loaded (/lib/systemd/system/arducopter.service; disabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-12 06:31:58 UTC; 3min 57s ago
  Process: 1329 ExecStartPre=/bin/bash /usr/bin/ardupilot/aphw (code=exited, status=0/SUCCESS)
 Main PID: 1337 (arducopter)
    Tasks: 6 (limit: 4915)
   CGroup: /system.slice/arducopter.service
           └─1337 /usr/bin/ardupilot/arducopter -C /dev/ttyO1 -A udp: -B /dev/ttyO2 -F /dev/ttyO5

Sep 12 06:31:58 beaglebone systemd[1]: Starting ArduCopter Service...
Sep 12 06:31:58 beaglebone bash[1329]: /bin/echo: write error: Operation not permitted
Sep 12 06:31:58 beaglebone bash[1329]: /usr/bin/ardupilot/aphw: line 6: /sys/class/gpio/gpio80/direction: No such file or directory
Sep 12 06:31:58 beaglebone bash[1329]: /usr/bin/ardupilot/aphw: line 7: /sys/class/gpio/gpio80/value: No such file or directory
Sep 12 06:31:58 beaglebone systemd[1]: Started ArduCopter Service.

So I think the problem has to be somewhere in overlays/setup

here's the picture for the connectors i'm using
captured signal from receiver
Bas de Bruijn
I manually ran the commands in the aphw script and checked after I manually run arducopter
debian@beaglebone:~$ ls /sys/class/gpio/
export  gpio80  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport
debian@beaglebone:~$ ls /sys/class/gpio/gpio80
active_low  device  direction  edge  label  power  subsystem  uevent  value
debian@beaglebone:~$ cat /sys/class/gpio/gpio80/direction
debian@beaglebone:~$ cat /sys/class/gpio/gpio80/value
debian@beaglebone:~$ cat /sys/devices/platform/ocp/ocp:P8_15_pinmux/state
something didnt go right with the pinmux setup i would think
@luminize I recall walking through DSM back in April, search on this thread with the word DSM
Bas de Bruijn
@patrickpoirier51 I will do that
Bas de Bruijn
@patrickpoirier51 I'm a bit confused, it seems that there was a problem, but after a fix the 4.19 kernel works? I have followed the setup tutorial to the letter. I'm out of ideas to be honest.
pruecapin_pu needs to be an input and not an output.
It seems /bin/echo is not permitted for your gpio80 pinmux, too. This is what I see in your arducopter.service file. Will you share your aphw file?
Did you use chmod on every file that needs to be executed? See here: https://help.ubuntu.com/community/FilePermissions.
Oh. And...sometimes powering the receiver off of a separate power supply works too. These are all just some items to take into consideration.
Bas de Bruijn

yes I did. I have just finished a new CD card, exact image, per instructions.

debian@beaglebone:~/ardupilot$ git branch
* Copter-3.6

Arducopter loads, (red light flashes) DSMX reveiver is bound to transmitter, signals visible on scope.
Qgroundcontrol does not complain that there's no receiver found, calibrating the radio fails though.
My service (I removed the $RANGER variable):

● arducopter.service - ArduCopter Service
   Loaded: loaded (/lib/systemd/system/arducopter.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-12 12:14:22 UTC; 27min ago
  Process: 797 ExecStartPre=/usr/bin/ardupilot/aphw (code=exited, status=0/SUCCESS)
 Main PID: 805 (arducopter)
    Tasks: 6 (limit: 4915)
   CGroup: /system.slice/arducopter.service
           └─805 /usr/bin/ardupilot/arducopter -C /dev/ttyO1 -A udp: -B /dev/ttyO2

Sep 12 12:14:22 beaglebone systemd[1]: Starting ArduCopter Service...
Sep 12 12:14:22 beaglebone systemd[1]: Started ArduCopter Service.

my aphw file

debian@beaglebone:~$ cat /usr/bin/ardupilot/aphw
# aphw
# ArduPilot hardware configuration.

/bin/echo 80 >/sys/class/gpio/export
/bin/echo out >/sys/class/gpio/gpio80/direction
/bin/echo 1 >/sys/class/gpio/gpio80/value
/bin/echo pruecapin_pu >/sys/devices/platform/ocp/ocp:P8_15_pinmux/state

the permissions

debian@beaglebone:~$ ls -l /usr/bin/ardupilot/
total 7412
-rwxr-xr-x 1 root root  890024 Sep 12 11:51 antennatracker
-rwxr-xr-x 1 root root     257 Sep 12 09:36 aphw
-rwxr-xr-x 1 root root 1461016 Sep 12 11:51 arducopter
-rwxr-xr-x 1 root root 1434284 Sep 12 11:51 arducopter-heli
-rwxr-xr-x 1 root root 1416180 Sep 12 11:51 arduplane
-rwxr-xr-x 1 root root 1181896 Sep 12 11:51 ardurover
-rwxr-xr-x 1 root root 1189688 Sep 12 11:51 ardusub
thanks @silver2row @awright424 @patrickpoirier51 for taking the time. I appreciate that.
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.71-bone-rt-r38 #1stretch PREEMPT RT Sat Sep 7 10:05:07 UTC 2019 armv7l GNU/Linux
can it be a protocol thing? like my dsmx receiver can't talk with Ardupilot?