I don’t get any power on the GPS port. Any reason for this? Am I missing something?
Going to answer my own stupid question. No 5 volts because I was powering the board through usb.
Hello,
BeagleBoneBlue configuration is going forward.
Few problems with rc.local, solution with systemd and creation of a service.
Initial problem (rc.local not working) may be due to syntax error in the wiki rc.local example:
/bin/sleep 10
/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_21_pinmux/state
/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_22_pinmux/state
/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state
/home/debian/arducopter -B /dev/ttyO2 -C /dev/ttyUSB0 > /home/debian/arducopter.log &
When running it, I have an error with :P8_15_pinmux/state:
Sep 12 13:45:21 beaglebone rc.local[1075]: /etc/rc.local: 17: /etc/rc.local: cannot create /sys/devices/platform/ocp/ocp:P8_15_pinmux/state: Directory nonexistent
May be it is due to \ missing before :P8 (could be ocp/ocp:P8_15_pinmux/state)
(I removed the line from rc.local).
Marc
Hi @mirkix,
I can not control the motors with the S.Bus signal from a FrSKY X8R, neither running your ready compiled Ardupilot file nor running “rc_test_servos -r” command. I have updated all, both GND are connected, I have seen the signal with an oscilloscope and apparently there is nothing strange (I can watch how a pulse width changes while I’m moving a stick). Actually the classical outputs of the X8R are working.
The S.Bus signal is interpreted by one PRU, isn’t it?. I am supposing that the loaded firmware on PRU isn’t correct. Could it be possible?. If you want I can copy the result of running $dmesg | grep pru.
Vielen Dank,
Gabriel
if the signal on your receiver exceeds 3,3v , is there a work around I am purchasing a transmitter and receiver at the end of the month and a couple of the receivers i’ve seen operate 4v -6.5v thanks.
@chris33 You can use a simple voltage divider https://learn.sparkfun.com/tutorials/voltage-dividers/all?print=1 .
For those of you who want to use the stock debian install on the BBBlue and arducopter / ardurover / etc, I’ve created a systemd config file that works well. I built a 450mm framed quad, initially with a bbbmini, but once I saw the blue, I switched to that. Very nice! Everything is working fantastic, want to pass along what I’ve learned and say thanks to Mirko for the fantastic work!
Here’s the arducopter.service and arducopter defaults files, adapt it as needed.
/etc/defaults/arducopter
TELEM1="-C /dev/ttyS1"
TELEM2="-A udp:192.168.100.22:14550"
#TELEM2="-C /dev/ttyAMA0"
GPS="-B /dev/ttyS2"
# Options to pass to ArduCopter
#ARDUCOPTER_OPTS=$TELEM1 $TELEM2
# -A is a console switch (usually this is a Wi-Fi link)
# -C is a telemetry switch
# Usually this is either /dev/ttyAMA0 - UART connector on your Navio
# or /dev/ttyUSB0 if you're using a serial to USB convertor
# -B or -E is used to specify non default GPS
/lib/systemd/system/arducopter.service
[Unit]
Description=ArduCopter Service
After=networking.service
Conflicts=arduplane.service ardupilot.service ardurover.service
[Service]
EnvironmentFile=/etc/default/arducopter
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_21_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_22_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_24_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo uart > /sys/devices/platform/ocp/ocp:P9_26_pinmux/state"
ExecStartPre=/bin/bash -c "/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state"
ExecStart=/usr/bin/ardupilot/blue-arducopter $TELEM1 $TELEM2 $GPS
Restart=on-failure
[Install]
WantedBy=multi-user.target
1 Like
I’ve seen a few new cape updates come through apt-get, did one of them happen to be enabling the ADC and related connections on the BBBlue? I’d really like to be able to hook my 3dr power module. 
If not, it’s been a while since I’ve poked around the dts files, but I’ll take a stab at it. I know just enough to be dangerous! 
@croadfeldt No, this is not DTB related. It has something to do with the memory map of the Robotics Cape Software.
Hi, I am having the same problem with S.Bus. Have you found a solution?
I have got taranis qx7 transmitter and x8r receiver. the receiver is connected to beaglebone blue with sbus signal pin to E4 pin 4. the ground is also connected so the level is same. Before connecting I tested the connection by attaching the conventional channel output 2 to servo and checking with radio and everything works. I put oscilloscope on sbus and can see the signal and can also see the signal at pin 4 E4 but when I run the test code with ‘sudo /home/debian/RCInput’, I do not see the output, neither can I see any output with the ardurover after running the code . I have no problem with GPS or IMU.
Hello,
Looks like the PRU is not enabled
Have you added the following line in the /etc/rc.local
/bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state
1 Like
Thank you @ppoirier ,
That indeed was the problem. Added that to the routine and everything works just fine, for now 
@arjunbais It’s good to know that you have already solved the problem. My problem wasn’t the same. I had forgotten to change the file permission 
Hello BeagleBone Blue folks. I do not think I will ever use my new Beagle Bone Blue. Too many APs and I am just going to use Navio2 right now. If anyone (US only please) wants to buy it please shoot me a message. Also has a 3D printed case with it and the original box.
Hello, please explain ‘‘to many AP’’
Well I could also say I am juggling too many APIs but I really meant too many Auto Pilots! I look at my lonely BeagleBone Blue and realize it needs to be free and in the wild somewhere.