Using Robotics Cape with Beaglebone AI

Hi there

I was just wondering if anyone could discuss the steps for making the robotics cape work with BB-AI.



Just a quick update on what I was able to find and my current problems.

  1. You can read the IMU and Barometer simply by changing the bus to 3. The MPU has a nice configuration template where you select the i2c_bus. You can just do conf.i2c_bus=3, and it will run as normal. The barometer does not seem to have this, and instead you have to modify the bmp.c file.

  2. There seems to be a problem with the PRUs as my previous codes use them to read RC Receiver PPM signals, and generate PWM using mirkix PRU’s for ardupilot., are unable to even share memory with them, and running rc_test_drivers does indicate that the PRU did not load properly.

  3. I also have problems with the LEDs as they don’t seem to be loading properly in the rc_test_drivers.

  4. Regarding UART, they seem to have problem given they are all set as ttyS1, ttyS2, etc. Only ttyO5 is working, and is set as ttyO5 → ttyS5, which I am guessing is some kind of renaming or something? Not sure, not an expert on linux.

Any help would be much appreciated! :slight_smile:

This is on my backlog. I have done some hacking on it on some branches, but have a long way to go.

Hi @jkridner

Thank you for your prompt response.

As a quick update:

I have managed to get the PRU working for PWM generation on all 8 servo channels using Mirkix PRU codes for ardupilot which you can find in (ardupilot/RcAioPRUTest.c at BBAIPilot · juvinski/ardupilot · GitHub). For this you need to update both the “RcAioPRU_BBAI_bin.h” file that is used, as well as the RAM/CTRL/IRAM addresses which are used by the PRU program…

Nonetheless, the aforementioned PRU program is still unable to read/process my RC Receiver CPPM signals when connected to the E4 pin of robotics cape (as it was done in previous boards), and after some quite long discussion in (mirkix/BBBMINI - Gitter), I’ve now understood that the PRU program that they have is loaded to I think PRU-ICSS2 which apparently has the eCAP0 linked to pin P8_32 of the pin header… I am now trying to change that to load the PRU code on PRU-ICSS1 which supposedly has the eCAP0 linked to pin P8_15, as in the blue/black, etc. which is available in connector E4.

The alternative for me, which I’ve already implemented is to use a UART port to process iBUS from my Flysky RC Receiver.

I should mention that the problem of the UARTs set as ttyS1 instead of ttyO1 was gone when I updated the /boot/uEnv.txt file with dtb=am5729-beagleboneai-roboticscape.dtb.

This also fixed some other errors reported when I ran the “rc_test_drivers” of the robotics cape, such as UART, SPI, LED, ADC as seen in the image below.


Nonetheless, even though the LEDs drivers seem to have loaded, they still give me some errors when I test “rc_test_leds”. The good news is ADC seems to be working correctly. :smiley:


Something that caught my eye and I can’t quite understand why is happening or what it means is that I don’t have a
/sys/devices/platform/ocp/ folder…


1 Like


Just a couple of comments on some further progress.

I am now able to fly my hexacopter perfectly as I did before with the Beaglebone Blue.

One of the things I noticed from the aforementioned Mirkix PRU code was that the Servo outputs are actually mapped as : 1 2 3 4 5 6 in BBBlue → 2 1 4 3 6 5 in BB_AI+Robotics Cape

Moreover, I noticed that UART5 from Robotics Cape is actually UART 1 in BB_AI, and I’ve successfully I used this to read an iBUS RC receiver.

Hope this helps anyone.

All the best!


FYI, to address the different peripherals used on the different base boards, we’re introducing a Cape Compatibility Layer. This is still a work in progress to be included in upcoming Bullseye images.


Any pointers about how to get PWM and I2C drivers working on the BB-AI using lib-robot-control?

I have worked my way through some threads, including this one and
I tried a few things such as upgrading the kernel and overlays, but no luck so far.

Also, I am using the v1.1 branch of, but this is not required.

Thanks in advance!

This is the current status:

Output from rc_test_drivers
Kernel: 4.19.94-ti-r73 Debian Buster IoT TIDL Image 2020-04-06
Debian: 10.3

PASSED: gpio 0
PASSED: gpio 1
PASSED: gpio 2
PASSED: gpio 3
ERROR: ti-pwm driver not loaded for hrpwm0
ERROR: ti-pwm driver not loaded for hrpwm1
ERROR: ti-pwm driver not loaded for hrpwm2
ERROR: ti-eqep driver not loaded for eqep0
ERROR: ti-eqep driver not loaded for eqep1
ERROR: ti-eqep driver not loaded for eqep2
PASSED: pru-rproc
PASSED: uart1
PASSED: uart2
PASSED: uart4
PASSED: uart5
ERROR: i2c1 driver not loaded
ERROR: i2c2 driver not loaded

Currently running on a:
Robot Control library Version:

