Using LibRobotControl and PX4/QGroundControl

Hello,

Has anyone successfully got their BBBlue to work w/ librobotcontrol and the PX4 software?

Seth

P.S. Is this normal? This is from the source of px4 before compilation plus it does not compile into the px4 source when cross-compiling. Also, upload to the BBBlue from a dev. desktop does not fully support the BBBlue. So, there will be some advancements in this field before I finish.

/* PRU encoder input */
                        0x038 0x36      /* P8_16,PRU0_r31_16,MODE6 */

                        /* PRU Servo output */
                        0x0e0 0x05      /*pru1_pru_r30_8, MODE5*/
                        0x0e8 0x05      /*pru1_pru_r30_10, MODE5 */
                        0x0e4 0x05      /*pr1_pru1_pru_r30_9, MODE5 */
                        0x0ec 0x05      /*pru1_pru_r30_11, MODE5 */
                        0x0b8 0x05      /*pru1_pru_r30_6, MODE5 */
                        0x0bc 0x05      /*pru1_pru_r30_7, MODE5 */
                        0x0b0 0x05      /*pru1_pru_r30_4, MODE5 */
                        0x0b4 0x05      /*pru1_pru_r30_5, MODE5 */
                        0x0C8 0x0F      /*P8.36, SERVO_PWR GPIO OUT*/

and…this is from the BeagleBoard-DeviceTrees github.com repo.


