View Full Version : Trying to debug HROS1 with RPI talking to Arbotix Pro

09-10-2015, 07:45 PM
I am sort of curious on how many people are using the RPI2 versus the Edison and I wondering about how well the Arbotix Pro is talking to the the Raspberry PI.

When I try to run some of the different project programs, such as the PS3 demo as well as the DXL manager, probably over 50 percent of the time when I try to run one of these programs, the system fails to initialize properly and errors out. Example:

[ID:200(SUB_BOARD)] ^[email protected] ~/HROS1-Framework-Kurte/Linux/project/dxl_monitor $ ./dxl_monitor

[Dynamixel Monitor for DARwIn v1.00]
Failed to connect CM-730!
Terminated DXL Manager.
[email protected] ~/HROS1-Framework-Kurte/
If I try to run it again it often will work. I am pretty sure it is a timeout issue.

Likewise most of the time I can not reliably switch to different IDS. For example:

[email protected] ~/HROS1-Framework-Kurte/Linux/project/dxl_monitor $ ./dxl_monitor

[Dynamixel Monitor for DARwIn v1.00]

Check ID:5(R_ELBOW) ... OK
Check ID:6(L_ELBOW) ... OK
Check ID:7(R_HIP_YAW) ... OK
Check ID:8(L_HIP_YAW) ... OK
Check ID:9(R_HIP_ROLL) ... OK
Check ID:10(L_HIP_ROLL) ... OK
Check ID:11(R_HIP_PITCH) ... OK
Check ID:12(L_HIP_PITCH) ... OK
Check ID:13(R_KNEE) ... OK
Check ID:14(L_KNEE) ... OK
Check ID:15(R_ANKLE_PITCH) ... OK
Check ID:16(L_ANKLE_PITCH) ... OK
Check ID:17(R_ANKLE_ROLL) ... OK
Check ID:18(L_ANKLE_ROLL) ... OK
Check ID:19(HEAD_PAN) ... OK
Check ID:20(HEAD_TILT) ... OK
Check ID:200(SUB_BOARD) ... OK

[ID:200(SUB_BOARD)] id 1
[ID:1(R_SHOULDER_PITCH)] wr 30 400
Fail to write!
Invalid ID(2):4!

The first set of id works, I am also able to write to servo, but then if I try to switch to different ID it most often fails.
I updated the code to print out error code (4), which is timeout.

Looking at the underlying code, it tries to switch servos by doing a ping of it. The ping is failing. The underlying code that ping is calling, sets a timeout of 2* (length of ping packet)*time_to_send_a_byte + 5 ms.

I am not sure how this equation was decided on. It looks semi-reasonable to me if I was talking directly to the servos locally on the processor, as you need the amount of time to actually send the transmit the packet, plus the time the servo says to delay starting to send a response, plus the times it takes to send the bytes back over the UART. But this does not take into account the overhead for sending the packet over USB to the Arbotix, and then once the Arbotix gets the response back you have the delay to send the data back over USB... Also when I was earlier debugging some stuff using USB2AX, I also saw that at times there were some reasonable gaps in the servo response bytes...

So again I was wondering if others have already run into this and debugged it? Also wondering if those running using the Edison are also seeing similar issues?

Otherwise I will probably start debugging this more. Will probably use a logic analyzer to see how if valid packets are actually being returned and if so how long are they taking.

Other suggestions?


09-11-2015, 12:14 PM
Hi there, just wondering have you verified you Arbotix-Pro to raspberry-pi connect is not lose? As I have not seen these issues, knock on wood, yet.

09-11-2015, 02:32 PM
I double checked it earlier, but will do so again. Also may try a real USB cable to see if that makes any difference.

May also start reducing how many servos are connected to see if that changes the response or lack of.

Thanks again

09-16-2015, 11:07 AM
Another sort-of update.

For the fun of it I swapped in the Edison for the RPI2. This took me longer than it should have as I like to do things the hard way and I wanted to build up my own image for it.

I first installed the latest official Edison image and it could not find the Arbotix Pro. That is when I remembered that the current official images do not include USB FTDI support. I tried to install it from AlexT's repo which installed but did not work, as the Linux images you build do not match the linux name of the official image, so the driver module did not load.

So I went through the process and built the module on my NUC under Ubuntu 14.04 and I used the menu config stuff to include the FDTI driver and then I reflashed. I now have /dev/ttyUSB0 :D

I followed the stuff in my my forum posting: https://communities.intel.com/message/265911#265911

I then installed git, downloaded my fork of the HROS1-Framework, and built portions of it and starting to test.

I needed to install git as well as libjpeg-dev

So far I have done some testing with the dxl_monitor program and it appears to be much happier with the Arbotix Pro. I am not getting any of the failures yet.

I now have the ps3_demo program built, and now need to redo the sixpair as it was built with libusb-0.1.so.4 which is not on my machine yet, but that should be easy. And then next up try it out with my own PS3 driver.


09-16-2015, 11:48 AM
Nice work though.. I went down a similar path not too long ago by installing the latest official image for Edison, finding no built in FTDI support, and unable to load the kernel module from AlexT's repo. Alex did get back to me about being unable to load the kernel module due to an infamous difference in kernel naming between the released binaries and the kernel produced by the build. In order to use his kernel modules he said you'd have to first install the kernel from his repo. By the time I was informed I had already moved on to something else.

I'm starting to get curious about the Arbotix communication troubles you are experiencing on the Pi. Also a little relieved you are getting the same good results on the Edison.

09-16-2015, 11:55 AM
Well dang. I went back and played with the dxl_monitor and got the same result you had. Must be when I check it, it ran so I just left it.
I am sure it is a timing issue and not you. (It is the code) This kernel has a ton of latency issues. There is a sanppy unbuntu kernel that can be interrupted it is used mostly for drones were telemeter can't handle latency issues. I use it with a NAVIO+ hat on one of my drones. I'll do some research. :happy:

09-16-2015, 01:41 PM
Holy cow, ok that fixed it and it runs everything way faster (I know were snappy came from LOL). I got the image from here https://drive.google.com/file/d/0BxaybdBoJZ8zOFdFQ1lGT0U5Uzg/view?usp=sharing. (P.S No desk top so everything is ssh.) This article gives details on how to build the Kernel. Look at the real time for Linux part. The Real-time patch lowers the worst case latency to tens of microseconds vs Hundreds of microseconds.(use raspi-config to set password and resize your sd card). http://docs.emlid.com/Navio-APM/installation-and-running/


09-18-2015, 10:25 AM
Thanks r3n33 - Yep I have had a few postings over the last long while about some of the issues of official builds having one name and builds we do from the official sources have a different name. I thought the last semi-silent update was going to resolve it, but...

I am still trying to do the things the hard way ;) With my build of the official sources, I can talk to the /dev/ttyUSB0 object which is the Arbotix Pro. As I mentioned in previous post it appears to not have (or at least show up) the same issues as I was having with the RPI2.

However I so far don't have a /dev/input/js0 object for the Sony PS3. I am part way there. The Bluez5 that is installed with the current sources did not have in the fixes for the Sony HID, however their github linux files (https://github.com/01org/edison-linux/tree/edison-3.10.17) show they have installed a patch to fix it which has not propagated to a build yet.

So I made a patch file from that delta and then added that patch file to the build and I think that part is in now. However I then found that the joystick device drivers were not installed, such as the generic analog joystick. I think I may now have built a version with those installed, but still no /dev/input/js0 object (even when plugged in USB). Looking at my NUC with Ubuntu I see there are rules
(/lib/udev/rules.d) in a couple of files that I believe are responsible for generating these nodes. So I will try adding the stuff to the appropriate rules files on the Edison....

As I said the hard way. But maybe hopefully I can then get the Intel people to setup all of the needed stuff in an official build. Or at least minimally maybe have most of it in the build and some of it in stuff you can opkg install from AlexT's repos...

LloydF - Sounds good. Looks like you found a workaround, which I may want to look into. I still wonder if this is more an RPI2 issue or an issue with the Arbotix-Pro? That is I did not have issues with running AX servos on the older RPI with USB2AX or USB2DYNAMIXEL. I have not done much testing with these on the RPI2 yet, but I would think the RPI2 would be faster...

At times I wish I had a USB sniffer device to see the messages going back and forth. For example I believe the USB2AX is setup to send stuff packed with if I remember correctly 16 data bytes per packet (maybe 32?), I wonder how many data bytes are being sent per packet with the Arbotix-Pro.... But that is me just guessing.

