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.

Thanks!

Hi

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.

image

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:

image

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…

image

1 Like

Hi

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!

2 Likes

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.

2 Likes

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 https://github.com/beagleboard/librobotcontrol/issues/173.
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 https://github.com/beagleboard/librobotcontrol, but this is not required.

Thanks in advance!

This is the current status:

Output from rc_test_drivers
Kernel: 4.19.94-ti-r73
BeagleBoard.org 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
PASSED: spi
PASSED: LED
PASSED: ADC iio

Currently running on a:
MODEL_BB_AI
Robot Control library Version:
1.1.0

Output from version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
model:[BeagleBoard.org_BeagleBone_AI]
dogtag:[BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06]
UBOOT: Booted Device-Tree:[am5729-beagleboneai-roboticscape.dts]
kernel:[4.19.94-ti-r73]
nodejs:[v10.15.2]
device-tree-override:[dtb=am5729-beagleboneai-roboticscape.dtb]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=BONE-PWM1.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.14.20210821.0-0~buster+20210821]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
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: 4b234000.pru is available
[ 30.992289] remoteproc remoteproc5: 4b238000.pru is available
[ 31.042074] remoteproc remoteproc6: 4b2b4000.pru is available
[ 31.089027] remoteproc remoteproc7: 4b2b8000.pru 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: 4b234000.pru is available
[ 30.938059] pru-rproc 4b234000.pru: PRU rproc node pru@4b234000 probed successfully
[ 30.992289] remoteproc remoteproc5: 4b238000.pru is available
[ 31.015176] pru-rproc 4b238000.pru: PRU rproc node pru@4b238000 probed successfully
[ 31.042074] remoteproc remoteproc6: 4b2b4000.pru is available
[ 31.063126] pru-rproc 4b2b4000.pru: PRU rproc node pru@4b2b4000 probed successfully
[ 31.089027] remoteproc remoteproc7: 4b2b8000.pru is available
[ 31.111807] pru-rproc 4b2b8000.pru: 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
lsusb
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
END

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.

latest bbai image: https://rcn-ee.com/rootfs/release/2023-08-05/bullseye-minimal-arm64/bbai64-debian-11.7-minimal-arm64-2023-08-05-4gb.img.xz

gpio pin specs for bbai: Connectors β€” BeagleBoard Documentation

gpio pin specs for robotics cape:
https://github.com/beagleboard/capes/blob/master/beaglebone/Robotics/Robotics_Cape_sch.pdf

Enabling the I2C1 Port
I’ve been trying to get the Robotics Cape to work with Beaglebone AI as well and after struggling with it for two weeks (steep learning curve with the device tree overlay stuff) I finally got the i2c1 port to work. The i2c1 port on the robotics cape maps to i2c5 on the beaglebone ai if you compare the gpio pin specifications. It turns out it is disabled by default (if you check the device tree for the kernel you will see there is no "status = β€œokay” entry for i2c5. It can, however, be enabled via a device tree overlay. Here’s how:

  1. image the Beaglebone AI with the latest image (Debian 11)

  2. Download the BONE-I2C1.dts file from the Cape Compatibility code and copy it to the Beaglebone AI: https://github.com/lorforlinux/bb.org-overlays/blob/bone_i2c/src/arm/BONE-I2C1.dts

  3. Change TIMESTAMP in BONE-I2C1.dts to an actual timestamp such as β€œ2023-08-18 15:30:00” (probably a better way than this)

  4. Compile using dtc: dtc -O dtb -o BONE-I2C1.dtbo BONE-I2C1.dts

  5. sudo cp BONE-I2C1.dtbo /boot/dtbs/5.10.168-ti-r68/overlays/

  6. sudo vim /boot/uEnv.txt

  7. In uEnv.txt, add the following line: uboot_overlay_addr0=BONE-I2C1.dtbo

  8. sudo reboot now

  9. Test by typing i2cdetect -y -r 1 which should show the i2c address of the device you connected to the i2c1 port. I connected a mux (0x70) so my output looks like this:

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – 29 – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – – – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: 70 – – – – – – –

You can then reference bus 1 and register address 0x70 when using the rc robot control library.