USB on BBB and BBAI-64

Hello Again,

Are the USB ports on the BBB and BBAI-64 working as intended? I mean…

I have a SDK that I am trying to compile and I remember reading here in the forums about USB devices not working properly or something along those lines of ideas.

I was not sure if it was a BBB thing or an overall beagleboard.org idea that seemed to not make the USB devices work.

Seth

P.S. Any insight or ideas of this entity may help me decipher if it is the SDK or the USB device on the BBB/BBAI-64 boards. I am in the compilation phase now and vaguely remember something where specific users were having trouble with the USB port on the boards.

Please post the sdk you are using, assuming it is c/c++.

1 Like

@foxsquirrel ,

Seth here. I am using this one:

It is some UART over USB type of SDK, i.e. I think. I have used it before today but recently, maybe from their changes in it a while back or without them updating it, the SDK for their Servos has not compiled correctly.

Seth

P.S. I can access the servos via their source on the Wizard 2 they produced for altering the state of the servo(s). Anyway, trying to compile here and receiving this error when compiling:

collect2: error: ld returned 1 exit status
make: *** [Makefile:68: libdxl_sbc_c.so] Error 1

I am not sure what this error entails or discussed on either board but both the BBB and BBAI-64 show the same error. pkg-config?

you will probably need to look further back in the compile output to find the actual error

1 Like

I found some resources on this error and it seems something is not right so far. I will keep up my findings.

Seth

P.S. If it matters, here is the output:

mkdir -p ./.objects/
g++ -shared -fPIC  -o ./libdxl_sbc_c.so ./.objects/group_bulk_read.o ./.objects/group_bulk_write.o ./.objects/group_sync_read.o ./.objects/group_sync_write.o ./.objects/packet_handler.o ./.objects/port_handler.o ./.objects/protocol1_packet_handler.o ./.objects/protocol2_packet_handler.o ./.objects/port_handler_linux.o -lrt
/usr/bin/ld: ./.objects/group_bulk_write.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: multiple definition of `packetData'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: first defined here
/usr/bin/ld: ./.objects/group_bulk_write.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/group_bulk_write.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/group_sync_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: multiple definition of `packetData'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: first defined here
/usr/bin/ld: ./.objects/group_sync_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/group_sync_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/group_sync_write.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: multiple definition of `packetData'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: first defined here
/usr/bin/ld: ./.objects/group_sync_write.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/group_sync_write.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: multiple definition of `packetData'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: first defined here
/usr/bin/ld: ./.objects/packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/port_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/port_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/protocol1_packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: multiple definition of `packetData'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: first defined here
/usr/bin/ld: ./.objects/protocol1_packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/protocol1_packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/protocol2_packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: multiple definition of `packetData'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/packet_handler.h:82: first defined here
/usr/bin/ld: ./.objects/protocol2_packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
/usr/bin/ld: ./.objects/protocol2_packet_handler.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/port_handler_linux.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: multiple definition of `g_used_port_num'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:47: first defined here
/usr/bin/ld: ./.objects/port_handler_linux.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: multiple definition of `g_is_using'; ./.objects/group_bulk_read.o:/home/debian/DynamixelSDK/c/build/linux_sbc/../../include/dynamixel_sdk/port_handler.h:48: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:68: libdxl_sbc_c.so] Error 1

This basically means nothing to me so far. I will need to read up and look through each file.

$sudo apt install pkg-config

Make sure it is installed

Then

$cd /usr/
$find -name *.pc

This will show all the pkg-config files.
Since it mentions that in the error it would be linking error, either a .so or .pc file(s) is missing.

If you are using cli g++, then make sure you are linking. That will be -l<name>. For example -lpthread.

To use pkg-config

g++ -o output main.cpp `pkg-config --libs --cflags <lib name goes here>`

Note, those are back-tics used for direct substitution of the return values when pkg-config is called, not apostrophes.

1 Like

@foxsquirrel ,

I installed the pkg-config repo. lib. and it compiled earlier in the day but only for g++/C++.

I think the python3 source compiled too. I need to double check what actually took place. Also, the C/gcc compilation is a fail all around. So, I may have to rekindle C++ and Python3 ideas for source scripts.