Will back to doing stuff the hard way :lol:

09-18-2015, 11:30 AM
The arbotix-pro uses the usual FT232RL USB2UART IC, so it will try to send back as much data as the STM32 has available in its buffer to dump over USB. It is quite likely an issue with the FTDI driver and/or its configuration. I know there have been many people afflicted by lots of lost packets on FT232RL-based devices (for both windows and linux) because the driver's packet timeout was set to be way too long compared to the timeout calculated in the robotis dynamixel library. Changing the driver's timeout to a smaller value, and/or increasing the calculated timeout in the framework might help. Might also be helped by following tigakub's suggestion of turning off Nagle's algorithm (http://forums.trossenrobotics.com/showthread.php?7470-It-s-ALIVE!&p=68296#post68296), but might work better only for outgoing packets to USB devices and not incoming to the host (since devices cannot actually signal they have data ready to send unless polled by the host).

Although it does not seem to want to work anymore on my netbook, I had used wireshark for snooping USB packets when working with the OpenCM (especially in figuring out the upload sequence).

09-18-2015, 03:20 PM
Yea, The NAVIO+ Guys have a nice cyclic test which show off the latencie issues with the rpi and rpi2 kernels, they must have gone through some sutff to get the ( Interipatable ) RT-snappy Unbuntu core up and running, but there in the Business of sensors and have a hat for the edison coming out soon (uav things:wink:).There version comes with a raspi-config program to expand the SD so the using of fdisk will kill it, just a warning.:o

09-18-2015, 03:50 PM
Thanks Tician. May have to experiment some here.

LloydF: Sounds like they may have a good option.

My testing may be slowed down some... My Edison Arduino board that I was doing the joystick testing with just went poof!
I plugged in the board and saw some slight flames coming out of U1 (just below the larger USB connector)...
I have a few more bad Edisons around here. Once totally dead, another one who won't output over the the USB debug... But maybe the edison module is still OK and it might work in one of the other mini adapters... (Still have the other Edison mounted in HROS1...)

09-18-2015, 06:03 PM
Slight flames LOL :cool:

09-18-2015, 06:43 PM
Slight flames LOL :cool:
Yep - maybe only a 1/4" tall flames :sad:, which is at least a bit more definitive than a puff of smoke :lol:
The good news is it appears the module is still working. So I now still have I think 3 working Edisons, now all on mini-breakout boards.

So I am still trying to figure out what all the modules are that are needed to support the PS3... Maybe I should take the easier route and simply use the Bluez4 stuff installed.

09-18-2015, 07:24 PM
Actually what I am now thinking of doing is a semi punt... That is I am going to swap out the Edison and put in an Odroid C1. Hopefully their USB stuff works well and I already have working Joystick (sixed) stuff for this.

09-19-2015, 10:29 AM
That's one of the few Boards i do not have let me know if it has Latency issues Like the 3.18 Kernel under wheezy has. The Pi's
are fine just not the kernel they are using, which leads to some experimenting with some different non-wheezy stuff. (wheezy I wounder If someone knew something way back when. (I haven't blown one yet, oh wait yes I have. ROFL) :veryhappy:

09-20-2015, 05:54 PM
Today I have done the first pass in swapping in the Odroid C1, that is currently running Ubuntu 14.04.

Unfortunately I think I am seeing a lot of the same issues I was seeing with the RPI2 as it tries to talk to the Arbotix-Pro.
Right now I have the C1 powering sort-of tacked together. That is my HROS1 came with a small 3 amp BEC. So used the power jumpers that I was using and used that to plug VIN/GND from Arbotix-Pro into source of BEC. I then stuffed the leads of a power connector (http://ameridroid.com/products/dc-plug-and-cable-assembly-2-5mm) into the output of the BEC and plugged it into the Odroid power connector.

Took me a few attempts to get the PS3 to work. I am using the sixad package that I installed from http://forum.odroid.com/viewtopic.php?f=52&t=5908. So now after I boot I again simply have to push in the PS button and it will set itself up and create /dev/input/js0. I know my raspberry Pi project Joystick test program is happy with talking to the joystick, so my updated code for the HROS1 should be fine, once I figure out some way to make the Arbotix Pro happy.

Somehow it appears interesting that it runs OK with the Edison which is a dual core 500mhz processor and not OK with C1 which is a 1.5ghz quad core processor with more memory, other stuff stored on emmc...

So looks like I need to do some more debugging!

09-20-2015, 08:39 PM
Hum. Okay this is odd if you use a class 4 sd card everything seems to work, with out timing issues (well the dxl_monitor runs ok). This needs a little looking into. (Well I was hoping LOL) It still fails with kernel 3.18.

09-20-2015, 08:56 PM
No, just wishful thinking, lol it just takes longer to fail.:sad: Was using this Ubuntu 14.04 LTS (Trusty Tahr) image for the Raspberry Pi 2, which I like a lot. But it is based on the 3.18 core and that seems the culprit here LOL.

09-21-2015, 11:09 AM
Sorry to hear that still no luck on RPI2...

As I mentioned I think it might even be worse on the Odroid C1, and I am using an eMMc, which is a lot faster than sd cards...

Unfortunately I think I am going to be tied up for a few days and not able to do much here, but hopefully later this week I will have some time to start debugging.

Probably will try to setup to update Arbotix-Pro. Which I believe requires the programmer like Tician mentioned, plus some form of adapter, which I believe there are Eagle files for in the Arbotix-Pro github project. So I can probably send those off to someone like OSHPARK and have them fabricated and then get the parts to populate it. Wish Trossen sold a setup for this...

As I mentioned, my gut says there is probably some buffering or non buffering issue between the Pro and faster processors. Will be interesting for example to see the sizes of data coming back from Arbotix-Pro. For example if you look in the HROS1 sources at the file CM730.cpp, probably turn on DEBUG_PRINT sucnh that when TxRxPacket is called you can in places that call ReadPort maybe update the debug outputs to maybe include hints on how many bytes are returned at a time and see if this is different for different processors...

But might not be it as I am seeing only RX_TIMEOUT and not RX_CORRUPT so it has not received any bytes. So maybe it has not sent all of the data? Might try hacking this function, that before I call something like SetPacketTimeout, I would see about making sure the write has finished writing (flush). Would try directly in this function and/or create a new function to call in LinuxCM730.cpp and call that new function...

Nagles algorithm? As far as I have seen this mainly applies to TCP/IP sockets, so not sure if it applies here?

Probably some of my first steps will be to work with being able to toggle IO pins on C1 (or RPI2), and hook up logic Analyzer to these pins, plus data pin on Dynamixel Buss. Plus see about setting up some form of USB sniffer and/or find some IO pin that mimics what is going in/out from there.

Got to go.


09-21-2015, 11:29 AM
If the Arbotix-Pro is still using the same bootloader as the CM-730, then it is possible to update the firmware over its USB port using the firmware_updater program from the DARwIn-OP framework. It should accept the new firmware binary over the FT232RL-connected UART and reflash itself. If it gets bricked or there is no bootloader, then the ST/Link or SWD dongle would be required.

09-21-2015, 05:52 PM
Be careful with bootloaders, I think they have a special set-up that they were going to give us beta testers one day. Things change so do promises so we will see I guess. Yea the only Image I have found that works without issue on the pi 2's is the RT image from the NAVIO+ folks. However there is a new Hex spider with the EarlBrain2 which is a raspberrypi 2 on unbuntu snappy with ROS Indigo so....
Christmas time should be nice.:cool: https://www.indiegogo.com/projects/erle-spider-the-ubuntu-drone-with-legs/

09-21-2015, 06:11 PM
If the Arbotix-Pro is still using the same bootloader as the CM-730, then it is possible to update the firmware over its USB port using the firmware_updater program from the DARwIn-OP framework. It should accept the new firmware binary over the FT232RL-connected UART and reflash itself. If it gets bricked or there is no bootloader, then the ST/Link or SWD dongle would be required.

The Arbotix-Pro version doesn't use a bootloader and loads at 0x8000000 versus the CM-730 which loads at 0x8003000 (i.e. above the bootloader).

On a side note, where would one find the CM-730 bootloader program/file other then on a CM-730?

09-21-2015, 07:00 PM
I was thinking the CM-730 bootloader was included in the CM-730 firmware archive, but apparently not. I assume it would probably be based on one of the STM32 example bootloaders for re-flashing over a UART, but modified to use the UART connected to the FT232RL (UART3?) instead of UART1 (DXL?).

09-22-2015, 11:40 AM
Ha. I should have realized when GUVCVIEW ran but the UBUNTU Mate Distro works at least as stable as on the edison or so it seems. YEA!:o It still has some failures as the only sold kernel I have found, has been the PREEMPT-RT kernel. (Looks like erle Brain 2 and NAVIO+ are using it with modifications i.e added raspi-config) This article tells you how to build a RT kernel. https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO

09-24-2015, 09:31 AM
Right now on the Odroid C1 I am trying out a change which may be helping. At least when I now run the dxl monitor, I can run scan several times and not see errors. Likewise I have been able to change IDs and do something like wr 30 400 and get success.

What I am doing is before I set the Read timeout, I call: tdcrain() on the file descriptor. If I understand correctly this is semi like calling fflush on a file? That is it should not return until all of the characters have been output. I created a new virtual function in the CM730 class, which I then implemented in the LinuxCM730 class.

I uploaded the changes to my fork (kurte) on github in the branch Use-my-joystick-controller. Warning unfortionatly on some of these files it shows the complete file changed even though I really only maybe added one maybe a few lines. More on this in a different posting.

Edit: I have noticed that on at least one of the times I did the wr 30 400 to a servo, there appeared like there was a rather long delay between when I hit the cr and the servo moved. So still looking at maybe how it is buffering. If there is some form of timeout?


09-24-2015, 06:22 PM
Tried a few more tests with the updates, plus I re-added back in the ioctl calls for TIOCGSERIAL/TIOCSSERIAL that the code base had, that was disabled for USB2AX type code.

I also tried adding on the ASYNC_LOW_LATENCY flag to see if that might help. I was pretty sure that was a longer shot as I think my machine was already setup for low latency... I think the default for FTDI is 16 and mine is already set to 1

[email protected]:~$ cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

I found information about some of this up on the site: http://projectgus.com/2011/10/notes-on-ftdi-latency-with-arduino/

Again with these changes I am not getting errors with the dxl monitor program. It would be interesting to see what the values are on an RPI2... Also should try out these changes with the actual robot doing something.

09-25-2015, 10:07 AM
Update to 2nd note above - Don't think adding the ASYNC_LOW_LATENCY flag will make any difference now on RPI2. I booted up my RPI2 and plugged a FTDI device in it and it too showed the latency of 1... Also found on web where Linux was updated awhile ago and now sets the ASYNC_LOW_LATENCY flag by default.

Have also started to do some testing of the ps3_demo program. At first I was getting nowhere, I would try to run: ./demo
and the program would simply exit doing nothing and with no error messages at all. I sprinkled in some printf messages to localize where the issue is: It is in LinuxMotionTimer::Start().

The pthread_create fails with error code 1 (which then just exit(-1) ).
The issue is that the thread code here is trying to change the scheduler (SCHED_RR) and set the tread priority to 31, which is not allowed for non-privileged user. Earlier I updated joystick code to not require sudo, but now it looks like this code requires it.

I am not sure if one can setup to use different scheduler priorities without sudo? I saw some stuff on a NICE value. Also not sure how much this helps out the motion manager...

For the fun of it I may hack this function, that if fails to create the thread, it print out a message and then start the thread with default stuff and see if it works OK.

09-25-2015, 10:45 AM
To enable higher priority without sudo, you have to modify "/etc/security/limits.conf" by adding:

@darwin hard rtprio unlimited
@darwin soft rtprio 32

@darwin hard nice 0
@darwin soft nice 0

where darwin was the default user for the theatre students to keep them from messing with the system. Change to meet your needs.

It is only the motion manager that uses the real-time callback thread of the motion timer, so making sure that works well will keep everything else working well.

09-25-2015, 01:22 PM
Thanks tician!

Yep that got it up and working without sudo. In this case substituted odroid for darwin and then reboot...

I may still put in the code to give some form of error message and maybe try to recover without RT priority.

09-29-2015, 03:36 PM
I tried out The new Raspberian release (JESSIE). Same Latency issues as all the non-RT kernels.:sad:

09-29-2015, 06:17 PM
You might want to try the changes I did to add a call to tcdrain before setting a timeout:
It was done in the delta: https://github.com/KurtE/HROS1-Framework/commit/e5800a79b98ce9b8b70dd008393119c033736496
Unfortunately the change looks big as it turned out to change line endings in the files. Some files in the projects are linux formatted and others are windows formated (lf vs cr/lf)...

I am not getting the failure to initialize on PS3 demo nor failures in dxl_monitor. Note: I do think there are still some messages with longer than should be delays, that still need to be looked into.

10-01-2015, 08:11 PM
Note: I split out the change that added the tcdrain into it's own branch based on master and created a pull request.

Would be great if someone tried it on RPI2 to see if it helps fix (or mask) the ftdi latency issue where basically the code was timing out, before the packet was actually transferred to the Arbotix-pro...

10-03-2015, 06:15 PM
Not sure how would be interested, but thought I would play around some with toggling IO pins on the ODroid C1 to get an idea of timings. I am using on Odroid version of the wiring pi library.

The test program looks like:

* testUSB.cpp:
* Standard "blink" program in wiringPi. Blinks an LED connected
* to the first GPIO pin.
* Copyright (c) 2012-2013 Gordon Henderson. <[email protected]>
************************************************** *********************
* This file is part of wiringPi:
* https://projects.drogon.net/raspberry-pi/wiringpi/
* wiringPi is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
* wiringPi is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* GNU Lesser General Public License for more details.
* You should have received a copy of the GNU Lesser General Public License
* along with wiringPi. If not, see <http://www.gnu.org/licenses/>.
************************************************** *********************

#include <stdio.h>
#include <signal.h>
#include <wiringPi.h>
#include "LinuxDARwIn.h"

// Quick and dirty test program to try out some USB communications between ODroid C1 (could be RPI2) and Arbotix Pro

#define LED_PULSE 27
#define LED_USB 26
#define LED_ERROR 11
//#define WRITE_LED_TEST

using namespace Robot;

LinuxCM730 linux_cm730("/dev/ttyUSB0");
CM730 cm730(&linux_cm730);

#define MAX_ID 20
int gID = 1;

void sighandler(int sig)
// cm730.WriteByte(CM730::ID_CM, CM730::P_DXL_POWER, 0, 0);

int main (void)
signal(SIGABRT, &sighandler);
signal(SIGTERM, &sighandler);
signal(SIGQUIT, &sighandler);
signal(SIGINT, &sighandler);

uint8_t panel_level = 0;
int value;
int error;
int error_level = 0;

printf ("Test Speed to talk to Arbotix Pro\n") ;

wiringPiSetup () ;
pinMode (LED_USB, OUTPUT) ;

if(cm730.Connect() != true)
printf("Failed to connect CM-730!");

cm730.WriteByte(CM730::ID_CM, CM730::P_DXL_POWER, 1, 0);
for (;;)
// See how fast this can go...
digitalWrite (LED_PULSE, HIGH) ; // On
digitalWrite(LED_PULSE, LOW); // Off /

// Now lets try to do a simple packet to Arbotix Pro
panel_level = panel_level? 0 : 7;
error = 0;
digitalWrite(LED_USB, HIGH);
cm730.WriteByte(CM730::ID_CM, CM730::P_LED_PANNEL, panel_level, &error);
cm730.ReadWord(gID++, MX28::P_PRESENT_POSITION_L, &value, &error);
digitalWrite(LED_USB, LOW);
if (gID > MAX_ID)
gID = 1;
// Give us an indicator at 0...
digitalWrite(LED_ERROR, error_level ? LOW : HIGH);
digitalWrite(LED_ERROR, error_level ? HIGH : LOW);
if (error)
error_level ^= 1;
digitalWrite(LED_ERROR, error_level ? HIGH : LOW);
printf("E:%d\n", error);
return 0 ;

I first tried it out doing something simple like trying to set the LED values on the board, so there should not be any additional delays introduced for the command having to talk over the AX buss.

I then later had it go through and try to read a word (Current position) from many of the servos, to again see how much additional delay this might add. I am using three IO pins on the Odroid, top one is simple high/low of the IO pins, to see if this added much delay (no). The next line down goes high when I start a command to talk to the Arbotix Pro and goes low after the command completes. The third line toggles if command errored. I also used the third pin to do a quick toggle in the reads when I wrapped around back to servo 1...


I was going to also put up an image of the logic analyzer run for just doing the set the LED on the controller, but the timings were more or less identical. That is you could do about 800 reads or writes per second.

Out of curiosity, I may run the same test talking to something like the USB2AX, to see the timings here.


10-07-2015, 10:20 AM
Ya know. Playing with this Jessie distro from the raspberrian folks. It is nice and I ran the dxl_monitor a half dozen times with no failures.
Seeing how this run's everything and vnc and opencv, everything but the old guvcviewer program. This is probably the way to go for the rpi2. I like simple and less stressful ya know.:rolleyes:

10-07-2015, 10:29 AM
Sounds good, may have to try out Jessie some time soon! Potentially could try it out on the Odroid (c1) as well as I see there is at least one image setup for them: http://forum.odroid.com/viewtopic.php?f=114&t=16520


10-07-2015, 11:12 AM
Now do not get me wrong. The only fix for real time data/clocking, is a RT-kernel. Just saying.:cool: (Man i am glad i found the RT kernel as it looks like the standard preempt kernels are not happy with the arbotix-pro). I got the image from here https://drive.google.com/file/d/0Bxa...ew?usp=sharing (https://drive.google.com/file/d/0BxaybdBoJZ8zOFdFQ1lGT0U5Uzg/view?usp=sharing). (P.S No desk top so everything is ssh.) This article gives details on how to build the Kernel. Look at the real time for Linux part. The Real-time patch lowers the worst case latency to tens of microseconds vs Hundreds of microseconds. (use raspi-config to set password and resize your sd card i.e Default login Username: pi Password: raspberry). Then install deb dependencies from https://github.com/Interbotix/HROS1-Framework/wiki . Use the how to setup your wifi from here and you are up and running with no errors and solid PS controller connection. After booting access the SD card contents open /etc/wpa_supplicant/wpa_supplicant.conf (with root privileges on Linux) and edit the file as described above, I like to use nano to edit myself:happy:.
Create WiFi network with default ssid and psk
By default in our image Raspberry Pi is set up to connect to the following WiFi network:
ssid = “emlidltd” {change to your ssid}
psk = “emlidltd” {your password here}
key_mgmt = wpa-psk
. http://docs.emlid.com/Navio-APM/installation-and-running/ (http://docs.emlid.com/Navio-APM/installation-and-running/)

10-09-2015, 10:42 AM
There is a HROS1-V2 image and it works great so far. Yea:veryhappy:! Ha no PS3 packages at all, hum....? Not sure what this is now, ill play a bit more on this one, but here is were the image is at.

10-09-2015, 01:05 PM
Thanks LloydF,

I am in process of downloading this image now, and will update an RPI2 to it and see what is there. Also it would be great if there was (maybe there is) a document that describes what steps were taken to make the image.

No PS3?

10-09-2015, 03:13 PM
Yea and it still has errors:sad:. However the rt kernel from the erlerobotv2 guys works and has ros indigo installed and only take 34% of a 8gb SD woot! This is the kernel that seems to be working (PREEMPT_RT kernel 3.18.9-rt5-v7+)
(I was hoping the Trossen guys would see they need to build a RT kernel and maybe name it HROS1-RT. The fun thing about rolling your own kernel is ya get to name it .:cool: Trossen-RT sounds too much like a virus, just saying.) https://github.com/erlerobot/rpi2-kernel

10-12-2015, 05:51 AM
So latency issues are one thing but "The other thing that was quite important to performing the walk tune was addressing the IMU readings. I'm not sure yet what step Trossen would like to take on getting these fixed ( ie update the Arbotix-Pro firmware so the output is correct or patch the Framework )"
This needs to be answered.

10-13-2015, 08:13 AM
I want to know if both of my Arbotix-pros have broken IMU's or just the first one. Can they be fixed. (or do they have to be sent back)

10-13-2015, 08:41 AM
Hi LloydF,

Just curious, when you say broken IMU's, are you saying your imu is plain not working or is it that the values are different than the code expects (like maybe different logical registers as compared to the CM-730?). If the later have you looked at the issue the r3n33 opened against the main project: https://github.com/Interbotix/HROS1-Framework/issues/11

Have you tried out her patch?

I am keeping my fingers crossed that they will soon either simply merge that patch in and/or will make a mod to the firmware to update the readings to be compatible. But if they do the later, I hope that they rev the firmware version and the software is updated to detect if the new firmware is installed and if it is not, then use the patch...

Also if they update the firmware, it requires a hardware programmer and a cable conversion to program the board (let alone a setup that allows you to build the firmware). So hopefully they will have a service that allows you to ship it to them to update...

10-13-2015, 09:55 AM
Just saying if it's output is backwards and needs to be programmed again then, yes its broken.

10-13-2015, 12:25 PM
Personally I'd say if it needs to be programmed again it's mis-configured ;) But tomato tomato I hope.

Regardless, I'm actually working with the team and these issues this week. At this point I feel confident in saying an update will be available very soon but I'll have to leave the details to the official people :)

10-13-2015, 07:52 PM
Personally I'd say if it needs to be programmed again it's mis-configured ;) But tomato tomato I hope.

Regardless, I'm actually working with the team and these issues this week. At this point I feel confident in saying an update will be available very soon but I'll have to leave the details to the official people :)
:happy: FYI - I see that some new stuff has been checked in to the Interbotix/HROS1-Framework project :D :D :D