&am33xx_pinmux {
        /***************************************************************************
        * Static Pinmux
        ***************************************************************************/
        mux_helper_pins: pins {
                pinctrl-single,pins = <

                        /* GPIO Inputs */
                        0x09c 0x37      /*P8.9  Pause BUTTON, input pullup*/
                        0x098 0x37      /*P8.10 MODE BUTTON input pullup*/
                        0x1AC 0x37      /*P9.25 MPU-9150 INTERRUPT IN*/

                        /* Motor Control GPIO Out*/
                        0x088 ( PIN_OUTPUT | MUX_MODE7 ) /* (T13) gpmc_csn3.gpio2[0] - MDIR_1A different from cape! */
                        0x074 ( PIN_OUTPUT | MUX_MODE7 ) /* (U17) gpmc_wpn.gpio0[31] - P9.13, MDIR_1B */
                        0x040 ( PIN_OUTPUT | MUX_MODE7 ) /* (R13) gpmc_a0.gpio1[16] - P9.15, MDIR_2A */
                        0x0D8 ( PIN_OUTPUT | MUX_MODE7 ) /* (V4) lcd_data14.gpio0[10] - P8.31, MDIR_2B different from cape! */
                        0x0AC ( PIN_OUTPUT | MUX_MODE7 ) /* (R4) lcd_data3.gpio2[9] - P8.44, MDIR_3A */
                        0x0A8 ( PIN_OUTPUT | MUX_MODE7 ) /* (R3) lcd_data2.gpio2[8] - P8.43, MDIR_3B */
                        0x0A0 ( PIN_OUTPUT | MUX_MODE7 ) /* (R1) lcd_data0.gpio2[6] - P8.45, MDIR_4A */
                        0x0A4 ( PIN_OUTPUT | MUX_MODE7 ) /* (R2) lcd_data1.gpio2[7] - P8.46, MDIR_4B */
                        0x1B4 ( PIN_OUTPUT | MUX_MODE7 ) /* (D14) xdma_event_intr1.gpio0[20] - P9.41, MOT_STBY */

                        /* PRU encoder input */
                        0x038 0x36      /* P8_16,PRU0_r31_16,MODE6 */


                        /* PRU Servo output */
                        0x0e0 0x05      /*pru1_pru_r30_8, MODE5*/
                        0x0e8 0x05      /*pru1_pru_r30_10, MODE5 */
                        0x0e4 0x05      /*pr1_pru1_pru_r30_9, MODE5 */
                        0x0ec 0x05      /*pru1_pru_r30_11, MODE5 */
                        0x0b8 0x05      /*pru1_pru_r30_6, MODE5 */
                        0x0bc 0x05      /*pru1_pru_r30_7, MODE5 */
                        0x0b0 0x05      /*pru1_pru_r30_4, MODE5 */
                        0x0b4 0x05      /*pru1_pru_r30_5, MODE5 */
                        0x0C8 0x0F      /*P8.36, SERVO_PWR GPIO OUT*/

I thought SERVO_PWR GPIO OUT was gpio80. Also…I see the encode input is P8_16 on this .dts file. I thought it was P8_15 for the PRU input pin on the encoder4 connector?

  1. https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv

Hello Again,

I have made no headway so far. Should I use a .dtb file in /boot/uEnv.txt or use uboot-overlays .dtbo files in the /boot/uEnv.txt file?

I can use config-pin if necessary but I am thinking I need to switch out some of the info. listed in the am335x-boneblue.dts file and then compile it. Where would I need to store this file, the .dtb file, to have it accessible and known to the file system? Would I just compile it and then keep it listed at:

dtb=am335x-boneblue.dtb

This argument would obviously be listed in /boot/uEnv.txt but I think changing some of the info. in the file is needed first. I will continue to work on it.

Seth

Well, have to say I had/have a success story with Ardupilot on BBBlue
image
Ask your particular q, I can try to answer. As for DTB, what and how you are using it is correct.
This DTB is outofthebox ready to go. in case of Ardupilot. In case of PX4 default version of librobotcontrol will not work, you have to install custom version or make quite simple change to PX4 code.

Hello @silentjet ,

Seth here. What change in the PX4 code would I need to change to make it work on the BBBlue?

I have actually had a terrible time on the BBBlue w/ ardupilot. I hung up my hat w/ ardupilot, i.e. as I could not grasp the idea.

Seth

I’m compiling both PX4 and AP on the board, thus there are compile-time errors. I also upstreamed the corresponding patch to librobotscontrol and it was accepted.

What kind of problems do you have with AP? SIGBUS ? :wink:

Hello,

I am not sure what you are saying. I mean, I understand, but why are you not cross-compiling PX4 or AP?

Oh and AP issues…it has been months, just three, since I relished in AP and the adventure of trying to make things work but!

I think the headers on the BBBlue for Servos where I would put the ESC connections were not understanding to turn on.

At least, the motors would not turn when I applied power and used the gimbals on the transmitter.

Seth

P.S. I will try to bring it up again and see…wait. I erased everything to do w/ AP. I got upset. I know…tiny me. But! I can try to set things up again.

Hello @silentjet ,

I think I put the P8_15 pru in use and not the P8_16 pru input in use when trying to get communication to the BBBlue.

I was going to register the P8_15 in the .dts file and then compile it but I am stuck at what exact register(s) need to be listed as arguments in the .dts file.

Seth

P.S.

                 
/* PRU encoder input */
0x038 0x36      /* P8_16,PRU0_r31_16,MODE6 */

I had it at the 4th encoder on the end which I think is P8_15 and not P8_16. Sheesh. Time to rewire something and compile. If you have any evidence of what I am describing, please try to reply at some point.

Because it is easier to develop even right on board :slight_smile: I mean I’m VIMer, so there is no difference for me where to use a console. And the only first compilation (or clean compilation) is quite long. Incremental ones are quite fast ^.^

As for AP, I had no such issues like what you are describing. As soon as I was able to load PRU firmware (in other case AP usually getting a crash) and calibration procedure finished and PWM is selected as a ESC control protocol it works like a charm.(well you still shall configure entire AP according to all guidelines in order to make ARM happen at all)

Why you are trying to do so? Out of the box DTS is ready to go. I was using Debian9 and I had no need to configure anything extra on a level of DTS. However, now I’m recalling that probably for AP there was a separate DTS, however it was bundled into the standart distribution… Hm… it was probably am335x-boneblue, or so…

Hello @silentjet ,

Why am I trying to do so? Well, I am assuming you mean why am I trying to change the .dts file for configuration.

I will answer. The reason I am trying to change the .dts file is b/c I already hardwired P8_15 and not P8_16 for pru input. So, I goofed up three years ago.

Seth

P.S. I will try again one day. If you are still around under this name, try to explain what you actually did to make it work (please). I have tried for years and notta. Nothing. Zip. Nilch. Zero.

Ok, I dig through my shelf and found a spare BBBlue, I can install and check what is wrong or is not working, but give me an exact description of your setup so i can repeat it…

1 Like

Hello @silentjet ,

Okay…I may not reply until later. I just wanted to update you. I have a bbblue on hand, it has an image that is bootable, and things, like apt, work now. I will install the AP source, if this is what we are talking about now, and then I guess we can discuss the PX4 source later.

Seth

P.S. I will update you on my image, my /boot/uEnv.txt file, and what exact AP config. I have soon.

In the meantime while things compile, I will make the wire available for the P8_16 instead of P8_15 like previously made.

Hello @silentjet ,

Okay…things are compiling on the board. I already made a cross-compile of the executable for arducopter but I want to make sure things are working on the BBBlue too.

So…it will be much later, i.e. as I am native compiling everything from ardupilot on the BBBlue.

Seth

P.S. I guess in the meantime, I can make my wire. I will update you soon.

Oh, I forgot about my other updates:

uname -a : Linux beaglebone 4.19.94-ti-r66 #1buster SMP PREEMPT Tue Aug 31 02:32:40 UTC 2021 armv7l GNU/Linux

and…

cat /etc/dogtag : BeagleBoard.org Debian Buster IoT Image 2020-04-06

and…here is the /boot/uEnv.txt file before rebooting.


#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.19.94-ti-r66
#uuid=
dtb=am335x-boneblue.dtb

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Ov                                                                                        erlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-I2C1-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo
uboot_overlay_addr6=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr7=/lib/firmware/BB-UART2-00A0.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/BB-I2C1-00A0.dtbo
#dtb_overlay=/lib/firmware/BB-UART4-00A0.dtbo
#dtb_overlay=/lib/firmware/BB-ADC-00A0.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

Hello,

A question about cross-compilation…

When compiling on another, non-armhf machine, would I need to call the correct compiler during compiling?

I am asking b/c I did use a Debian Distro that works but I am on an amd now and not armhf at all. So, my question is that idea but for some reason, I think this was my communication error when using upload and rsync after compiling on the non-armhf machine to install the executable on the BBBlue.

Seth

P.S. So, would I simply call the compiler in /usr/bin/ or the dir. in /usr/ called arm-linux-gnueabihf ? Anyway, if you know, please do reply. I am still testing things, i.e. so if when I can get a clean CC done, I will then reply.

@silentjet ,

It is too late to reply on your side of things, I am sure. So, when you get around to it:


● arducopter.service - ArduCopter Service
   Loaded: loaded (/etc/systemd/system/arducopter.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-09-18 04:55:58 UTC; 8min ago
  Process: 1612 ExecStartPre=/usr/bin/ardupilot/aphw (code=exited, status=0/SUCCESS)
 Main PID: 1618 (arducopter)
    Tasks: 7 (limit: 1026)
   Memory: 5.9M
   CGroup: /system.slice/arducopter.service
           └─1618 /usr/bin/ardupilot/arducopter -C /dev/ttyS1 -A udp:192.168.1.5:14550 -B /dev/ttyS2

Sep 18 04:55:58 beaglebone systemd[1]: Starting ArduCopter Service...
Sep 18 04:55:58 beaglebone systemd[1]: Started ArduCopter Service.

So, it seems it is working but I cannot turn on my receiver from the Servo Headers power and gnd. I am exporting a GPIO pin that is unusable, GPIO80, which seems to be an issue on my side.

Seth

P.S. I went into a QGroundControl software to check on things. Everything seems okay but I cannot export GPIO80 thus far. If you have any ideas, I can then proceed. If not, I will try a simple workaround but I would rather support powering the receiver(s) from the Servo Headers on the BBBlue if possible.

If P8_15 is not a pru input, I am thinking that this is a lost cause but…


&am33xx_pinmux {
	/***************************************************************************
	* Static Pinmux
	***************************************************************************/
	mux_helper_pins: pins {
		pinctrl-single,pins = <

			/* GPIO Inputs */
			0x09c 0x37	/*P8.9  Pause BUTTON, input pullup*/
			0x098 0x37	/*P8.10 MODE BUTTON input pullup*/
			0x1AC 0x37	/*P9.25 MPU-9150 INTERRUPT IN*/

			/* Motor Control GPIO Out*/
			0x088 ( PIN_OUTPUT | MUX_MODE7 ) /* (T13) gpmc_csn3.gpio2[0] - MDIR_1A different from cape! */
			0x074 ( PIN_OUTPUT | MUX_MODE7 ) /* (U17) gpmc_wpn.gpio0[31] - P9.13, MDIR_1B */
			0x040 ( PIN_OUTPUT | MUX_MODE7 ) /* (R13) gpmc_a0.gpio1[16] - P9.15, MDIR_2A */
			0x0D8 ( PIN_OUTPUT | MUX_MODE7 ) /* (V4) lcd_data14.gpio0[10] - P8.31, MDIR_2B different from cape! */
			0x0AC ( PIN_OUTPUT | MUX_MODE7 ) /* (R4) lcd_data3.gpio2[9] - P8.44, MDIR_3A */
			0x0A8 ( PIN_OUTPUT | MUX_MODE7 ) /* (R3) lcd_data2.gpio2[8] - P8.43, MDIR_3B */
			0x0A0 ( PIN_OUTPUT | MUX_MODE7 ) /* (R1) lcd_data0.gpio2[6] - P8.45, MDIR_4A */
			0x0A4 ( PIN_OUTPUT | MUX_MODE7 ) /* (R2) lcd_data1.gpio2[7] - P8.46, MDIR_4B */
			0x1B4 ( PIN_OUTPUT | MUX_MODE7 ) /* (D14) xdma_event_intr1.gpio0[20] - P9.41, MOT_STBY */

			/* PRU encoder input */
			0x038 0x36	/* P8_16,PRU0_r31_16,MODE6 */

			/* PRU Servo output */
			0x0e0 0x05	/*pru1_pru_r30_8, MODE5*/
			0x0e8 0x05	/*pru1_pru_r30_10, MODE5 */
			0x0e4 0x05	/*pr1_pru1_pru_r30_9, MODE5 */
			0x0ec 0x05	/*pru1_pru_r30_11, MODE5 */
			0x0b8 0x05	/*pru1_pru_r30_6, MODE5 */
			0x0bc 0x05	/*pru1_pru_r30_7, MODE5 */
			0x0b0 0x05	/*pru1_pru_r30_4, MODE5 */
			0x0b4 0x05	/*pru1_pru_r30_5, MODE5 */
			0x0C8 0x0F	/*P8.36, SERVO_PWR GPIO OUT*/

The last line 0x0C8 0x0F /*P8.36, SERVO_PWR GPIO OUT*/ of the above quoted text shows a GPIO OUT of P8_36. This seems like it is nice b/c it will power the Servo Rail/Header on the BBBlue.

It does not power my servo rail. I tried to call in scripts and .service files a .sh file that handles config-pin. I also tried to use echo to handle the PRU input pin(s). I changed the source in the .c file at https://github.com/silver2row/ardupilot/blob/master/Tools/Linux_HAL_Essentials/pru/rcinpru/rcinpru0.c on line 31 to handle P8_16. Wild guess there! Ha.

Anyway…these are the updates so far. I know this is elongated and boring to you since you got your drone up and running w/ the BBBlue. My receiver does not want to stay paired when P8_15 is connected to SBus output. But! Please let me know what you are thinking.

Oh and that line about the PRU input shows P8_16 as the PRU Encoder Input . I think it needs to be P8_15 but how? How could I account for the memory addresses and Hexadecimal 0x-- location(s).

Also, I checked the file system on the Debian Linux Distro I am using. I found little to handle my thoughts. My findings are little so far. I keep getting reverted to another section of the file system that does not make my findings any more authenticated.

Hello @silentjet ,

I got the binary on the BBBlue, the calibrations are done, and I have my set up/configs. done on the BBBlue to handle PRU input, turning on the Servo Headers for power, and for GPS.

My receiver is on and my transmitter is not showing any sign of motor movement.

Am I supposed to put the ESCs connectors to the Servo Headers on the BBBlue? Anyway…I know you are most likely busy.

But when…

  1. If you get up and running, please send over some type of config. set up.

and…

  1. Please show your /boot/uEnv.txt file too!

Seth

P.S. When I calibrated the ESCs, I was able to control the three-phase motors w/ ease but at no point afterwards did the motors move due to my transmitter gimbal maneuvers.

Hi,
So, the first thing to check is if you are receiving anything from your receiver. Use MissionPlanner and in Status tab check if following parameters are changing when you are moving your sticks on the radio: ch1in ch2in ch3in and ch4in. Where you’ve connected your receiver BTW ?

Am I supposed to put the ESCs connectors to the Servo Headers on the BBBlue?
Yes, exactly

On the image you can see my uEnv.txt
зображення

Hello,

Okay…I am using QGroundControl instead b/c of me not being able to install MP.

Besides that…I have kernel 4.19.x but the rest of /boot/uEnv.txt is the same but I do have some extras in there for whatever reason, i.e. GPS on UART2 and so on.

Also…I was able to cross-compile the binary/executable to the BBBlue for ArduCopter.

I will check my readings on QGroundControl and get back to you. I was able to calibrate my ESCs and perform the rest of the parameter functions in the calibration settings.

Seth

P.S. Do I actually need to have .dtbo files available for my peripherals and modules or is that taken care of currently w/ their source?

…QGroundControl…

From what I know QGC does not have similar functionality like monitoring variables, but you can still see channel values changing in Radio Calibration section…

Do I actually need to have .dtbo …

You do not need any additional dtbo, complete configuration is set in basic/primary dtb, at least serials and GPS’s i2c and spi plus all onboard sensors…

Hello @silentjet ,

Okay…this extra couple of .dtbo files may have been an issue on my side of things. I still need to test w/out the .dtbo files listed in /boot/uEnv.txt and then try to figure out how to install MP.

Something is wrong. MP will not install. I probably just need to restart or something.

In QGC, yes sir, the values change for MODE 1 and MODE 2.

Seth

P.S. I will test later tonight and then reply once I can assure to myself that it is receiving communication but not listening.