8.7 3/19/2017 Image Any reason why enabling robotics cape “sudo configure_robotics_dt.sh” causes the WIFI adapter to not work after a reboot connmanctl only show eth0 no usb or wif or bluetooth. copy back the uEnv.txt.bak and reboot and all works as expected. Is there something different in the hardware that causes the overlay to drop the wifi adapter.
Andy
I saw this https://github.com/StrawsonDesign/Robotics_Cape_Installer/issues/16 But thats from December would assume the fix made March Image.
I saw this
BeagleBone Green Wireless (wl18xx IRQ pin) and battery_monitor · Issue #16 · beagleboard/librobotcontrol · GitHub But
thats from December would assume the fix made March Image.
Assume what? We wave a magic wand and redesign the BBGW???
The BBGW and Robotic's Cape are not compatible. There is no software
fix for this.
8.7 3/19/2017 Image Any reason why enabling robotics cape "sudo
configure_robotics_dt.sh" causes the WIFI adapter to not work after a reboot
connmanctl only show eth0 no usb or wif or bluetooth. copy back the
uEnv.txt.bak and reboot and all works as expected. Is there something
different in the hardware that causes the overlay to drop the wifi adapter.
One of the I/O line's on the Robotic's Cape, knocks out the wl1835 irq
line. Thus on a BBGW, if you enable this cape, you'll lose "all"
communication with the wl1835.
The Robotic Cape is only compatible with the BBB, BBG, and BBBW.
Regards,
Thanks for the reply, Sorry from the post I thought the issue was just with the battery monitor code knocking out the Wireless and when I looked at the updated source code looked like that module was disabled if not Beagle Bone Black. I am not using his cape just trying to use his libraries. We already have a bunch of robotics chassis but with large motors that can draw as high as 6 amps so can’t use BB Blue as PWM pins don’t come out to pins. We already have 6 BBGW and drew up an expanded Grove Cape that brought out all the Robotics Cape Pins added servo pins etc into groups to go to our motor controllers etc.
So if I want to move forward using the Robotics Cape Code Base will it just be avoiding this one conflict pin or is there a lot of pins. In my case I have no battery monitor as not using his cape so easy enough to roll my own overlay and avoid this pin.
Any other gothcha’s between the Beagle Bone Green Wireless and the Robotics Capes that you know of?
Thanks for the Help as always.
Andy
So librobotic's uses dev mem and just takes that pin on load. We just
need to patch librobotic's on the bbgw to not take that specific pin.
(side note, i didn't even look on the robotic's schematic, it might be
a pin we can't redirect..)
Regards,
Am I reading the bbgw schematic correctly.
We need to exclude its use of
p8 Pins BBWG Robotics Cap
11 WL_SDIO_D1 QEB2B
12 WL_SDIO_D0 QEB2A
15 WL_SDIO_D3 PRU ENC A
16 WL_SDIO_D2 PRU ENC B
17 WL_IRQ BATT LED 1
18 WL_SDIO_CLK BATT LED2
If the robotics capes is using traditional two drive motor setup then only having two out of four encoders works. This fits my middle schoold kids robotics chassies. I do not need BATT LEDs on the board a simple red light on means low battery but honestly wireless means a socket connection tells me all I need.
Issues I see are PRU code is in assembly what happens if it trys to use a pin that it doesn’t have an overlay to. If we need to batch the pru assembly then assume we need a way to detect BBWG in the PRU assembly or set a bit in the shared memory to let it know not to use those PRU encoder pins. I haven’t dug into the libroboticscape code to see how the Batt LED pis are being used.
If there is a BB Blue Rev B in the works please ask them to conceder bringing the PWM pins out to pins or connector. I imagine the drone userswould want this as well as looks like they are using the servo outputs to drive there escs versus the PWM as they two need more then 1 amp motor controllers.
Can’t wait to see the Mip edu kits and a quad (hex? in pictures only 4 motor outputs?) copter kit.
My fork is located here. https://github.com/Andrewiski/Robotics_Cape_Installer
Library compiles and I think I have the model detected and the pins excluded even in the pru0 but stuck on compiling my new overlays so I can test.
Doing something stupid here I am sure but have never had to compile an overlay before.
in install.sh
echo “dts building the BBGW overlay”
cp device_tree/am335x-roboticscape-bbgw.dtsi /opt/source/dtb-4.4-ti/src/arm/am335x-roboticscape-bbgw.dtsi
cp device_tree/am335x-bonegreen-wireless-roboticscape.dts /opt/source/dtb-4.4-ti/src/arm/am335x-bonegreen-wireless-roboticscape.dts
dtc -o “/boot/dtbs/$UNAME/$TREE_BBGW_RC” -O dtb -i “/opt/source/dtb-4.4-ti/src/arm” /opt/source/dtb-4.4-ti/src/arm/am335x-bonegreen-wireless-roboticscape.dts
keep getting
Error: am335x-bonegreen-wireless-roboticscape.dts:18.1-9 syntax error
FATAL ERROR: Unable to parse input tree
even if I try to compile an existing dts in this folder.
this padawon is in search of help from the master
I believe I have all the bugs worked out in my fork (https://github.com/Andrewiski/Robotics_Cape_Installer) of RoboticsCape Library for the BBGW. End up losing 2 of the motor encoders, All the Battery LEDs and SPI and had to move MDir1a to a different pin. To be clear you can’t use the Robotics Cape as USB headers are int he way so can’t attache Cape but I am using the library and wiring directly to encoders. The point of this was to reuse BBGW hardware I already have but allow my development to work on BBBW and Blue as we purchase new hardware.
Updated List of Conflict Pins that I found on BBGW are as follows
Pin BBWG Robotics Cape
P8_11 WL_SDIO_D1 QEB2B
P8_12 WL_SDIO_D0 QEB2A
P8_14 WL_EN BAT_LED_4
P8_15 WL_SDIO_D3 PRU_ENC_A
P8_16 WL_SDIO_D2 PRU_ENC_B
P8_17 WL_IRQ BATT_LED_1
P8_18 WL_SDIO_CLK BATT_LED_2
P8_26 WL_Level_Shifter_OE BATT_LED_3
P9_12 BT_EN MDIR_1A
P9_28 BT_AUD_IN SPI1_CS0
P9_29 BT_AUD_FSYNC SPI1_D0
P9_30 BT_AUD_OUT SPI1_D1
P9_31 BT_AUD_CLK SPI1_SCLK
P9_41 WL_SLOW_CLK MOT_STBY