This includes for example Invert F/B Accel Value - Not sure if is all of the needed updates for the IMU, but at least I am seeing progress!


10-14-2015, 11:32 AM
I'll look around on the schematics and see if there is a spare inverter that could be forced into service with wire solder and a exacto knife?

10-14-2015, 11:37 AM
I'll look around on the schematics and see if there is a spare inverter that could be forced into service with wire solder and a exacto knife?
The IMU values are digitally read by the STM32 (via SPI) from the gyro and accelerometer ICs, and then sent to the framework via dynamixel packet. No hardware change could fix the inverted axes without requiring a completely different PCB for mounting the gyro and accelerometer ICs. The issue is software: there was a change somewhere in either the framework or the arbotix-pro firmware that swapped axis direction/'polarity' without ensuring consistency between both firmware and framework.

edit: or a change in the orientation of the arbotix-pro and its IMU ICs when mounted inside the robot, compared to the DARwIn-OP+CM-730 or NimbRo-OP+CM-730...

10-14-2015, 12:44 PM
Hum, so no surgery today.:tongue:

10-14-2015, 06:36 PM
Hum, so no surgery today.:tongue:

Adding alignment matrices to the frameworks gyro and accelerometer processing to account for orientation of the sensing devices would be the simplest solution.

10-16-2015, 05:13 PM
How will we know when something is done about this issue with the Arbotix-Pro's? I mean I saw the get pull update for the HROS1 but, do not know what it did or what to expect now, software or firmware changes. (feel like a starving mushroom here:rolleyes:)