Updates on the way!

Seth

P.S. Thank you for the g++ command line with arguments with pkg-config. I will test it soon with C and see where I stand. You will most likely hear from me again…

$mkdir delete
$cd delete
$git clone https://github.com/ROBOTIS-GIT/DynamixelSDK.git
$cd DynamixelSDK/
$git checkout -b my-branch
$cd c++/build/
$ls
$cd linux64
$make 

It did produce a .so and it has some gcc warnings, must not have been too bad it produced the .so

fred@vm10:~/delete/DynamixelSDK/c++/build/linux64$ ls
libdxl_x64_cpp.so  Makefile

Also, it is best if you light up a VM and test there because make install will actually install and if you don’t want it around its hard to get rid of.
When you are ready to install in the path

$make install
1 Like

Oh!

You got the C++ lib to build for aarch64? Odd…I can see C++ libs. of the SDK being built on the BBAI-64 itself but under linux_sbc instead of linux64. That may be the precursor to something:

  1. Making their “new” SDK work like new.
  2. Utilizing what I currently have in stock to make neater, more renowned things.
  3. Thank you…

Seth

P.S. When you say, VM, are you saying to cross_compile the SDK lib. with the C++ libraries and then smash it on the BBAI-64 instead?

g++ <your code.cpp> -ldxl_x64_cpp -o <my file name>
1 Like

Wozzers. Just like that?

Nice…

Seth

Yes, it is so much easier to do native builds. I remote into the target for random tests to make sure it still builds. Try to work mostly on the host since it is several orders of magnitude faster than target boards.

1 Like

Well, I don’t know what is going to happen. I just got a .so from the sdk and that is as far as I went.

That makes sense. @foxsquirrel , just for background here…

I am the most patient person. I was using the BBB for a long time to boot, sign in, compile, and then edit source.

I would just use it for that purpose alone mostly. I got to learn source scripting and editing a bit better because it was slower. The sub 1GHz can produce or did. Do not get me wrong here…

I liked what I was doing. I only found specifics at times on how to cross_compile specific source and since I am a lacky of a Windows abuser, I only go to Linux to really mean it when scripting.

Seth

P.S. Background out of the way! Onto scripts!

And A-Okay about not testing the .so usage and building. I have the hardware with me. So, I do not expect you to attain it for these purposes. Thank you again…

1 Like

You will get farther ahead and your blood pressure will be lower using Debian or Ubuntu. Also, CLion (paid version) will let you remote into your board. It is way better than messing around with a toolchain, don’t get me wrong a toolchain is fine, just doing it native is much simpler. All we have at home and work is 99% linux and only a few windows boxes for stuff that is only available on windows.

1 Like

That makes 100% of sense. No wonder. No wonder I have been patient. A little too patient in time created a parting. Anyway, long story short here…

I went to the Robotis Forum too. I wanted to see if they had any others that were proclaiming things were not working as stated…

Does the -fcommon flag in a Makefile seem legitimate for the build process in this subject?

I am asking because the people at Robotis seem to know of others who have had some issues which I am describing.

Seth

P.S. They are using gcc 9.4.x to build their SDK I think or at least they did use the v9.4.x when the error from the last person who wanted support got it.

Off to look up the -fcommon flag.

-fcommon did it. The C/C++ files are being cross_compiled easily!

Seth

P.S. I looked up -fcommon to no avail. It is of gnu gcc or something from what I read but I cannot find any naming schema for it.

Without make install, the .so file does nothing.

And without sudo, I cannot use make install. Blah. Up a creek now!

Seth

P.S. Sir/Ma’am, any words of wisdom?

One Last Trial Reply,

I will do my best to not reply unless you say something else to me. Anyway…

So, I got the DYN.c file compiled within the SDK library /DynamixelSDK/c/src/dynamixel_sdk/DYN.c but this was unintentional due to switch-a-roos within the SDK in question.

Anyway, I will attempt to put the file(s) in /DynamixelSDK/c/example/protocol1.0/DYN.c instead so I can utilize the SDK instead of make the DYN.c file part of the SDK. Oops!

Seth

#apt install sudo