RC input not working with SBUS

[rflowers]

@mirkix Thankyou very much for your amazing work on this project.

Unfortunately currently the build instructions do not work with SBUS RC controllers, the signal is not detected by ardupilot.

I have checked the output from my receiver with a scope verified that it is producing a signal, so the electronics appear good but this is not detected by ardupilot or the rcin examples test code. My best guess is that the recent device tree alterations in Linux have broken the installation code to install the PRU firmware and setup the pinmux (all the ardupilot examples I can find use the old cape manager format and give errors in the new device tree format). I have followed your instructions on a brand new beagleboard and patched with your latest patch and still cannot get any rc signal into ardupilot.

I’ve managed to get Hello world PRU code working to test PRU installation and decompiled the dtbos accessed in install.sh of Linux Hal Essentials in the hope of manually installing them as a workaround, no joy yet

I have tried the pre-compiled arduplane, but it doesn’t appear to install the firmware or setup the pinmuxing (which from reading the Linux HAL essentials appears to need to be set up separately), I have also compiled ardupilot from source on the bbb in case it was hidden in the source, apparently no change, my best guess is that the install.sh script needs to be run on the target bbb to enable the prus to read the receiver signal.

currently config-pin -q on P8:15 (the multi-function pin) gives cape not found, but can be manually set to the correct value (pru in or pru ecap I guess, based on similar terms in your ardupilot service script, which also appears to have been broken by the update).

Any work arounds you could suggest to get rc input working would be great. Any diagnostic code would also be very helpful.

Thank you for your time.

[mirkix]

@rflowers What kind of RC receiver do you use?

[rflowers]

frsky x8r receiver paired with taranis controller.

[rflowers]

ok I’ve been trying to resolve this. Robert C Nelson is currently doing some work with the beagleboard overlays, which is improving the config-pin functionality. The problem breaking the pru installation appears to be in the tools/linux hal essentials/startup script, this doesn’t support the new ocp style configuration, despite being normally required to be run once on the bbb to install firmware.

@mirkix, how does your bbblue implementation install aiopru on the bbblue? I notice it isn’t listed in the instructions. Is this implemented another way or is this an oversight. Is there anyway to check it is correctly configured with a command or script?

Thanks in advance

[rflowers]

Ok I have resolved the immediate issue by means of following the instructions in the Linux HAL essentials section and Aiopru subsection. specifically the install.sh no longer works, however running make install in the devicetree/pxf subfolder followed by these instructions:

Enable loading cape during BBB startup (no need to follow above step if you do this step once): cp BB-PXF-01-00A0.dtbo /lib/firmware add cape_enable=capemgr.enable_partno=BB-PXF-01 to /boot/uboot/uEnv.txt add CAPE=BB-PXF-01 to /etc/default/capemgr

and then the instructions for pru/aiopru.

This has allowed me to get the RcAioPRUTest code in aiopru to work with my controller, and also the RC_Channel and RCinput tests in examples to see the channel values.

I appreciate this isn’t a clear solution, some steps may be unnecessary and it is not yet working with ardupilot proper, but it seems the pru installation, at least for rc input is now working properly.

@mirkix @RobertCNelson do you have any thoughts/observations? I am happy to write this up and help out, to make the bbb easier to use with RC.

[mirkix]

@rflowers BB-PXF is for an outdated Cape not the Blue or BBBmini. AioPRU Firmware is loaded here https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL_Linux/RCOutput_AioPRU.cpp#L57 inside ArduPilot. I am using X8R without a problem. How do you config the PRU ECAP pin?

[suz1]

this is what I currently get with config-pin, it is set to pruecapin_pu.

config-pin -i P8:15 Pin name: P8_15 Function if no cape loaded: gpio Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin Function information: gpio1_15 default gpio1_15 gpio1_15 gpio1_15 gpio1_15 eqep2_strobe pru_ecap pru0_in15 Kernel GPIO id: 47 PRU GPIO id: 79 debian@beaglebone:~$ config-pin -q P8:15 P8_15 Mode: pruecapin_pu debian@beaglebone:~$

thanks. Is there any other information I can supply - logs, dumps etc? I'm running 4.4.113-ti-rt-r146 kernel.

[rflowers]

ok I am lucky enough to have a second b.b. to experiment with, so I have kept my semi-working b.b. installation and attempted to replicate it on the second using your instructions. I can read the rc input on pin e4 with code such as rcinputtorcoutput in linux_halessentials on my working one, but it is not getting the information to rc_channel, which to my understanding is the next level before ardupilot properly receives the inputs. On your implementation none of this code works.

I can see your implementation of the PRU code in rcoutput, this doesn’t work on my b.b., I cannot tell why, and because of this style of implementation, none of the diagnostic tools work, even when the electronics can be demonstrably correct. I am mainly using arduplane rather than arducopter, but the issue appears common to both.

I notice jason kridner @jadonk has a fairly extensive setup.sh for his b.b. arducopter build - https://gist.githubusercontent.com/jadonk/6080ca92d6e225eb89d33ad7744e1775/raw/4b3a7010f6d0b24647ded2f1ed1b45bcad1539c8/ardupilot_setup.sh which uses the devicetree method, and I wonder if there is anything in there that might ease the installation instructions so that future users might have a simpler time getting this working. Please let me know your thoughts.

[rflowers]

Ok I have now got SBUS working. However of my 2 bbs, both of which I followed the detailed instructions at https://libraries.io/github/mirkix/ardupilotblue, which give more setup info than this more popular, though apparently less up to date documentation. The problem I had was even though both had the same script, the device tree installation worked fine on one, and not on the other. I believe the disparity is due to a number of different scripts for the device tree, some using uio_pruss, on the successful board. They set something underlying correctly, and that board now works, whereas the other board doesn’t. So unsatisfying and the installation instructions do not appear comprehensive. My work around has been imaging the successful one onto the other one to copy the kernel setting or whatever, as unfortunately I’m out of time. If I can find a better solution I’ll post it on a blog or similar to help the others struggling with this problem. Hopefully the device tree rewrite for bb (currently underway) can fix this problem long term.