11-09-2015, 07:56 AM
(feel like a starving mushroom here:rolleyes:) Has anyone heard from the TRS peoples or what they are doing or up too, in months?

11-16-2015, 04:46 PM
Hum. I noticed that most of the Distros that have a raspi-config program, if you turn off the desktop an boot to the command line
the lag is acceptable and you get no errors in the dxl-monitor. This is what I have been testing with: Testing real-time capabilites using cyclictest utility

Installing cyclictest utility on Raspberry Pi:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
cd rt-tests
sudo make all
sudo cp ./cyclictest /usr/bin/ */rmk put in place were everyone can find it.
cd ~

Testing real-time:

sudo cyclictest -l1000000 -m -n -a0 -t1 -p99 -i400 -h400 -q

I am going to have to collect some data here on different kernels to see what is acceptable lag for the Arbotix-pro before errors start building up. So far a Desktop adds over 1k to 2k uS of delay. A non Desktop is around 100 to 125 uS and a RT kernel is around 25 to 50 uS.

11-17-2015, 09:02 AM
(feel like a starving mushroom here:rolleyes:) Has anyone heard from the TRS peoples or what they are doing or up too, in months?
I heard from Kyle about a week ago that he was going to work on migrating the Arbotix-m stuff over to the current versions of Arduino like 1.6.6. That is why I made another quick pass through my branch: https://github.com/KurtE/arbotix/tree/arduino-1-6 and removed some of the warnings I was getting from the board manager. I also found issues with building the Hexapod and Quad code base that was generated by Nuke and found a change to the code that got it to compile again... So hopefully soon they will be able to migrate beyond 1.0.6...