Output from
dogtag:[ Debian Buster IoT TIDL Image 2020-04-06]
UBOOT: Booted Device-Tree:[am5729-beagleboneai-roboticscape.dts]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 11.898700] remoteproc remoteproc0: 58820000.ipu is available
[ 12.002020] remoteproc remoteproc1: 55020000.ipu is available
[ 12.030481] remoteproc remoteproc2: 40800000.dsp is available
[ 12.116320] remoteproc remoteproc3: 41000000.dsp is available
[ 12.156235] remoteproc remoteproc1: powering up 55020000.ipu
[ 12.156284] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3751356
[ 12.267690] remoteproc remoteproc0: powering up 58820000.ipu
[ 12.267739] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 7051536
[ 12.277673] Modules linked in: omap_remoteproc virtio_rpmsg_bus remoteproc virtio virtio_ring cmemk(O) uio_pdrv_genirq uio gpio_pisosr spidev
[ 12.286557] Modules linked in: omap_remoteproc virtio_rpmsg_bus remoteproc virtio virtio_ring cmemk(O) uio_pdrv_genirq uio gpio_pisosr spidev
[ 12.829779] [] (iommu_attach_device) from [] (rproc_boot+0x380/0x6ec [remoteproc])
[ 12.839269] [] (rproc_boot [remoteproc]) from [] (rproc_auto_boot_callback+0x20/0x2c [remoteproc])
[ 12.850098] [] (rproc_auto_boot_callback [remoteproc]) from [] (request_firmware_work_func+0x60/0x9c)
[ 13.531390] remoteproc remoteproc2: powering up 40800000.dsp
[ 13.545225] remoteproc remoteproc3: powering up 41000000.dsp
[ 13.566990] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 21014532
[ 13.578963] remoteproc remoteproc3: Booting fw image dra7-dsp2-fw.xe66, size 21014532
[ 14.006365] remoteproc remoteproc1: registered virtio0 (type 7)
[ 14.058934] remoteproc remoteproc1: remote processor 55020000.ipu is now up
[ 14.279078] remoteproc remoteproc3: registered virtio1 (type 7)
[ 14.319016] remoteproc remoteproc3: remote processor 41000000.dsp is now up
[ 14.435112] remoteproc remoteproc2: registered virtio2 (type 7)
[ 14.466958] remoteproc remoteproc2: remote processor 40800000.dsp is now up
[ 30.906758] remoteproc remoteproc4: is available
[ 30.992289] remoteproc remoteproc5: is available
[ 31.042074] remoteproc remoteproc6: is available
[ 31.089027] remoteproc remoteproc7: is available
dmesg | grep pru
[ 24.289994] pruss_uio_shmem 4b200000.pruss_shmem: Allocating gdev
[ 24.374944] pruss_uio_shmem 4b200000.pruss_shmem: Allocating info
[ 24.502756] pruss_uio_shmem 4b200000.pruss_shmem: Requesting resource
[ 24.614404] pruss_uio_shmem 4b200000.pruss_shmem: Mapping resource
[ 24.666973] pruss_uio_shmem 4b200000.pruss_shmem: Registering with uio driver
[ 24.735149] pruss_uio_shmem 4b200000.pruss_shmem: Saving platform data
[ 24.794751] pruss_uio_shmem 4b280000.pruss_shmem: Allocating gdev
[ 24.852516] pruss_uio_shmem 4b280000.pruss_shmem: Allocating info
[ 24.870985] pruss_uio_shmem 4b280000.pruss_shmem: Requesting resource
[ 24.883082] pruss_uio_shmem 4b280000.pruss_shmem: Mapping resource
[ 24.889938] pruss_uio_shmem 4b280000.pruss_shmem: Registering with uio driver
[ 24.910079] pruss_uio_shmem 4b280000.pruss_shmem: Saving platform data
[ 30.906758] remoteproc remoteproc4: is available
[ 30.938059] pru-rproc PRU rproc node pru@4b234000 probed successfully
[ 30.992289] remoteproc remoteproc5: is available
[ 31.015176] pru-rproc PRU rproc node pru@4b238000 probed successfully
[ 31.042074] remoteproc remoteproc6: is available
[ 31.063126] pru-rproc PRU rproc node pru@4b2b4000 probed successfully
[ 31.089027] remoteproc remoteproc7: is available
[ 31.111807] pru-rproc PRU rproc node pru@4b2b8000 probed successfully
dmesg | grep pinctrl-single
[ 0.982788] pinctrl-single 4a003400.pinmux: 282 pins, size 1128
dmesg | grep gpio-of-helper
[ 0.993669] gpio-of-helper 44000000.ocp:cape-universal: Failed to request gpio ‘P9_27’
[ 0.993684] gpio-of-helper 44000000.ocp:cape-universal: Failed to create gpio entry
[ 1.000760] gpio-of-helper: probe of 44000000.ocp:cape-universal failed with error -1
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hi tyler

As you can see from the images above, I also do not get the i2c drivers to mark as “passed” when calling rc_test_drivers… however, as I mentioned there, I noticed the imu is connected to i2c-3, so I specify the bus when setting the configuration at the IMU start up.

Regarding PWM generation, I used mirkix PRU, which as I mentioned, works but has the channels mixed/reversed, eg. 214365 instead of 123456. To achieve this, you need to have a look at the files they provide which do this, and it is not through the robot control library.

Sorry, I hope it helps.

Hi @jkridner

Just checking if you know any good example of real time image processing with the bb-AI. I’ve only found your example for using the streamer.

I am interested in doing some basic color segmentation or edge detection, before applying the whole AI stuff but would be nice to know how to offload the stuff to the dedicated units.

At the moment I have a 2 kg hexacopter flying perfectly stable and doing stuff with our motion capture system like waypoint navigation, flips and the likes, here in Cranfield University. Next step is to add situation awareness which involves getting bounding boxes of things near me like other drones, persons, obstacles and stuff.

Would appreciate some help.