View Full Version : [Question(s)] Moving more to the Raspberry Pi

08-11-2015, 07:09 AM

I'm currently running my Hexapod with a modified version of the Phoenix code on an Arbotix-M being fed commands via the serial port from a Raspberry Pi 2.

As part of the next phase of the project I'm trying to simplify the hardware and remove the Arbotix-M and run the Phoenix code on the RPi2 with a USB2AX.

Once again KurtEck has done the hard work and kindly made available the RPi2 Phoenix code. When trying to install it however I keep hitting the errors below when executing "make". I've now run out of ideas on how to resolve, so any assistance would be much appreciated.


[email protected] ~/git/Raspberry_Pi/Phantom_Phoenix $ make
cd ../library; make
make[1]: Entering directory '/home/hexy/git/Raspberry_Pi/library'

-------- begin --------

cc (Debian 4.6.3-14+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

-------- end --------

make[1]: Leaving directory '/home/hexy/git/Raspberry_Pi/library'
cd ../BioloidEX_Usb2Ax; make
make[1]: Entering directory '/home/hexy/git/Raspberry_Pi/BioloidEX_Usb2Ax'

-------- begin --------

cc (Debian 4.6.3-14+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

-------- end --------

make[1]: Leaving directory '/home/hexy/git/Raspberry_Pi/BioloidEX_Usb2Ax'
make -f makefile_PhantomX
make[1]: Entering directory '/home/hexy/git/Raspberry_Pi/Phantom_Phoenix'

-------- begin --------
cc (Debian 4.6.3-14+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

arm-linux-gnueabihf-g++ -Wall -pedantic -g -O2 -fno-rtti -Wno-write-strings -I. -I../library -I/usr/include/espeak -I../BioloidEX_Usb2Ax Phantom_Phoenix.o Phoenix_Code.o Phoenix_Driver_AX12.o Phoenix_Input_Commander.o -o Phantom_Phoenix -L/usr/lib/arm-linux-gnueabihf -L../library -L../BioloidEX_Usb2Ax -L../library -lpthread -lespeak -lBioloidEX -lArduinoPort -lpthread
/usr/bin/ld: ../library/libArduinoPort.a(Wiring.o): undefined reference to symbol '[email protected]@GLIBC_2.4'
//lib/arm-linux-gnueabihf/librt.so.1: error adding symbols: DSO missing from command line
collect2: ld returned 1 exit status
makefile_PhantomX:73: recipe for target 'Phantom_Phoenix' failed
make[1]: *** [Phantom_Phoenix] Error 1
make[1]: Leaving directory '/home/hexy/git/Raspberry_Pi/Phantom_Phoenix'
makefile:20: recipe for target 'Phantom_Phoenix' failed
make: *** [Phantom_Phoenix] Error 2

08-11-2015, 08:48 AM
Hi, sorry I was away for a couple of days, but am back now :D

I will take a look. It has been awhile since I build for RPI, but will try to fix ASAP...

A week or so ago, I ran into some similar issue and needed to change around the order in which I included libraries.
I think I fixed that one by, simply adding another -lpthread at the end, but this looks like it already has it...


Update: You are currently building the PhantomX directory, which for some reason is not linking. This directory should be functionally equivalent to building the directory: phoenix_fixed/PhantomX, which currently does link properly on my RPI2. I will compare the two directories again, especially make files to see what the differences are...

08-11-2015, 10:06 AM
I uploaded an updated makefile that hopefully should work. At least it links now on my RPI2 on the HROS1...

The main differences was adding in -lrt

08-11-2015, 06:33 PM
Thanks Kurt,

I'll give it a try after work tonight.

Just checking I'm using the right code on the USB2AX - have you been running this firmware on the USB2AX when running this Pi code?: lufa_usb2ax (https://github.com/KurtE/usb2ax/tree/master/firmware/lufa_usb2ax) from KurtE (https://github.com/KurtE)/usb2ax (https://github.com/KurtE/usb2ax)?


Update: Makefile now works great thank you. Only problem is that it's not recognising the servos as below. I've run out of time tonight but will try and debug tomorrow.

[email protected] ~ $ ./Raspberry_Pi/Phantom_Phoenix/Phantom_Phoenix
device open error: /dev/ttyACM0
0 0 0
Program Start
Servo(0): 8 not foundServo(1): 14 not foundServo(2): 2 not foundServo(3): 7 not foundServo(4): 13 not foundServo(5): 19 not foundServo(6): 10 not foundServo(7): 16 not foundServo(8): 4 not foundServo(9): 9 not foundServo(10): 15 not foundServo(11): 3 not foundServo(12): 12 not foundServo(13): 18 not foundServo(14): 6 not foundServo(15): 11 not foundServo(16): 17 not foundServo(17): 5 not foundServo(18): 20 not foundServo(19): 21 not foundERROR: Servo driver init: 20 servos missing
Open Failed
Voltage: 65535
Voltage went low, turn off robot 65535
Arduino Phoenix Monitor

08-12-2015, 10:13 AM
Hi Andrew,

I almost missed your update.

At some point soon, I need to take a pass through my rpi project and clean some stuff out and also probably back track a little bit.

In particular: I have two versions of the BioloidEx library as part of the project. One of them assumes that you are running with an UsB2AX that has updated firmware that has the interpolation code moved in to it. The other is setup to use the generic USB2AX and does not require updates.

Earlier on I was mainly setup to use the updated firmware version, hoping I could get this type of functionality added to the official USB2AX functionality. But as I don't think this is likely to happen, I have started to back off and setup to use the default firmware.

My most recent one I played with is in phoenix_fixed directory stuff and in particular in the phoenix_fixed\PhantomX_joy directory where I am now using the straight bioloidex directory where the phantomX is using the bioloidex_usb2ax which is updated firmware).
Note: I added the interpolation stuff into the straight bioloidex directory that uses a secondary thread to take care of it, so it does not require the sprinking of calling off to the library for the interpolation like the Arbotix code required.

Note: the PhantomX_joy - code is a version I setup to use to allow me to use the Linux Joystick drivers. In particular I have it setup to handle Sony playstation 3/4 (DS3/DS4) controllers. There are some issues with these controllers and Bluetooth, but have them working on ODroids. i have also started to play with my joystick code on RPI as well, as I am porting it to the HROS1 code base.

What I have not done yet, is to update the starting phoenix_fixed\PhantomX directory to use the same version of BioloidEx. Should not be hard, just probably need to update makefile to point to different library and maybe some defines... Maybe I should try it out soon. Need to dig out an XBee..

But as a head start you might look at this phoenix_fixed directory structure and in particular look at the two makefiles I mentioned.

I will try to get some time in the next day or two to update the files and setup an XBee and use the Commander.


08-12-2015, 12:48 PM

I had a go at updating the makefile as you suggested and will give that a try when I get home from work later today.


08-12-2015, 02:19 PM

I updated the Phoenix_fixed\PhantomX plus the Phoenix_fixed\PhantomX_Joy as well as the Phantom_Phoenix branch to now not use the USB2ax code that was updated. I also verified I have the code in place to free up the servo driver.

I tested this with an Xbee and it does still properly talk to the Commander


08-13-2015, 04:56 AM

The revised files compiled no problem and I can see the servos at start up, so good progress. Now to work on the XBEE commander connections.

Two traps that caught me out for a few minutes:
1 - I hadn't set my user up as part of the dialout group needed by the USB2AX, and
2 - There are two extra servos 20 & 21 in the base code, so needed to comment them out too.


08-13-2015, 06:14 AM
Woo hoo

Jim Bob is back up and running using the RPi2 and the USB2ax. Thanks for your help in getting to this point Kurt.

Now it's onto getting the navigation code to work with the new config.

08-13-2015, 08:13 AM
Great to hear you are up and running again!

On your last few things, I should check and make sure I mention dialout group in my readme... (Also should rework that file at some point to be in some logical order).

As for the Turret (Head) servos, you obviously figured it out, but you simply need to go into the hex definition file and comment out or delete the line that defines: cTurretRotPin

Will great to see what you get working next!


09-09-2015, 10:25 PM
I've been running the Phoenix code on my Hexapod using two different configurations over the past three weeks. The first configuration is running both a Raspberry Pi2 and and Arbotix-M, the second with the Raspberry Pi2 alone. In both configurations Python code has been use to take information from a group of sensors and drive the Hexapod in a semi- autonomous manner. Both configurations worked reasonably well, but each had pros and cons that I thought I'd share below:

Configuration One: RasperryPi2 running KurtE’s port of the Phoenix code and some custom Python code to read sensors and control the Hexapod movements.

· Only one controller to set up and maintain
· Allows richer data flow between the Phoenix code and the controlling python code
· Easier to debug c.f. having code still on the Arbotix-m
· Small improvement in power consumption
· Takes up less space
· Prone to occasional stutters and glitches in movement
· Need to carefully consider the impact on the movement processes when running other threads or processes on the Pi2

Configuration Two: Arbotix-M running KurtE’s port of the Phoenix code (slightly modified to run on servos numbered 2-19 as does the Raspberry Pi version) along with the RasperryPi2 running some custom Python code to read sensors and control the Hexapod movements. Communicating via a serial connection.

· Smother, more realistic movements
· Generally don’t need to worry too much about timing on the Pi2
· Takes up more space
· Need to establish physical link between the RPi2 and the Arbotix-m
· Opposite of pros under configuration one

Both configurations worked fine, but the good timing abilities of the Arbotix-m did result in a noticably smoother and less glitchy movement.

09-10-2015, 09:03 AM
Sounds like you are having some fun! In the RPI only mode what are you using to talk to the actual servos?

What my personal preference is to do something in between. That is I would like most of the code to run on the Linux box. I personally prefer all C/C++ but...

I then like having the secondary processor (Arbotix, USB2AX, Teensy 3.1, ...) take more care of the timings as these processors are more setup to handle timing critical things...

That was why for example most of the time earlier I used my updated firmware for the USB2AX, which moved the Interpolation code from the Linux box to the servo processor. You could tell it, to move these N servos to the new positions and do it in N milliseconds. It would then take care of deciding when to issue the serial outputs to the servos and how often... Also I had this code only output information for those servos who actually move with each interpolation step, and try to take into account how many bytes will be output for each servo transaction as to time when the checksum byte is output to be as exact as possible for the servo rate... I don't think you can do that type of timings, when you are going through USB where you may have other stuff going on with USB, let alone interaction with the scheduler...

Again I had this working pretty well, but also want(ed) to take it one step farther and have it such that I can also queue up the next move while the servos are still moving on the previous move. That is the command would say, when you finish the current move, then move to these new positions. This would remove any delays during the transition from one step to next... I am hoping to experiment some more with this hopefully sometime soon, probably with a Teensy 3.1, where I may start off trying to emulate the Arbotix Pro and then add this level of support.

Also another place the earlier code was getting into walking issues, is the timing interactions between doing things like trying to walk with the interpolation code issuing the SYNCWRITE and other code that may want to query information, like what the current battery voltage is. The current code tries to make sure to schedule these types of calls at times when it won't interfere, but could still be issues.

Let me know if you find any bugs or have some enhancements that I can integrate back in.

Nice write up!

09-10-2015, 12:27 PM
In the RPI2 only mode I'm using the USB2AX to connect to the servos. I should have noted that in my post, so I've made a quick edit.

Apart from changes to the Phoenix_Input_Commander code to read commands from the Python code, the RPI code is largely unchanged.

My favourite recent enhancement was the change you made to renumber the servos 2-19, so I attempted to carry those changes through to the Arbotix-M version, so far this seems to be working but I've yet to fully test.