As for HROS1 stuff, I have not heard much.

Your RPI2 stuff sounds interesting, but not sure how that translates to other setups like ODroids... Personally I wish they would bring in my pull request that simply makes sure that the write happens before they start their timeouts. It is not a complete fix, but for me has gone a long ways toward minimizing the problem.

11-17-2015, 02:19 PM
I think Tyberies is off to Portland, Oregon. So, ya, He may have a new job and we could be, on our own now? Seem every one
connected to this Jimmy Robot 21st Century thing took there IP and ran.

11-17-2015, 02:48 PM
He relocated from Trossen HQ in Chicago awhile back, but last I heard Andrew was still head of Interbotix R&D working on assorted projects like the HROS (and other collaborations with Intel?).

11-17-2015, 04:16 PM
I think Tyberies is off to Portland, Oregon. So, ya, He may have a new job and we could be, on our own now? Seem every one
connected to this Jimmy Robot 21st Century thing took there IP and ran.

Let's not jump to wild conclusions here. Please.

21st Century Robots was an effort that enabled us to launch the project and have me focus on bringing the OS1 & OS5 to market for an entire year. The only "IP" we didn't have control over was the actual character Jimmy, which has zero bearing on the project as it was used for marketing and wasn't a viable design to begin with. Trossen Robotics was still the only driving force behind development on the kits. The 21st Century Project didn't have unlimited funding, but it did enable us to get as far as we did.

I'm still around, I still read these forums, but you have to understand that Trossen Robotics is a very small team with only two technical people on staff (myself and Kyle). We work very long hours and juggle a lot of different projects, and tech support/answering questions via email will always have priority over the forums, which can take a lot of time to keep up on with as active as they are.

We have updates coming soon on the OS1 codebase that also incorporate KurtEck's changes, but we've also been prioritizing creating more tutorials, documentation, & videos that will enable people to try new things with their robots.

Once again, we're a very small team here that keeps things rolling. We have to spend our labor wisely and based on priorities that we as a company have to manage, and aren't necessarily always shared/broadcasted publicly. I ask for your patience and understanding in this.

11-18-2015, 03:34 AM
Thank, you I fell informed now.:rolleyes: (I fell like some levity is needed here. "It's alive";))

11-18-2015, 12:16 PM
Thank you for the update on the Trossen activities. I am looking forward to the much needed tutorials, documentation, videos, and updated codebase.

12-16-2015, 08:50 AM
So, the bottom line here, is if you are not using telemetry data, which needs serious timing and needs a RT (real time kernel), you can get buy with almost any Distro's that the HROS1-Framework will compile in, as long as you turn off the Desktop.:rolleyes:

01-16-2016, 01:56 PM
I have started playing around again with some of this. In particular trying to figure out why the reading of information from servos is not always reliable. I found that as well on my Hexapod code base talking through USB2AX as well as with the HROS1 code base talking through Arbotix-Pro

Right now I testing out some of the HROS1 FSR Feet code and was getting several misreads, so I setup with standalone system to test some of it out. Currently using Odroid C1 with an USB2AX talking to currently one FSR Foot (id=111), I also have one servo (id=1), connected with powered hub and the 12v 10amp wall wart...

I hacked up some of my Raspberry Pi test program to do queries of the FSR registers... Again was getting some misreads, so decided to instrument the code to get an idea of timings. The code again is part of my RPI code base, which is based on Xevels version of the Robotis code base.

Above is a Logic Analyzer output, when I try reading 10 bytes of registers starting at 0 for Servo ID=1. The above succeeded. The top line shows the AX buss as measured from the powered hub. The 2nd line shows when the code is in the TX function, the next line shows when we are in the RX function. The next line shows when RX actually returns any data. The next line shows when the flush call is made to make sure the data has been written out. Last line which did not apply was a clear function which was not called.

The interesting stuff is that on the AX buss, it only took about 1.3ms for the Tx to happen and the RX to be completely done for the 10 register read. But it took 3+ms before the data was all returned to the program running on the C1+, which is very close to our time out.

What I have not instrumented yet is how much of the difference in time is within the USB2AX and how much of the time is the C1 waiting/processing the USB data. At some point I may instrument the USB2AX code base, to get some more of that information. However to do so, may again program a Sparkfun Atmega32u4 breakout board again with USB2AX code base. With these you have IO pins to toggle...

Side Note: I was trying something like:

dxl_set_txpacket_parameter(0, 0);
result = dxl_get_result();

It always failed. While all of the data showed up on AX buss, only the first 32 bytes ever showed up... But off topic.

Next up try to repair my second Arbotix Pro and try out some of the same tests. May take a few days...

01-31-2016, 10:11 AM
Replacement Arbotix Pro arrived, so may retry above tests, with it...

However one thing I keep wondering about, is if in the case of having the Arbotix Pro talk to many of the boards we are using, if we are maybe barking up the wrong tree.

That is instead of using USB, if instead we should communicate using TTL Usart. Obviously this may not be a valid option if you are connecting to a PC (or NUC ;) ), but:

For example the Odroid C1 I believe the Uart maybe can go 5mbs. Not sure yet about RPI2, but at least one web page shows some higher speeds, like maybe 1.5 or 2mbs (http://www.thedevilonholiday.co.uk/raspberry-pi-increase-uart-speed/), Edison: I have not played with this for awhile, but I remember that it can go pretty high (https://communities.intel.com/thread/58972?start=0&tstart=0), Have not looked at XU3/XU4 yet... In some cases may need level shifter... Probably not on RPI2 or C1.

So the next question is, how to use one of the Uarts on the Arbotix Pro? Also what baud rates would it support. I know there is some support for using XBee (not sure if any documentation on this), and how much support is built into the default firmware.

Maybe I should try something like this on one of my Teensy 3.2 based boards and get an idea if there are any throughput differences. For this I will probably assume full duplex and not add any unnecessary complications of half duplex.


02-01-2016, 01:35 PM
Seems like an interesting idea. So far I've used the Arbotix Pro on the Edison and NUC and haven't had any issues. I've had some thoughts about adding inertial sensor fusion but haven't taken action or even attempted to compile the firmware.

You might be in uncharted territory ;)

02-01-2016, 02:08 PM
Except decent sensor fusion schemes require magnetometer inputs to help correct for gyro drift. Kurt's Teensy-based Arbotix Pro includes headers for breakout boards of decent 9DOF sensors, where the Arbotix Pro still uses the rather old pair of 3DOF sensors from the CM-730.

02-01-2016, 03:20 PM
True true. Good on Kurt for including compatibility with the BNO055 on his Teensy design :happy: If it's algorithms are decent it saves a bit of effort.

02-01-2016, 04:54 PM
Hi Renee and Tician,

Been playing around some today with some of this.

Currently the new board has the Sparkfun LSM... Board on it, but I think I really really prefer the Adafruit one, as I believe it does all of the stuff for you on its arm chip, I think I need to assemble another one of my new ones with it. Need to order another one or can probably remove from first board... (May have to try out the hot air station)

What I have tried so far today (before started doing some work in greenhouse):

Verified on Odroid C1+ that I could output the Dynamixel stuff on the USart that is on the expansion connector. So far it appears promising. I only test with my own Rasperry PI project. Was able to test without changing a single line of code, just did:

sudo ln -S /dev/ttyS2 /dev/ttyDXL
And my hacks in the dxl_hal code picked up and used this serial port. I hooked up logic analyzer and ran my AX12 test program and verified that a packet was sent to the appropriate pin on the connector at 1mbs :D

I updated my Teensy_Arbotix_Pro sketch to instead of doing the host communications hard coded to the Serial object, that instead I talk to PCSerial, which I currently define as: #define PCSerial Serial // Default to USB

I then uploaded it to Teensy board and verified it still works, and get some timings...

Next up, I will define it as either Serial2 or Serial3 and then run jumpers between the two boards and see if it works and also capture some data. Again The first timings I show show how long it took to output a request to servo 1 and get it's response back. The second timing shows how long between requests. The delta time gives a general idea of how much time may it is taking to get the data through USB.

It would be interesting to try some of these same tests using an Edison, unfortunately The USART and IO pins are not exposed on the mini adapter and my Arduino adapter smoked...

Would also like to experiment using Arbotix Pro:
Renee as you mentioned, this appears to be uncharted territories. If I understand the Arbotix Pro schematic and code, it is my understanding that the underlying processor has at least 4 Usarts (chip maybe 5). Currently the board initializes 3 usarts (DXL, USB - using FTDI chip, and Zigbee). There is a 4th one connected up to the processor to a 3 pin header on the board (TX, RX, GND), and other than the system init code (system_init.c) iadding those pins to the GPIO_PIN definitions for PortB, I don't see anywhere that uses it.

What I would like to try is to try to initialize this USART (need to figure out which number), and have it's interrupt handler mimic the USB interrupt handler, which I may disable and see if I can build this and download it to an Arbotix Pro. Probably the one got screwed up with the usb connector broke off and is currently toast.

If this works well, may then see how hard it would be to add some way to switch where to connect to PC (Mode button?) or maybe try to auto detect. That is maybe check both and first one who sends out a packet wins...

But first I need to figure out how to build firmware and update. I know there is some stuff up on the main site that gives some idea of how to build, I believe only under Linux. Would be nice if that was not a restriction for doing this. Has anyone tried? Updating the firmware? Hints? Will probably open new thread on this.

Now back to working on greenhouse.

02-01-2016, 06:13 PM
Since the CM-730 and CM-530 use the exact same STM32, could probably use the cm530 easy-functions with it after some modifications. The SPI comms to the accelerometer and rotational velocity sensor would probably be the biggest change since the CM-530 and CM-730 both use USART1, USART3, and UART5 for DXL, PC/USB, and ZIGBEE, respectively.

Unfortunately, the CPU_TXD/PA9 and CPU_RXD/PA10 pins connected to the 3-pin header are USART1, which is otherwise multiplexed to pins PB6 and PB7 for DXL comms. The UART5 used for Zigbee is slower than the USARTs, but should still be able to hit 1Mbps. You could use PA2 and PA3 for USART2 instead of analog inputs; have to change initializations a bit and add a "ISR_USART_PC()" call to the "USART2_IRQHandler" function in stm32f10x_it.c and modify "__ISR_USART_PC()" in usart.c to use USART2 instead of USART3. Ooof, the CM-730 code is such a jumbled mess.

02-01-2016, 08:14 PM
Thanks Tician, I will take a look at what you mentioned. If I am looking at the right documents, I believe that Usart 1 can go up to 4.5mbs and the others can go up to 2.5mbs, so 1 should not be a problem. I was wondering about the pin mappings as it appeared to me like DXL and PC were on the same USART... But sounds like they can be remapped some.

The manual mentioned something about some other manual on the alternate functions, in particular:

This alternate function can be remapped by software to some other port pins (if available on the used package). For more
details, refer to the Alternate function I/O and debug configuration section in the STM32F10xxx reference manual,
available from the STMicroelectronics website: www.st.com.

This afternoon, I did a test to talk to my Teensy board using Serial2 on Teensy and /dev/ttyS2 on Odroid C1 and have them talking, but right now, I am running into a problem that flush operation is taking way too long.

The first line shows AX Buss, 2nd line shows TX of packet from C1 to Teensy, 3rd line shows RX of packet from Teensy to C1. What is nice is that it shows nice overlap of communication. However the code does not come back very quick. The bottom timing shows how long it takes for the flush function to return:

void dxl_hal_flush(void)
digitalWrite(WPD_FLUSH_PIN, HIGH);
digitalWrite(WPD_FLUSH_PIN, LOW);
Should complete at about same time as end of output packet (2nd line). I have mentioned this up on Odroid forum as well. Wonder what is going on in the Drain...

02-01-2016, 08:45 PM
DXL and CPU (the 3-pin header) are different connections to USART1; guessing the 3-pin 'CPU' header was added to the Arbotix Pro to debug DXL comms and/or add alternative interfaces. The ADC headers can be used to access USART2, and the alternate pins for USART2 are not available on the 64-pin STM32. The PC interface (USB via FT232RL) is on USART3. Zigbee is on UART5 with no alternative pins. UART4 is only accessible from the pins dedicated to the ACC and ROT SPI chip selects. One set of alternate pins for USART3 is not available on the 64-pin STM32, and the other is the same as UART4 (already used by chip selects).

Quoth the datasheet:

The USART1 interface is able to communicate at speeds of up to 4.5 Mbit/s. The other available interfaces communicate at up to 2.25 Mbit/s.
All interfaces can be served by the DMA controller except for UART5

02-01-2016, 09:42 PM

I assume you are using the document: http://www.st.com/web/en/resource/technical/document/datasheet/CD00191185.pdf,

With the Pin descriptions starting about page 31...

Again sorry I have not used these processors before. Is this the only alternative functions for these pins? The comments sort of implied that there may be additional ways to remap. (comment 9 page 37).

So the logical thing to try is to do as you mentioned and try out USART2. Alternatively does anyone actually use the Zigbee stuff? If not could potentially connect through XBee pins, but probably USART2 is good choice...

Looks like my memory was off :lol: but 2.25 should still work.

But first step is to actually be able to build and program the board, I might try first using Ubuntu on Mac (parallels), or on the NUC, who lost room on my desk when the 3d printer arrived.

Thanks again.

02-02-2016, 02:17 AM
The Reference Manual (CD00171190.pdf) agrees: USART3 has three mapping options, USART2 has two mapping options, USART1 has two mapping options, and UART4/5 have no alternate mappings.

Using UART5 instead of USART3 may actually be as easy as: 1) make "ISR_USART_ZIGBEE()" in "app/src/isr.c" to call "__ISR_USART_PC()" instead of "__ISR_USART_ZIGBEE()"; 2) change all occurrences of "USART3" to "UART5" in "TxDData()", "__ISR_USART_PC()", and "__ISR_USART_DXL()" in "hw/src/usart.c". All the pin settings and configurations should be set up already for UART/USART operation, so should be nothing else to change except the baudrate.

02-02-2016, 09:59 AM
Slightly on topic: I just remembered I put together a STM32(F103) serial bootloader using the ymodem protocol a couple years ago. It went through a LOT of testing but never into production. If you'd like to add to your experimentation pile I can send you a copy ;) I likely have a WPF application for uploading firmware already written or you can use something like TeraTerm that supports ymodem transfers.

Anyway. Feel free to say you have enough on your plate. I'm just surprised I didn't think of this until now.

02-02-2016, 10:51 AM
Thanks Tician,

I will download that other document as well. Also I like at least first trying out the XBee USart as you mentioned, it is already setup. My first step is to setup such that I can build the current stuff and download it.

Right now looking at documents that came with ST-Link/V2 to see about setting it up on a PC. Do they have a compatible C/C++ compiler suite for pc... If so I might try to see how hard it would be to setup. Also wonder if any of the other setups might work like visualgdb... Again I might start up separate topic on building and downloading firmware.

Thanks Renee,

Yes, I personally wish the Arbotix Pro came with a serial bootloader installed. Maybe once we figure out how to do current stuff may be fun to add. My impression is that the CM-730 had some form of bootloader as implied in things like:
So might be nice if Arbotix Pro had similar way.

Also next up figure out timing issue with tcdrain (flush). Reading around the web it looks like it may try to call some IOCTL of device driver and some of have seen issues. May try disabling this and see how it outputs. Also may look at termios settings for buffering.

02-02-2016, 03:31 PM
Quick update: I installed STLINK driver and app on PC, but may decide to first start off on Linux...

But back to testing the Odroid C1 talking through USART to my Teensy board. I disabled the call to tcdrain and it is working a lot nicer!
For example Logic Analyzer output of my request to read 10 registers in from Servo 1 (whose delay has been set to 0), show:
So about .5ms between requests...

Then if I instead ask for 10 registers from ID=200 (the Teensy acting like Arbotix Pro), you see:

about .34ms. As you can see in this top line, there is no communication on the top line (AX Buss), and not too much wasted time between request and response.

So I think this is showing some promise.

02-04-2016, 09:24 AM
Quick update: for those who may be interested.

Yesterday, I wondered about what would happen if instead of communicating with the serial port at 1mbs, I would try a higher baud rate.
I believe C1+ can go 5mbs, Arbotix Pro: 2.25 mbs, and Teensy 3.1 at 120mhz I believe Serial3 can run 3.75 mbs. So I updated my test run for 2mbs. Will try higher later, but need to change my dynamixel library to not pass in baud rate divider and simply pass in desired baud rate. Anyway it worked, and for example a query of 10 bytes from the controller went from something like .34ms to about .18ms, which is great.

Also yesterday on my Mac, in the Ubuntu virtual machine I am able to build the firmware for Arbotix Pro. I forked the Arbotix Pro project and cloned it into my MAC disk area, where I can build under Ubuntu and edit under the MAC and maybe with windows...
I created a new branch and added code that will optionally allow the USART associated with Zigbee be used as the host communications. Currently I have it setup that it can read data from either the USB usart or zigbee usart and when it receives data from either of these it sets a global with which USART/UART (USB is USART3 and Zigbee is UART5). Then when program wishes to send out data to the host, it uses this instead of hard coded USART3... This currently builds. I uploaded the stuff to new branch on my clone:

I will also make it optional to instead of use zigbee, you can use USART2, who has TX/RX pins that are current A6 and A7 on JP7. Need to copy Interrupt handler. Also add Interrupt definition into interrupt file, Initialize the USART, Change the IO pins mappings from Analog to appropriate for USART. Also not sure how this might effect AtoD converter if those channels IO pins are no longer exposed...

Next up to test it out on Arbotix Pro. Was/Am planning to do it on the Arbotix Pro whose USB port tore off as board is currently toast, but this board did not come with JTAG pins installed on board. The replacement board does, which I may try to be brave and hope I don't screw it up... Or wait until I make an order to Digikey and order the connector(S9015E-05-ND) to solder in. Anyway I probably need to do a digikey order and get some parts to assemble 2nd of my Teensy boards as I ordered another Adafruit BSO055...

Will also be interesting to see how all of these timings translate when I try with Odroid XU4 (need to setup ttl level converter). I may be tempted to try it out on Odroid C2 (http://odroid.com/dokuwiki/doku.php?id=en:odroid-c2), when it comes out next month. for $40, Amlogic S905 : Quad Core Cortex™-A53 (ARMv8 64bit) 2ghz, 2gb memory...

02-06-2016, 10:40 AM
Wondering if I should open yet another thread about Arbotix Pro firmware and/or email with Andrew...

Wondering more about FTDI on the Arbotix Pro.
For example the initialization code:


I know that Baudrate_PC is 1000000. Looks like they maybe tried 3mbs which I believe is the maximum that FTDI chips handle. My assumption it did not work as I believe this USART has maximum of 2.25mbs. Not sure if they tried 2mbs?

Also what I don't know is the relationship between the baud rate I specify here, versus the baud rate that the code on the PC (Odroid, RPI2, Edison) side sets using IOCTLS. That is if I change the PC side and say 2mbs, does it change the FTDI chips settings? My assumption is yes, as that is what we do with FTDI USB to serial adapters. If so is there some notification that the Arbotix receives, that it should then change it's settings...

Again looks like I may want to read some more on the FTDI chip...

02-06-2016, 10:58 AM
The baudrate is hardcoded into both the cm-730 firmware and the darwin-op framework, but I'm thinking the firmware's baudrate can still be changed using the baudrate option within the dynamixel table of the cm-730/arbotix-pro. The FTDI/PC/USB baudrate can be changed within the framework, but the firmware does not check for any sort of heartbeat signal at multiple baudrates to make sure it is matched to the framework.

Thinking that the choice of two different baudrates for the PC/USB (>1Mbps) and dynamixel buss (1Mbps) was to help make up for the latency issues with the PC/USB connection.

02-06-2016, 11:13 AM
Thanks tician,

Thinking that the choice of two different baudrates for the PC/USB (>1Mbps) and dynamixel buss (1Mbps) was to help make up for the latency issues with the PC/USB connection.
My guess right now, is that Baud rate is fixed inside Arbotix Pro.
That is, the only two pins connecting it is the RX and TX pins...

So I don't believe the processor is telling the FTDI chip what baud, it is only configuring it's internal USART talking to it. Not sure if the FTDI defaults to some specific baud rate and/or there is some USB definition (or whatever it is called) setting the default...

So my guess is that to change the baud rate would need to change both the Arbotix Pro and the framework, which again should not be much of an issue... I will be again hacking mine up for this as well as optionally changing what device it is talking to and also some init code as how you set baud rate may be different for FTDI (/dev/ttyUSB0), versus others like:
/dev/ttyACM0 or /dev/ttyS2. I know I had to update this in some other code when I started playing with talking to Teensy or USB2AX. Need to redo this in my HROS1 stuff as I have not merged in all of Andrew's changes, like changing the name of the object from CM730 to ArbotixPro...

As I mentioned in another posting, changing the baud rate for Teensy through USART from 1mbs to 2mbs, did speed things up. Should do same for USB, obviously the timings may be dwarfed by USB latency...

Thanks again!

02-06-2016, 06:38 PM

Today I decided to risk it and program the Replacement Arobotix Pro with my updates. So far the Arbotix-pro still boots :lol:
So far I don't think the talking to Usart2 is working yet (A6, A7), but I am able to use the RX/TX pins on Zigbee connector (pins 2,3) and I am now able to communicate with the Arbotix Pro at 1MBS from /dev/ttyS2 on my Odroid C1.

Note: I am using my Rasperry Pi project that handles multiple different TTL drivers...

Here is a request to read 10 bytes/registers from servo 1:


I am pretty happy the request completed in about .47ms. Tomorrow I will try 2mbs, but there is reasonable overlap of Usart streams, so may not speed this one up as much. Will check also with asking for registers of the controller itself to see. However I noticed that it looks like these were echoed on AX buss as well?

Also will hack up an HROS1 setup to not hard code /dev/ttyUSB0. Also need to update the init code as setting baud rates different, plus the FTDI driver is really helped when I add calls to tcdrain, but other drivers, like to /dev/ttyS2 is and maybe /dev/ttyACM0 is hurt by the call... Need to figure out why and fix and/or detect difference and call or not call appropriately.

Edit: Note: the timing I show is not the real timing of the call, but timings between calls. I print out 50 registers, but some servos don't like outputting more than 10 or so at time... So the actual call is somewhat less as I issue prints to the stdout for the 10 bytes read in


02-07-2016, 04:56 PM
Today I hacked up some of the Init code for the HROS1 project, such that I can try out connecting to the Arbotix Pro using
/dev/ttyS2 on the Odroid C1+.

To do this, I added some of the hacks from my Raspberry Pi project. Example before it looks for the tty associated with the device string that was passed in: /dev/ttyUSB0
It looks to see if the device: /dev/ttyDXL, which right now I setup for testing by doing the command:

ln -s /dev/ttyS2 /dev/ttyDXL

Then needed to change code to set the baud rate. The official code uses tcsetattr to do some of the initialization and initializes to 38400 and then uses IOCTLS (TIOCGSERIAL, and TIOCSSERIAL), to query the state and then set the non standard baud rate of 1000000.0 by setting serinfo.custom_divisor. This works for the FTDI driver, but not many of the others (like /dev/ttyACM0 /dev/ttyS2). On some devices the IOCTL will return an error, which earlier I used to detect this and use a fallback, but on others it silently fails. So to fix this I instead I try to set the baud rate directly in the tcsetattr call, using the B1000000 setting in newtio.c_cflag. This appears to work on all of them (at least on this processor and some others I tried earlier). If this call fails I try to set it the old way

Also I have been running into issues on when to use or not use calls to tcdrain. It appears to help speed things up with FTDI and slow it down with some of the others, so hacked in code to try to detect FTDI and only do it then...
Again real hack, not sure best way to do:

char szProcFD[20];
char szPath[80];
int ich;
sprintf(szProcFD, "/proc/self/fd/%d", m_Socket_fd);
ich = readlink(szProcFD, szPath, sizeof(szPath));

// Hack look for /dev/ttyUSB... actuall only look at USB
if ((ich > 0) && (szPath[8]=='U') && (szPath[9]=='S')&& (szPath[10]=='B'))
m_UseTCDrain = 1; // FTDI use drain...
m_UseTCDrain = 0; // Others ACM S2.. Don't appear to.

if (DEBUG_PRINT == true)
printf("ReadLink(%d): %s Drain: %d\n", ich, szPath, m_UseTCDrain);

So far it looks like I can get dxl_monitor up working. So far not talking to HROS1, but simply to Arbotix Pro on my desktop, with one servo...

Here is a trace showing the Serial streams when I use the dump command to show data about the Arbotix Pro, where I believe it is doing a query starting at register 0 for something like 0x45 bytes...

Again top line is the AX Buss, 2nd line is data I am sending from C1 to AP and 3rd line is AP back to C1. The interesting thing here is that both the request to the Arbotix Pro as well as it's response show up on AX buss. Not sure why yet. I see where it echos everything it receives from the host out, but don't see yet where it echos everything it is sending back to the host over the AX Buss...
Might be nice to eliminate that, but if both are at 1mbs, looks like not much time wasted as both are going on concurrent. Will again soon look at this with Host talking at 2mbs.

Next up, I will also try to verify with RPI2 that this works as well. Can not try right now with Edison as my Arduino carrier fried, will look at IO pins on the connector to see if I can do that here as well. Probably again need level shifter.

Back to play

02-09-2016, 07:04 PM
Another quick update:
Today I tried seeing if I could talk to XU4 and/or XU3 lite. My first attempt with XU4 of using jumper wires to expansion connector to see the USART output did not appear to work (probably user error), so I decided to extract the XU3-lite from PhantomX and try with it sitting on desk. Which appears to work. So I tried jumpering from XU4 to Arbotix-Pro through TXB0108 on breadboard and it appears to be working.

I also tried an RPI2 which failed, probably one of two things:
1) Might need to set the usart clock speed on RPI (can not tell if this actually applies to RPI2)
2) Need to disable debug console from using this USART (most likely)
Will try again.

Next up do some more hacking on firmware...

02-10-2016, 03:32 PM
RPI2 update:
I have not tested it yet with the hardware, but logic Analyzer shows I can talk at 1mbs. Both parts 1 and 2 above apply:

1) From https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=73673 I updated my /boot/config.txt file to add:

#uart clock

Needs to be 16 times max baud rate.

From some other links like: http://raspberrypihobbyist.blogspot.com/2012/08/raspberry-pi-serial-port.html
Needed to remove references to /dev/ttyAMA0 from /boot/cmdline.txt (delete section of text off of line)
and /etc/inittab (comment # out the line with the reference in it)

Was going to try reprogramming the original Arbotix Pro (that has USB connector missing) as the jtag connector arrived from digikey, but the pins won't go through holes on Arbotix Pro... So will continue with good board.

03-01-2016, 07:04 AM
Raspberry pi 3 is on the way I hope this is a big success. I'll let ya know when it get's here. :wink:

03-01-2016, 08:03 AM
Raspberry pi 3 is on the way I hope this is a big success. I'll let ya know when it get's here. :wink:
Me too, I almost tried to order one yesterday!

But as I mentioned in other threads (and maybe here), I have the XU4 in mine now, plus a new XU4 to go into my PhantomX.

Plus yesterday I did order the new Odroid C2 (http://ameridroid.com/products/odroid-c2) which should ship Friday. Like the RPI3 it is 64 bits Quad, plus it runs at 2ghz and comes with 2GB of memory and I ordered it with their new emmc (only works on C0-C2). So it will be interesting to compare.
One thing I liked with the RPI3 is it includes Wifi and BT, but I have seen arguments on both sides on if this is good.

Again it should be fun when both get our nice new shiny boards!

It is also interesting that Odroid has a 64 bit Ubuntu 16.04 (I assume preliminary). If I read it right, the RPI3 you run the same 32 bit image as you run on RPI2 and they may consider doing a 64 bit image.

But as per this thread: I will be trying out my TTL serial version of the Arbotix-Pro firmware with the HROS1, which I pretty confident will remove most of the issues with the talking between the two boards. But first will probably do it on the PhantomX, as I am in the process of rebuilding mine anyway and I like working with hexapods...

03-01-2016, 09:38 PM
64 bit really isn't needed unless you have more than 4 GB of RAM /and/ a single application that needs it!
The same code with 32-bit sized pointers will use less cache and thus run slightly faster.
(Note: on x86, you also get more registers with 64-bit mode, so the equation is slightly different there)

03-03-2016, 09:06 PM
64 bit really isn't needed unless you have more than 4 GB of RAM /and/ a single application that needs it!
The same code with 32-bit sized pointers will use less cache and thus run slightly faster.
(Note: on x86, you also get more registers with 64-bit mode, so the equation is slightly different there)
Thanks, I asked the question up on the Odroid forum if 64 bits gets you anything and got a few responses back:

Yes it's like 10-20% faster even with <4gb ram. Arm v8 has extra instructions not just address space.

If your program is data intensive, 64bit buys you a lot. There are twice as many registers that are twice as big for both integer and floating point. That means less trips to and from slower memory. Additionally, compilers can make better optimizations since armv8 is well defined and not as fragmented as armv7. For example, VFP/NEON will always be present.

Will be interesting... Hopefully ships tomorrow!

03-04-2016, 10:57 AM
10-20% improvement is ... sometimes true.

More registers are great! (Then again, we already had NEON before that.)

Wider pointers and "native" integers makes for heavier use of the memory subsystem, and can slow things down a lot, depending on workload and code specifics.

So, as always, "it depends" :-) I bet you can come up with specific cases where you get +50%. I bet you can also come up with cases where you get -50%.

03-04-2016, 11:25 AM
Yep - I totally understand that Statistics like this is just another form of lie :lol:

It will be interesting. I am mostly interested to see how well this (and maybe RPI3) compares for usage in things like the HR-OS1 versus usage of XU4. I like the XU4 and the benchmarks still show it running faster, but: (oops again statistics)

C2 requires no fan... (Note: They are playing with Large heatsink for XU4 as an option)

C2 IO pins are 3.3v's so my talking TTL to Arbotix-Pro does not require voltage converter..

Same foot print as RPI2 so can use same mounting and the like on HROS1...

BUT: current image is for preliminary Ubuntu 16.04, so no ROS available yet (I think).

03-11-2016, 08:33 PM
Just got home from Vacation and Yea! A rpi-3 and a odroid-C2 with a nice 32GB Debian eMMC image, bust I need to find the RT-PREEMPT "real time kernel" for it. Time to play.

03-17-2016, 03:25 PM
Ok, so th RPI-3 Works with the new image from the rpi 2016-02-26 image. Use raspi-config to resize and boot without desktop and https://github.com/Interbotix/HROS1-Framework/wiki for all Debian Dependencies, get clone the framework and everything compiles and runs some 35% Faster (you know i am guessing on the speed increase but it is much faster.) oh yes!! edit note (the wifi built in is really nice and frees up a usb port, so I really dont need a hub. Yea!)(Note still have some Bluetooth issues with the rpi3)

03-17-2016, 04:15 PM
Ok, so th RPI-3 Works with the new image from the rpi 2016-02-26 image. Use raspi-config to resize and boot without desktop and https://github.com/Interbotix/HROS1-Framework/wiki for all Debian Dependencies, get clone the framework and everything compiles and runs some 35% Faster oh yes!!
Sounds great.

Yep - I wll try out my C2 on it at some point soon. Also will be using my TTL level communications. But right now I am more into Hexapod mode/mood. May also use my Teensy 3.2 setup instead of Arbotix Pro. What I need to do is figure out how the code base uses the Gyro/Accel information and see if instead I can drop in full IMU support. Probably need to study their code some more in that area... But that sounds like more a conversation for a new topic.

05-06-2016, 10:05 AM
Ok, so th RPI-3 Works with the new image from the rpi 2016-02-26 image. Use raspi-config to resize and boot without desktop and https://github.com/Interbotix/HROS1-Framework/wiki for all Debian Dependencies, get clone the framework and everything compiles and runs some 35% Faster (you know i am guessing on the speed increase but it is much faster.) oh yes!! edit note (the wifi built in is really nice and frees up a usb port, so I really dont need a hub. Yea!)(Note still have some Bluetooth issues with the rpi3)

Hi Lloyd, are you seeing the latency issue with the RPi3?

05-07-2016, 07:09 AM
Hi. I have temporarily stopped using the RPi3 until a few more issues are worked out with there image and the new V2.1 camera, but as far as to what does work all you need do is make sure the Desktop is off and unless your running a real time rig like a chopper you should be good.

05-07-2016, 09:11 PM
Ok, thanks, sounds good.